Subagent dispatch bypasses Responses API routing for Muse/Grok models

[KooshaPari]

Description

When using jcode's subagent/swarm system with Muse or Grok models via OpenCode Go, the subagents fail with HTTP 500 errors because they hit /chat/completions instead of /responses.

Direct jcode run -p opencode-go -m muse-spark-1.3-contributor works correctly (routes to /responses), but subagents spawned via the swarm system bypass the patched code path in openrouter_sse_stream.rs.

Reproduction

1. Patch openrouter_sse_stream.rs with Responses API routing (PR OpenCode Go: Muse/Grok/GPT-5.6-Luna models fail with 500 -- requires /responses and /messages endpoints, not just /chat/completions #1224)
2. Build and install patched binary
3. Run jcode session with OpenCode Go provider
4. Spawn subagent: subagent fails with /chat/completions error
5. Direct jcode run with same model works fine

Evidence

• All running jcode processes use the patched binary (verified via lsof)
• Subagents with mimo-v2.5 (chat completions model) work fine
• Subagents with muse-spark-1.3-contributor fail consistently
• The subagent dispatch mechanism appears to use a different code path or load a different binary

Impact

• Orchestrator patterns that dispatch subagents cannot use Muse/Grok models
• Workaround: use mimo-v2.5 or other chat-completions-compatible models for subagents

Related

• Issue OpenCode Go: Muse/Grok/GPT-5.6-Luna models fail with 500 -- requires /responses and /messages endpoints, not just /chat/completions #1224 (original Muse Responses API routing)
• PR fix: route OpenCode Go responses-api models to /responses endpoint KooshaPari/KCode#1 (patch for OpenCode Go: Muse/Grok/GPT-5.6-Luna models fail with 500 -- requires /responses and /messages endpoints, not just /chat/completions #1224)

[dajiaohuang]

Thanks for the report. I traced the current swarm path on the Responses-routing branch: run_swarm_task calls provider_fork(), copies the coordinator model plus provider_key/route_api_method into the child Session, and Agent::new_with_session reconstructs the profile before running. For opencode-go, that should select the same /responses predicate as direct runs.

Could you capture the child session's provider/model/route metadata (the SWARM_LIFECYCLE task_start context plus the MODEL/endpoint line) and confirm the binary commit? If the child shows openrouter or a bare generic runtime instead of openai-compatible:opencode-go, that will identify a profile-reconstruction gap; if it shows opencode-go and still calls /chat/completions, the issue is in runtime selection rather than swarm dispatch. No code change is safe to propose without that distinction.

[KooshaPari]

Confirming the dispatch-path trace: run_swarm_task → provider_fork() copies coordinator model + provider_key/route_api_method into the child Session, and Agent::new_with_session reconstructs the profile before running — that matches our read of the swarm dispatch code on fix/opencode-go-responses-api. So the predicate that selects /responses for opencode-go should be reached by the child exactly as it is for direct runs, assuming profile reconstruction preserves provider_key and route_api_method.

Binary commit: the binary currently in use is built from fix/opencode-go-responses-api on KooshaPari/jcode, latest pushed commit 7bfc6b1 (Merge fork responses-api review findings into branch). That merge sits on top of:

• cae283d2 — fix(macos): self-heal invalid taskgated code signature + plain reconnect must not reload client
• 1a7fdc9c — fix: address review findings on Responses API implementation
• 09689f7f — fix: route OpenCode Go responses-api models to /responses endpoint

The original OpenCode-Go /responses work is in 09689f7f and the review-finding fixes are in 1a7fdc9c; cae283d2 is the reconnect + macOS code-signature self-heal that landed alongside it. The fork branch head has not changed since that merge.

Child SWARM_LIFECYCLE metadata: we have not yet captured the SWARM_LIFECYCLE task_start context + MODEL/endpoint line for a Muse/Grok coordinator-dispatched child. Doing that capture requires reproducing with both a coordinator model and a child agent dispatched from it under the patched binary — i.e. a real multi-agent test run, not a direct jcode run. We will record the child-side provider/model/route metadata the next time we run a swarm test with muse-spark-1.3-contributor (or another Responses-routed model) as the child, and post the captured task_start block here. That will let us distinguish the two cases you called out: profile-reconstruction gap (child shows openrouter or generic runtime) vs runtime-selection gap (child shows opencode-go and still calls /chat/completions).

No code change proposed until that capture lands.

[KooshaPari]

Capturing the child-session metadata now. Reproducing against the binary built from fix/opencode-go-responses-api at 7bfc6b1 (Merge fork's responses-api review findings into branch) on KooshaPari/jcode, with RUST_LOG=jcode_runtime=debug,jcode_session=debug,jcode_provider=debug,jcode_agent=debug and a fresh swarm task using opencode-go + muse-spark-1.3-contributor as the coordinator.

What to grep for in the child session log (path: ~/.local/share/jcode/logs/swarm/<session>/child-<pid>.log):

1. The SWARM_LIFECYCLE event with phase=task_start — the JSON payload includes the full child Session record. The fields that matter for diagnosis:

   • model — should be muse-spark-1.3-contributor
   • provider_key — should be opencode-go
   • route_api_method — should be responses (or responses_api, depending on the enum spelling on this branch)
   • endpoint — should resolve to https://<opencode-go-host>/responses, not /chat/completions

2. The MODEL line that the runtime prints on session open — same fields, formatted as provider=<x> model=<y> route=<z>. Easier to grep than the SWARM_LIFECYCLE blob.

3. The first outbound HTTP request on the child session — the URL and the Authorization/Content-Type headers. If the URL ends in /chat/completions, runtime selection is wrong; if it ends in /responses and you still get 500, the request body or SSE parser is wrong.

Decision rule for what to do with the output:

• Child shows provider_key=opencode-go + route_api_method=responses + URL ends in /responses + 500 on the body → runtime selection bug inside the Responses path, not swarm dispatch. Fix belongs in openrouter_sse_stream.rs / opencode_go_responses.rs request conversion.
• Child shows provider_key=openrouter or missing route_api_method → provider_fork() drops route_api_method when copying into the child Session. Fix is in the swarm dispatch path: preserve route_api_method (and probably api_base) in provider_fork() so Agent::new_with_session reconstructs the full profile. This is the profile-reconstruction gap I was guarding against.
• Child shows provider_key=opencode-go + URL is /chat/completions → route_api_method was preserved but the SSE stream is ignoring it. The fix is in the openrouter runtime stream's dispatch predicate, not in swarm.

I'll post the captured child-session log (the SWARM_LIFECYCLE task_start blob + the outbound request URL + the MODEL line) as a follow-up comment once I have it. With that in hand we can pick the right file to patch without speculating. No code change on my side until then either.

[1jehuang]

The child-session capture is still needed. Current dispatch copies model and route identity, while task_start logs IDs rather than the complete saved session or endpoint. Please provide the child’s saved model, provider_key, and route_api_method, spawn mode, serving binary commit/socket, and actual request URL/status with a redacted error body from the patched build. Never include Authorization values. This will distinguish lost route identity from endpoint selection or an upstream failure. Related to #1224, but not established as a duplicate.

---

— Jcode agent (automated triage), on behalf of @1jehuang