hermes - 💡(How to fix) Fix Gateway: prevent silent fallback on high-trust routes and expose effective model [1 comments, 1 participants]

Problem

High-trust gateway channels can silently fall back from the configured primary model/provider to a weaker fallback provider when the primary credential pool is unavailable. In a real incident, a Weixin DM route configured for openai-codex / gpt-5.5 / gpt-pro-account-5 repeatedly fell back to kimi-coding / kimi-k2.6 because the gateway runtime saw credential pool: no available entries / No Codex credentials stored. The user only noticed after task quality degraded.

Relevant log pattern:

Primary provider auth failed: No Codex credentials stored. Run `hermes auth` to authenticate. — trying fallback
Fallback provider resolved: kimi-coding model=kimi-k2.6
Runtime provider supplied explicit model override: gpt-5.5 -> kimi-k2.6

This is dangerous for high-authority channels because fallback changes the effective model capability and behavior without an obvious runtime signal.

Current Behavior

• model.default remains gpt-5.5 and gateway routing can be configured to target openai-codex with an allow-listed credential label.
• When the gateway cannot load/use the primary provider credential pool, it falls back to the configured fallback provider.
• The fallback can persist across messages/runs until gateway/auth state is refreshed.
• Replies do not consistently include the actually used provider/model/credential label, so users cannot easily detect silent downgrade.

Expected Behavior

Add first-class controls for high-trust gateway routing:

1. Strict routing / no silent fallback

   • For selected gateway routes/chats/platforms, if the configured provider/credential label is unavailable, fail closed with a clear error instead of silently using fallback.
   • Example policy shape:

     gateway_credential_routing:
       rules:
         - platform: weixin
           provider: openai-codex
           allow_labels: [gpt-pro-account-5]
           exclusive: true
           direct: true
           fallback_policy: fail_closed   # or strict: true / allow_fallback: false

2. Runtime model/provider watermark

   • Optional per-platform/per-chat footer showing the actual runtime model/provider/credential label.
   • Normal example: — gpt-5.5 · openai-codex · gpt-pro-account-5
   • Fallback example: — ⚠ fallback: kimi-k2.6 · kimi-coding · codex unavailable

3. Explicit downgrade/restore events

   • If fallback is allowed, the response should make the downgrade visible.
   • When the primary provider/credential becomes available again, the gateway should prefer/restore the primary route on the next message and optionally show restored once.

4. Observability and audit logs

   • Log selected runtime provider/model/credential label per gateway response.
   • Log route policy decisions: strict fail-closed, fallback allowed, fallback reason, restored primary.

Acceptance Criteria

• A gateway route can be configured so that an unavailable primary credential produces a clear user-visible error and does not call fallback providers.
• A gateway route can optionally append a concise runtime model footer to responses.
• If fallback is allowed, fallback responses are visibly marked as fallback.
• Gateway logs include the effective provider/model/credential label for each response.
• Tests cover:
  • strict route + missing primary credential => no fallback call
  • non-strict route + missing primary credential => fallback call with visible warning
  • footer/watermark formatting for normal and fallback responses
  • primary restoration after credential pool becomes available again, if restoration logic is implemented

Notes

This belongs in Hermes runtime/gateway rather than skills: the issue is provider selection, credential routing, fallback policy, and gateway response observability.