hermes - ✅(Solved) Fix --oneshot CLI mode: fallback_providers chain not propagated to AIAgent constructor [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#18961Fetched 2026-05-03 04:53:16
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Participants
Timeline (top)
labeled ×3cross-referenced ×1

Fix Action

Workaround

Manually pass -m <fallback_model> --provider <provider> on every --oneshot invocation.

PR fix notes

PR #18962: fix(cli): propagate fallback_providers to AIAgent in oneshot mode

Description (problem / solution / changelog)

Summary

Fixes #18961 — --oneshot CLI mode now respects the configured fallback_providers chain from config.yaml, bringing it to parity with gateway mode.

Problem

When the primary provider returns HTTP 429 (rate-limit) in --oneshot mode, the agent hard-fails instead of falling back to the next provider in the fallback_providers chain. Gateway mode already handles this correctly by passing fallback_model=self._fallback_model to the AIAgent() constructor.

Root Cause

hermes_cli/oneshot.py loads cfg = load_config() but never extracts fallback_providers / fallback_model from it, and the AIAgent(...) call at line 287 is missing the fallback_model= parameter entirely.

Fix

Two-line change:

  1. Extract fallback config from the already-loaded cfg: fallback_model = cfg.get("fallback_providers") or cfg.get("fallback_model") or None
  2. Pass it to AIAgent(...): fallback_model=fallback_model

AIAgent.__init__ already normalizes both the list (fallback_providers) and legacy dict (fallback_model) formats into a fallback chain, so this works with either config style.

Testing

  • Manual: configure a fallback_providers chain in config.yaml, then run hermes --oneshot while the primary provider is rate-limited → previously hard-failed, now falls back.
  • AIAgent.__init__ signature already accepts fallback_model parameter (line 954 in run_agent.py), so no downstream changes needed.

Files Changed

  • hermes_cli/oneshot.py: Added fallback config extraction + parameter passthrough (5 lines)

Changed files

  • hermes_cli/oneshot.py (modified, +5/-0)

Code Example

fallback_model = cfg.get("fallback_providers") or cfg.get("fallback_model") or None
# ... in AIAgent(...) call:
fallback_model=fallback_model,
RAW_BUFFERClick to expand / collapse

Bug

In --oneshot CLI mode, the configured fallback_providers chain from ~/.hermes/config.yaml is not loaded and not passed to the AIAgent() constructor. As a result, HTTP 429 (rate-limit) responses on the primary provider cause hard failure instead of fallback. Gateway mode handles this correctly.

Reproduce

  1. Configure 4-provider fallback_providers: chain in config.yaml.
  2. Hit primary provider's per-minute quota.
  3. Run any hermes --oneshot ... (or hermes -p ...) call.
  4. Observe: hard 429 abort, no fallback attempt.
  5. Same scenario via Telegram gateway: fallback chain triggers correctly.

Diagnosis

  • hermes_cli/oneshot.py (~lines 287-309 in v0.12.0): AIAgent(...) call has no fallback_model= parameter.
  • gateway/run.py (~lines 8573-8599 and 12418-12447): AIAgent(...) call correctly passes fallback_model=self._fallback_model.
  • _load_fallback_model() in gateway code is never invoked from the oneshot path.

Suggested fix (minimal, ~10 lines in hermes_cli/oneshot.py)

fallback_model = cfg.get("fallback_providers") or cfg.get("fallback_model") or None
# ... in AIAgent(...) call:
fallback_model=fallback_model,

Workaround

Manually pass -m <fallback_model> --provider <provider> on every --oneshot invocation.

Environment

  • Hermes Agent v0.12.0 (Build 2026.4.30)
  • Linux Mint, kernel 6.8
  • Python 3.11.15

Related

RELEASE_v0.12.0.md mentions Gemini-429 setup guidance (#15100) but no oneshot-pipeline fix.

extent analysis

TL;DR

The most likely fix is to modify the hermes_cli/oneshot.py file to load and pass the fallback_providers chain to the AIAgent() constructor.

Guidance

  • Verify that the fallback_providers chain is correctly configured in ~/.hermes/config.yaml.
  • Check the hermes_cli/oneshot.py file (lines 287-309 in v0.12.0) to confirm that the AIAgent() call is missing the fallback_model parameter.
  • Apply the suggested fix by adding the fallback_model parameter to the AIAgent() call in hermes_cli/oneshot.py.
  • As a temporary workaround, manually pass the -m <fallback_model> --provider <provider> flags on every --oneshot invocation.

Example

fallback_model = cfg.get("fallback_providers") or cfg.get("fallback_model") or None
# ... in AIAgent(...) call:
fallback_model=fallback_model,

Notes

This fix assumes that the fallback_providers chain is correctly configured in ~/.hermes/config.yaml and that the hermes_cli/oneshot.py file is the correct location for the fix.

Recommendation

Apply the workaround by manually passing the -m <fallback_model> --provider <provider> flags on every --oneshot invocation, as the suggested fix requires modifying the code.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix --oneshot CLI mode: fallback_providers chain not propagated to AIAgent constructor [1 pull requests, 1 participants]