Built-in providers ignoring config.yaml api_key field

NousResearch/hermes-agent · cluster 7579 · agent

Data as of

6 open items. Fix attempted, not merged.

The short answer

2open issues
4open PRs
9items grouped
Known?
Yes. 9 related items grouped here, 1 issue already closed.
Fix event
No fix has been merged to main. 2 PRs closed without merging; see the attempts below.
Tracker
The maintainers' tracker marks this unresolved. That is separate from the fix event.
Still open
2 issues and 4 PRs.

Multiple reports and corresponding fixes address built-in providers (DeepSeek, Anthropic, others) failing to read the api_key field from config.yaml, instead requiring environment variables. Several fix attempts target this credential priority behavior.

Open issues2

  • Issue#7579Anthropic provider ignores config.yaml api_key, requiring duplicate env var configuration
  • Issue#21725[Bug]: DeepSeek provider ignores api_key in config.yaml, hardcoded only reads environment variable DEEPSEEK_API_KEY

Open PRs4

  • PR#7581fix(providers): honour config.yaml api_key for anthropic provider
  • PR#19523fix(cli): honor fallback model explicit credentials
  • PR#73572fix(auth): honor built-in provider api_key config
  • PR#106947fix(anthropic): honor model.api_key from config.yaml

2 PRs closed without merging

From the close comments: closed without comment 1 · stale or abandoned 1

  • #11713 fix(anthropic): honor model.api_key from config.yaml · closed without comment
  • #21743 fix(auth): read api_key from config.yaml for built-in providers — fixes #21725 · stale or abandoned
Closed issues · 1
  • Closed#19519Built-in Provider API Key Priority: config.yaml api_key field ignored for provider: deepseek
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.19: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36. 1.00 means 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 Lab

At a glance

Subsystem
agent
Closed issues
1
Attempts
2 PRs closed without merging

For your agent

The same facts, typed.