hermes - 💡(How to fix) Fix xAI OAuth fallback after provider switch due to stale encrypted_content replay

Summary

When an existing long-running gateway/Telegram session is switched to xai-oauth/grok-4.3, Hermes replays prior Responses-style encrypted reasoning items from the conversation history. xAI rejects the request with HTTP 400 because it cannot decrypt the provided encrypted_content, then Hermes immediately activates fallback (in our setup, opencode-go/kimi-k2.6).

A fresh one-shot session with the same xAI OAuth credential and model works, so this does not appear to be an auth, availability, or model-access issue.

Evidence

Fresh test succeeds:

hermes chat -q 'respond with exactly OK' --provider xai-oauth -m grok-4.3 -Q

Output:

OK

But in a long-running Telegram session after switching to xai-oauth/grok-4.3, ~/.hermes/logs/agent.log shows:

OpenAI client created ... provider=xai-oauth base_url=https://api.x.ai/v1 model=grok-4.3
conversation turn: ... model=grok-4.3 provider=xai-oauth platform=telegram history=247 ...
API call failed (attempt 1/3) error_type=BadRequestError ... provider=xai-oauth base_url=https://api.x.ai/v1 model=grok-4.3 summary=HTTP 400: Error code: 400 - {'code': 'Client specified an invalid argument', 'error': 'Could not decrypt the provided encrypted_content. Ensure the value is the unmodified encrypted_content from a previous response.'}
Fallback activated: grok-4.3 → kimi-k2.6 (opencode-go)

The same pattern repeats on later turns when the primary runtime is restored:

Primary runtime restored for new turn: grok-4.3 (xai-oauth)
API call failed ... HTTP 400 ... Could not decrypt the provided encrypted_content...
Fallback activated: grok-4.3 → kimi-k2.6 (opencode-go)

Expected behavior

Hermes should not replay provider/model/session-specific encrypted reasoning blobs when they are incompatible with the current provider/model request.

At minimum, when xAI returns Could not decrypt the provided encrypted_content, Hermes should retry the same provider/model with encrypted reasoning stripped from historical assistant messages before activating fallback.

Actual behavior

Hermes sends stale/non-decryptable encrypted_content to xAI, xAI rejects the request with HTTP 400, and Hermes immediately falls back to the configured fallback provider.

This makes manual switching to Grok appear unreliable even though a fresh xAI OAuth request succeeds.

Suggested fixes

Any of these would likely solve the issue:

1. Strip encrypted_content / codex_reasoning_items when switching provider/model families.
2. Track which provider/model/session minted each encrypted reasoning item and only replay it to compatible targets.
3. Add targeted retry logic: if a provider error contains Could not decrypt the provided encrypted_content, retry once against the same provider/model with encrypted reasoning removed from prior assistant messages; only fallback if that retry fails.

Environment

• Hermes gateway session: Telegram DM, long-running session history
• Provider/model selected manually: xai-oauth/grok-4.3
• xAI base URL: https://api.x.ai/v1
• Fallback provider/model observed: opencode-go/kimi-k2.6
• Fresh hermes chat --provider xai-oauth -m grok-4.3 test succeeds

Related code noticed during investigation

agent/codex_responses_adapter.py intentionally replays encrypted reasoning items for Responses transports, including xAI:

# Replay encrypted reasoning items from previous turns
# so the API can maintain coherent reasoning chains.
# This applies to every Responses transport including
# xAI — see _chat_messages_to_responses_input docstring
# for the May 2026 reversal of the earlier xAI gate.

That behavior is reasonable for continuity when the encrypted blob belongs to the same compatible provider/model chain, but seems brittle after runtime/provider switches or when the historical blob is no longer decryptable by xAI.