Kimi K3 works as primary but OpenCode Go rejects subagent requests with 400

[mihneaptu]

Description

Using opencode-go/kimi-k3 through OpenCode Go works when selected for the primary agent, but fails immediately when the same model is invoked as a subagent through task.

I have been using the Sidekick agent from mihneaptu/opencode-fusion. I also reproduced this with that repository's Design agent. They are regular agent Markdown definitions with different permission/tool sets.

The child session records this response:

HTTP 400 invalid_request_error
Error from provider (Console Go): Upstream request failed
isRetryable: false
endpoint: https://opencode.ai/zen/go/v1/chat/completions

Test matrix:

Invocation	Variant	Result
Kimi K3 as primary/default chat	default	Pass
Kimi K3 as primary/default chat	max	Pass
Kimi K3 as Sidekick subagent	default	Fail: HTTP 400
Kimi K3 as Sidekick subagent	max	Fail: HTTP 400
Kimi K3 as Design subagent	max	Fail: HTTP 400

On subagent failure, the primary agent receives an empty task response because the child session ends on the provider error.

This appears related to #31580 and #37496, possibly because a tool schema present in the subagent request is rejected by Kimi/Moonshot. The Console Go response currently hides the underlying upstream validation detail.

Plugins

None. Custom Sidekick/Design agent definitions from mihneaptu/opencode-fusion (not an OpenCode plugin).

OpenCode version

1.18.3

Steps to reproduce

1. Configure a subagent with "model": "opencode-go/kimi-k3" and "variant": "max".
2. From a primary agent, use the task tool to delegate a harmless no-file task to that subagent.
3. Observe that the child returns an empty response and its session logs HTTP 400: Error from provider (Console Go): Upstream request failed.
4. Remove the variant and repeat; the subagent still fails.
5. Run the same model directly as primary with opencode run --model opencode-go/kimi-k3 --variant max "Reply with OK"; it succeeds.
6. Repeat delegation with another subagent definition (Design); it fails with the same 400.

Screenshot and/or share link

Operating System

Microsoft Windows 11 Pro 10.0.26200 (build 26200)

Terminal

Git Bash; also reproduced with opencode run from PowerShell

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Bug: opencode-go/kimi-k2.6 fails in child sessions with "image.png" error #24454: Kimi K2.6 also fails in child (subagent) sessions via OpenCode Go — same symptom of subagent HTTP error while primary works fine

[mihneaptu]

Additional reproduction: native Build fails after multi-turn tool history

I reproduced the same error with no Fusion agents or custom agent files active. The live config contained only:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "opencode-go/kimi-k3",
  "small_model": "opencode-go/kimi-k3"
}

In a native Build session using Kimi K3 max, the model completed several reasoning/tool-call turns successfully and then failed on a later continuation:

HTTP 400 invalid_request_error
Error from provider (Console Go): Upstream request failed
isRetryable: false
endpoint: https://opencode.ai/zen/go/v1/chat/completions

The session had 12 stored messages with successful read, glob, question, and todowrite calls before the failure. Entering continue in that same conversation produced the same error again (same native Build session, at 20:53:38 and 20:57:04 in the log).

Control test immediately afterward:

opencode run --variant max "Do not inspect or modify files. Reply with exactly: FRESH_KIMI_MAX_OK"
FRESH_KIMI_MAX_OK
> build · kimi-k3

Updated conclusion: this is not Fusion-specific, not strictly subagent-only, and not a general Kimi K3 or max outage. Fresh primary sessions succeed, while a longer native Build conversation can fail repeatedly when its accumulated reasoning/tool-call history is replayed. This points to a possible multi-turn reasoning/tool-history serialization incompatibility.

Evidence screenshots:

[mihneaptu]

Update after controlled A/B tests and replaying the affected session through patched source:

1. temperature is one independent 400 path

Using identical fresh Kimi K3 max requests:

• with temperature: 0.2 -> HTTP 400 Upstream request failed
• with the temperature field omitted -> completed successfully

The same omission also let the Fusion Sidekick and Design child agents complete live tool-call tasks. Max thinking remains enabled; only the unsupported sampling field is removed.

Metadata fix: anomalyco/models.dev#3328
Fusion prompt fix: mihneaptu/opencode-fusion#28

2. Long-session history is a separate 400 path

The broken session contained this stored sequence:

step-start -> empty metadata-free reasoning -> step-start -> reasoning -> text

Replay turned the empty boundary into an assistant message with no usable content. The patch skips that empty reasoning part. The focused regression suite passes (37/37), and replaying the exact previously broken Kimi K3 max session continued for 26 model steps and finished normally.

OpenCode fix: #37624

One correction to avoid overclaiming: the public Console code loads the production provider routing table from deployment secrets. It does not prove that OpenCode Go routes Kimi K3 through OpenRouter. What the A/B test proves is that the upstream selected by OpenCode Go rejects the temperature field.

[rekram1-node]

Fixed upstream in models.dev: anomalyco/models.dev#3331

Kimi K3 locks sampling server-side (temperature fixed at 1.0; other values → HTTP 400). The catalog had advertised temperature = true, so clients sent the field and OpenCode Go rejected the request.

#3331 marks the base model temperature = false so clients omit it. After catalog refresh, subagent calls that were injecting temperature should stop 400ing.

Related incomplete fix attempt: anomalyco/models.dev#3328 (closed as superseded).