Skip to content

[codex] fix(fallback): honor explicit api_mode - #57957

Closed
kohoj wants to merge 1 commit into
NousResearch:mainfrom
kohoj:codex/fix-fallback-api-mode-57582
Closed

[codex] fix(fallback): honor explicit api_mode#57957
kohoj wants to merge 1 commit into
NousResearch:mainfrom
kohoj:codex/fix-fallback-api-mode-57582

Conversation

@kohoj

@kohoj kohoj commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Fixes #57582.

Problem

The original fallback-index report was corrected in the issue thread: the live failure was that a fallback_providers entry could set api_mode: anthropic_messages, but fallback activation ignored that field and inferred transport only from provider name, URL, and model. A custom Anthropic-compatible proxy without an api.anthropic.com host or /anthropic suffix defaulted to chat completions and posted to the wrong endpoint.

Root cause

try_activate_fallback() read provider/model/base_url/api_key from each fallback entry but never read fb["api_mode"]. The primary runtime path supports explicit api_mode; fallback activation did not.

Fix

  • Add an explicit fallback api_mode gate for supported transports before the existing inference chain.
  • Leave existing provider/URL/model inference intact when api_mode is absent.
  • Warn and fall back to inference for unsupported api_mode values.

Tests

  • $HOME/.hermes/hermes-agent/venv/bin/python -m pytest tests/run_agent/test_provider_fallback.py -q
  • $HOME/.hermes/hermes-agent/venv/bin/python -m ruff check agent/chat_completion_helpers.py tests/run_agent/test_provider_fallback.py

@alt-glitch alt-glitch added type/bug Something isn't working comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint P2 Medium — degraded but workaround exists duplicate This issue or pull request already exists labels Jul 3, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

This was generated by AI during triage.

Duplicate of #16346 (earliest open canonical, fix(agent): respect fallback api_mode overrides). Same mechanism -- honor an explicit api_mode on a fallback entry before URL/provider inference in try_activate_fallback() (relocated from run_agent.py to agent/chat_completion_helpers.py). #29749 already dedups into #16346. Note: issue #57582's root cause was corrected in -thread to the fallback-index-reset bug, which #57700 fixes via a DIFFERENT code path (agent_runtime_helpers.py) -- related, not the same fix.

@kohoj
kohoj marked this pull request as ready for review July 4, 2026 12:22
@kohoj

kohoj commented Jul 6, 2026

Copy link
Copy Markdown
Contributor Author

Closing this after re-reading the duplicate feedback: #16346 is the earlier canonical PR for the explicit fallback api_mode path, and the corrected #57582 thread points at a different fallback-index-reset root cause covered elsewhere. I won't keep a non-canonical competing fix open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint duplicate This issue or pull request already exists P2 Medium — degraded but workaround exists type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fallback chain (_fallback_index) doesn't reset on primary recovery — mid-session exhaustion silently disables failover for rest of session

2 participants