NousResearch/hermes-agent
Named custom provider handling falls back to OpenRouter or loses config
Cluster 34001 · agent. Data as of
2 open items. Fix attempted, not merged.
The short answer
1open issue
1open PR
5items grouped
- Known?
- Yes. 5 related items grouped here, 3 issues already closed.
- Fix event
- No fix has been merged to main. see the attempts below.
- Tracker
- The maintainers' tracker marks this
unresolved. That is separate from the fix event. - Still open
- 1 issue and 1 PR.
Next step: read the attempts below. Your case may extend or revive that work.
Pick up a Lab taskMost members describe named or bare "custom" providers being normalized or misrouted, with reports of OpenRouter being used in TUI/Desktop sessions and a 401 on resume. Two also point to a related timeout-setting issue, and one is a PR that passes requested_provider through the gateway; the members do not establish whether any of this is fixed.
Open issues1
- Issue#34001Named custom provider stale_timeout_seconds ignored because runtime provider is normalized to `custom`
Open PRs1
- PR#34078fix(timeouts): plumb requested_provider through gateway to resolve named custom provider timeouts (#34001)
Closed issues · 3
How this cluster was grouped
-
Link evidence (
partly structural links): some members are connected by structural evidence (shared changed files, or a closing/superseded reference); the rest are joined by an automated relevance judgement over their text. - Members outside that structural core may belong to a different underlying problem.
-
Pairwise link density
0.21: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36.1.00means every pair is linked.
Pick up a Lab task
Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.
Open the LabAt a glance
- Subsystem
- agent
- Closed issues
- 3
- Attempts
- 0 PRs closed without merging