Skip to content

fix(fallback): pass explicit credentials from fallback config to provider router - #2705

Closed
tannerfokkens-maker wants to merge 1 commit into
NousResearch:mainfrom
tannerfokkens-maker:fix/fallback-model-custom-credentials
Closed

fix(fallback): pass explicit credentials from fallback config to provider router#2705
tannerfokkens-maker wants to merge 1 commit into
NousResearch:mainfrom
tannerfokkens-maker:fix/fallback-model-custom-credentials

Conversation

@tannerfokkens-maker

Copy link
Copy Markdown

Summary

  • _try_activate_fallback() was ignoring base_url and api_key from the fallback_model config when calling resolve_provider_client(). For custom providers, this caused the router to fall through to environment variable resolution (OPENAI_BASE_URL / OPENAI_API_KEY), which typically still point at the primary (exhausted) endpoint — silently defeating the entire fallback mechanism.
  • Now forwards fb.get("base_url") and fb.get("api_key") as explicit_base_url and explicit_api_key, parameters that resolve_provider_client() already supports but were never used from this call site.

Reproduction

Configure a custom fallback provider in config.yaml:

model:
  default: gpt-5.4
  provider: openai-codex

fallback_model:
  provider: custom
  model: qwen3.5-27b
  base_url: http://localhost:1234/v1
  api_key: sk-local-key

Exhaust the primary model's quota. Before this fix, fallback activation would fail because the provider router never received the custom endpoint credentials — it tried env vars instead, which either pointed at the primary or weren't set.

Test plan

  • Exhaust primary model quota and verify fallback activates with the correct custom endpoint
  • Verify fallback still works for non-custom providers (openrouter, anthropic, etc.) where base_url/api_key are None in config
  • Run existing tests/test_fallback_model.py suite

🤖 Generated with Claude Code

…ider router

When fallback_model is configured with a custom provider (base_url + api_key),
_try_activate_fallback() was calling resolve_provider_client() without forwarding
the explicit base_url and api_key from the fallback config. This caused the
provider router to fall through to environment variable resolution (OPENAI_BASE_URL,
OPENAI_API_KEY), which typically point at the primary/exhausted endpoint — silently
defeating the fallback mechanism for custom providers.

Now passes fb.get("base_url") and fb.get("api_key") as explicit_base_url and
explicit_api_key, which resolve_provider_client() already supports but were
never being used from this call site.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the contribution @tannerfokkens-maker! This fix has since been implemented independently on main.


This is an automated hermes-sweeper review.

Evidence that the fix is already on main:

  • Commit 70f798043b (merged via PR fix: Ollama Cloud auth, /model switch persistence, and alias tab completion #5269 on 2026-04-05) independently introduced fb_base_url_hint/fb_api_key_hint extraction and forwarding as explicit_base_url/explicit_api_key in _try_activate_fallback() — the exact fix this PR proposes.
  • run_agent.py lines 6873–6887 on current main confirm the forwarding is live.
  • The main-branch version is a superset: it additionally resolves key_env environment-variable secrets (commit 4ac1c959b2) and applies a security hardening for Ollama Cloud host-matching (GHSA-76xc-57q6-vm5m, commit 7fc1e9181).
  • Shipped in release v2026.4.8.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants