Skip to content

fix(moa): forward slot api_mode + pin chat_completions on live MoA switch - #55579

Merged
teknium1 merged 2 commits into
mainfrom
hermes/hermes-a4e658ce
Jun 30, 2026
Merged

fix(moa): forward slot api_mode + pin chat_completions on live MoA switch#55579
teknium1 merged 2 commits into
mainfrom
hermes/hermes-a4e658ce

Conversation

@teknium1

Copy link
Copy Markdown
Contributor

Summary

Two Mixture-of-Agents transport bugs that broke reference and primary calls are now fixed: MoA slots route through their resolved api_mode, and a live switch to a MoA preset always speaks chat_completions on the primary call.

Changes

  • agent/moa_loop.py + agent/auxiliary_client.py: _slot_runtime now forwards the resolved api_mode, and call_llm accepts an api_mode override (cherry-picked from @liuhao1024's fix(moa): propagate api_mode from slot runtime to call_llm (#54379) #54384). Fixes Copilot GPT-5.x references 400'ing on /chat/completions and anthropic_messages aggregators on unrecognized hosts 404'ing.
  • agent/agent_runtime_helpers.py: switch_model now pins api_mode = "chat_completions" in the provider == "moa" branch, mirroring agent_init.py. The aggregator's real transport is resolved inside the reference/aggregator fan-out, never on the outer primary call.
  • Tests: salvaged test_moa_slot_api_mode.py; added test_moa_switch_api_mode.py asserting the pin holds across codex_responses/anthropic_messages/chat_completions/empty incoming modes.

Root cause

Validation

Before After
Copilot GPT-5.x reference 400 unsupported_api_for_model routed via codex_responses
anthropic_messages aggregator (unknown host) 404 routed via anthropic_messages
Live switch to MoA preset (gateway) primary call → moa://local 404 → fallback MoAClient.chat.completions
test_moa_slot_api_mode / test_moa_switch_api_mode / test_moa_loop_mode 25 passed, 0 failed

Closes #54379, #55268, #54259, #54669.

Infographic

MoA wire-routing fixes


Nous Research

liuhao1024 and others added 2 commits June 30, 2026 03:22
Slot_runtime resolved the provider's real API surface (including api_mode)
but only forwarded base_url and api_key to call_llm, dropping api_mode.
This caused Copilot GPT-5.x reference slots to hit /chat/completions
instead of the Responses API, returning 400 unsupported_api_for_model.

- _slot_runtime: forward api_mode from resolve_runtime_provider
- call_llm: accept explicit api_mode param, override task config
- 4 regression tests for propagation, omission, and signature
The gateway/CLI /model switch path (switch_model in agent_runtime_helpers)
built the MoAClient facade but left agent.api_mode at the value
determine_api_mode / the resolved aggregator transport produced (e.g.
codex_responses or anthropic_messages). The conversation loop dispatches on
agent.api_mode, so a non-chat_completions value made the primary/acting call
go through client.responses.create — which the MoAClient facade has no
.responses for — and fall through to the moa://local placeholder, 404 three
times, then fall back to a reference model (issues #54259, #54669).

agent_init.py already pins api_mode=chat_completions for provider==moa; mirror
that in the live switch so the primary call always routes through
MoAClient.chat.completions. The aggregator's real transport is resolved and
applied inside the reference/aggregator fan-out, not on the outer call.
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 P3 Low — cosmetic, nice to have type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MoA reference slots drop resolved api_mode → Copilot GPT-5.x references 400 with unsupported_api_for_model

3 participants