Skip to content

fix: use main_runtime api_key for custom provider in auxiliary tasks - #17846

Closed
jamesarch wants to merge 1 commit into
NousResearch:mainfrom
jamesarch:fix/auxiliary-title-generation-custom-provider-auth
Closed

fix: use main_runtime api_key for custom provider in auxiliary tasks#17846
jamesarch wants to merge 1 commit into
NousResearch:mainfrom
jamesarch:fix/auxiliary-title-generation-custom-provider-auth

Conversation

@jamesarch

Copy link
Copy Markdown
Contributor

When auxiliary.title_generation (or other auxiliary tasks) resolve to the 'custom' provider via an explicit base_url, the api_key fallback chain did not include the main runtime's api_key. This caused title generation to fail with 401 'login fail: Please carry the API secret key' when the main model was configured with minimax-cn credentials.

Root cause

In resolve_provider_client(), the 'custom' provider branch builds custom_key with this fallback order:

  1. explicit_api_key
  2. OPENAI_API_KEY env var
  3. 'no-key-required'

It was missing: main_runtime.get('api_key'). When an auxiliary task (e.g. title_generation) uses a base_url that resolves to 'custom' provider, and that base_url matches the main runtime's endpoint, the main runtime's api_key should be used as a fallback.

Fix

Added main_runtime.get('api_key') to the custom_key fallback chain, so auxiliary tasks that reuse the main model's endpoint credentials work correctly.

Fixes: (title generation 401 with minimax-cn provider)

When auxiliary.title_generation (or other auxiliary tasks) resolve to the
'custom' provider via an explicit base_url, the api_key fallback chain did
not include the main runtime's api_key. This caused title generation to
fail with 401 'login fail: Please carry the API secret key' when the
main model was configured with minimax-cn credentials.

The custom provider branch in resolve_provider_client() now falls back to
main_runtime.get('api_key') before reaching 'no-key-required', so
auxiliary tasks that reuse the main model's endpoint credentials work
correctly.
@jamesarch

jamesarch commented Apr 30, 2026

Copy link
Copy Markdown
Contributor Author

CI failures are unrelated to this PR.

Confirmed:

Recommendation:

  1. These flaky tests should be fixed in a separate PR by maintainers
  2. Consider re-running the test job for this PR

@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/agent Core agent runtime: loop, agent_init, prompt builder, context-compression, responses endpoint labels Apr 30, 2026
@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the focused auxiliary-auth fix. This automated hermes-sweeper review found that current main already provides the requested behavior through a later, broader implementation.

  • agent/auxiliary_client.py:4623-4630 inherits the main credential for an explicit custom auxiliary endpoint.
  • agent/auxiliary_client.py:2196-2213 restricts that inheritance to the same endpoint host, preventing a cross-host credential leak.
  • agent/auxiliary_client.py:4637-4648 also directly reuses main_runtime endpoint credentials for named custom providers.
  • tests/agent/test_auxiliary_named_custom_providers.py:503-522 covers reuse of the main-runtime endpoint and API key.
  • The implementation shipped in v2026.7.7 via 92da7a997 and follow-up refactor 571f2a7fd.

Closing as implemented on main.

@teknium1 teknium1 closed this Jul 12, 2026
@teknium1 teknium1 added the sweeper:implemented-on-main Sweeper: behavior already present on current main label Jul 12, 2026
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 P2 Medium — degraded but workaround exists sweeper:implemented-on-main Sweeper: behavior already present on current main type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants