fix(auxiliary): custom provider URL rewrite + main_runtime model for title gen by crayfish-ai · Pull Request #16819 · NousResearch/hermes-agent

crayfish-ai · 2026-04-28T04:15:02Z

Summary

Auxiliary client improvements, rebased cleanly on upstream/main:

Changes

agent/auxiliary_client.py:
- Apply _to_openai_base_url() to custom provider base_url (fixes /anthropic → /v1 rewrite missing for provider="custom")
- Use main_runtime.get("model") instead of _read_main_model() so auxiliary tasks follow system default model changes
agent/title_generator.py: Thread main_runtime through generate_title → auto_title_session → maybe_auto_title
cli.py / gateway/run.py: Pass main_runtime dict to maybe_auto_title
tests/agent/test_title_generator.py: Update mock assertions for new main_runtime parameter

Files: 5 changed, +26/-7 lines

Supersedes the auxiliary portion of #16055 (restart hang fix is already in upstream).

…title gen - auxiliary_client: apply _to_openai_base_url() to custom base_url (fixes /anthropic → /v1 rewrite missing for provider="custom") - auxiliary_client: use main_runtime.get("model") instead of _read_main_model() so auxiliary tasks follow system default model changes - title_generator: thread main_runtime through generate_title → auto_title_session → maybe_auto_title - cli.py / gateway/run.py: pass main_runtime to maybe_auto_title - tests: update mock assertions for new main_runtime parameter

alt-glitch · 2026-04-28T04:36:24Z

Supersedes auxiliary fix from #16055 (closed). Closes #16719 (auxiliary tasks ignore custom base_url).

…anches Follow-up to PR #16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

teknium1 · 2026-04-28T08:47:50Z

Merged via #16922 with your commit cherry-picked onto current main (authorship preserved as crayfish-ai <270082434+crayfish-ai@users.noreply.github.com> → f3371c3). I also widened the same treatment to the two sibling custom-endpoint fallback sites in resolve_provider_client() carrying the identical bug class — named-custom providers (providers: / custom_providers: config) and the external-process branch (copilot-acp) — so the /anthropic → /v1 rewrite and main_runtime.get('model') fallback are consistent across all three. Thanks for the fix!

…clients (#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (#16819, #22ddac4b1) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

…anches Follow-up to PR #16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

…clients (#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (#16819, #22ddac4b1) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

…anches Follow-up to PR NousResearch#16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

…clients (NousResearch#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (NousResearch#16819, #22ddac4b1) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

…anches Follow-up to PR NousResearch#16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

…clients (NousResearch#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (NousResearch#16819, #22ddac4b1) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

…anches Follow-up to PR NousResearch#16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

…clients (NousResearch#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (NousResearch#16819, #5dca13839) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

…anches Follow-up to PR NousResearch#16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

…clients (NousResearch#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (NousResearch#16819, #22ddac4b1) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

…anches Follow-up to PR NousResearch#16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

…clients (NousResearch#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (NousResearch#16819, #22ddac4b1) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

…anches Follow-up to PR NousResearch#16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

…clients (NousResearch#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (NousResearch#16819, #6bc0375b2) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

…anches Follow-up to PR NousResearch#16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

…clients (NousResearch#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (NousResearch#16819, #22ddac4b1) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

…anches Follow-up to PR NousResearch#16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

…clients (NousResearch#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (NousResearch#16819, #d39a3df20) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

…anches Follow-up to PR NousResearch#16819 applying the same treatment to the two sibling fallback sites in resolve_provider_client() that carry the identical bug class as the anonymous-custom branch: - Named custom provider (providers: / custom_providers: config entries): apply _to_openai_base_url() on the OpenAI-wire path (chat_completions / codex_responses), leave custom_base untouched on the anthropic_messages path where the /anthropic surface is intentional. Prefer main_runtime.get('model') over _read_main_model() so the entry model still wins first. The ImportError fallback for anthropic_messages now redoes query-param extraction against the rewritten URL so the final OpenAI client hits /v1. - external_process branch (copilot-acp): same main_runtime.get('model') fallback before _read_main_model() so auxiliary tasks on this provider track live /model switches instead of stale config.yaml. Keeps the fix consistent across all three custom-endpoint fallback sites in resolve_provider_client().

…clients (NousResearch#17027) Auxiliary tasks (title_generation, vision, compression, web_extract, session_search) now pick the correct wire protocol based on the endpoint, not just on which resolve_provider_client branch built the client. Fixes 404s on Kimi Coding Plan and any other named provider whose endpoint speaks Anthropic Messages. Root cause: the 'api_key' branch of resolve_provider_client (and the Step 2 fallback chain inside _resolve_auto) always built a plain OpenAI client regardless of what the endpoint actually spoke. For provider=kimi-coding + model=kimi-for-coding, that meant: POST https://api.kimi.com/coding/v1/chat/completions { "model": "kimi-for-coding", ... } → 404 resource_not_found_error The /coding route only accepts the Anthropic Messages shape (the main agent already uses api_mode=anthropic_messages for it). Earlier fixes (NousResearch#16819, #22ddac4b1) patched the anonymous-custom, named-custom, and external-process branches — but the named api_key branch (kimi-coding, minimax, zai, future /anthropic providers) was the fourth sibling and never got the same treatment. Fix: one module-level helper _maybe_wrap_anthropic() that rewraps a plain OpenAI client in AnthropicAuxiliaryClient when: - api_mode is explicitly 'anthropic_messages', OR - the URL ends in '/anthropic', OR - the host is api.kimi.com + path contains '/coding', OR - the host is api.anthropic.com. Wired into _wrap_if_needed (covers all resolve_provider_client branches that already go through it) and into the Step 2 api_key fallback chain inside _resolve_auto. Explicit api_mode still wins: passing api_mode='chat_completions' forces OpenAI wire, and already- wrapped specialized adapters (Codex, Gemini native, CopilotACP) pass through unchanged. E2E verified: - resolve_provider_client('kimi-coding', 'kimi-for-coding') → AnthropicAuxiliaryClient (was plain OpenAI, which 404'd) - _resolve_auto Step 1 for kimi-coding runtime → AnthropicAuxiliaryClient - resolve_provider_client('openrouter', ...) → plain OpenAI (no regression) - api_mode='chat_completions' override → plain OpenAI (explicit wins) Tests: - tests/agent/test_auxiliary_transport_autodetect.py (new): 21 tests covering URL detection, wrap decisions, and integration. - 204/205 existing auxiliary tests pass (1 pre-existing failure on main, unrelated to this change). Co-authored-by: teknium1 <teknium@users.noreply.github.com>

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 28, 2026

teknium1 mentioned this pull request Apr 28, 2026

fix(auxiliary): custom provider URL rewrite + main_runtime model for title gen (widened) #16922

Merged

teknium1 closed this in #16922 Apr 28, 2026

teknium1 mentioned this pull request Apr 28, 2026

fix(auxiliary): auto-detect Anthropic Messages transport for all aux clients #17027

Merged

Navigation Menu

Uh oh!

fix(auxiliary): custom provider URL rewrite + main_runtime model for title gen - #16819

fix(auxiliary): custom provider URL rewrite + main_runtime model for title gen#16819
crayfish-ai wants to merge 1 commit into
NousResearch:mainfrom
crayfish-ai:fix-auxiliary-v5

crayfish-ai commented Apr 28, 2026

Uh oh!

alt-glitch commented Apr 28, 2026

Uh oh!

teknium1 commented Apr 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

crayfish-ai commented Apr 28, 2026

Summary

Changes

Uh oh!

alt-glitch commented Apr 28, 2026

Uh oh!

teknium1 commented Apr 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants