Go endpoint: kimi-k3 rejects 'n' parameter (400: n: Input should be None)

Bug

The OpenCode Go endpoint (https://opencode.ai/zen/go/v1/chat/completions) returns HTTP 400 for kimi-k3 whenever the request includes the n parameter — even the OpenAI-default n: 1:

{
  "error": {
    "type": "server_error",
    "message": "Error from provider (Console Go): Upstream request failed: n: Input should be None"
  }
}

Reproduction

curl https://opencode.ai/zen/go/v1/chat/completions \
  -H "Authorization: Bearer $OPENCODE_GO_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"kimi-k3","messages":[{"role":"user","content":"Say OK"}],"max_tokens":16,"n":1}'

-> 400 with the error above. The same request without n succeeds.

Scope

Affects kimi-k3 with any reasoning_effort value (low/medium/high/max) and also with no effort parameter at all.
Other Go models tested (kimi-k2.6, kimi-k2.7-code, glm-5.3, minimax-m3, mimo-v2.5) accept n: 1 fine — the bug is specific to kimi-k3's upstream validation.

Impact

Any OpenAI-compatible client that always sends n: 1 (VS Code Copilot Chat custom models, several SDKs) cannot use kimi-k3 on the Go plan at all. Presumably the upstream model's pydantic schema declares n: None = None and rejects any provided value instead of ignoring n=1.

This issue might be a duplicate of or related to existing issues about the Go gateway forwarding parameters that strict upstream validators reject. Please check:

OpenCode Go: kimi-k3, kimi-k2.6, kimi-k2.7-code, glm-5.2, grok-4.5, qwen3.7-max, hy3-preview all fail with 'Upstream request failed' — non-standard 'mcp'/'system' fields rejected by strict provider validators #37771: OpenCode Go: kimi-k3 and other models fail with 400 because non-standard fields (mcp, system) are forwarded verbatim to strict provider validators — same root cause class (gateway not stripping provider-incompatible fields before forwarding).
models: catalog variant settings sent with camelCase keys to OpenAI-compatible providers -> 400 'Extra inputs are not permitted' #41971: Catalog variant settings sent with camelCase keys to OpenAI-compatible providers causing 400 'Extra inputs are not permitted' — another instance of the gateway forwarding fields that strict validators reject.

The n parameter issue you describe is a distinct specific case (the upstream kimi-k3 model declares n: None and rejects any provided value, including the OpenAI-default n=1), but it falls into the same general class of the gateway not sanitizing/stripping incompatible parameters per-model before forwarding.

Thanks for the clear report and the curl reproduction. Testing this needs a real OpenCode Go API key so the request reaches the kimi-k3 upstream, and our automated environment doesn't have one. Without a key, the endpoint rejects the request before it gets as far as checking n. The problem is in the hosted Go gateway (or the upstream behind it) rather than in the OpenCode app, which doesn't send n itself, so a maintainer with Go access will need to confirm it.

Related reports:

opencode-go kimi-k3 intermittently emits raw <|...|> chat-template delimiters and pathological parallel tool-call bursts #46411: another kimi-k3 problem on opencode-go
Go (/zen/go/v1/responses): deepseek-flash never returns phase on assistant messages, which breaks Codex desktop's turn collapsing #57372: another behaviour bug on the Go endpoint

Navigation Menu

Repository navigation

Go endpoint: kimi-k3 rejects 'n' parameter (400: n: Input should be None) #47568

Bug

Reproduction

Scope

Impact

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Go endpoint: kimi-k3 rejects 'n' parameter (400: n: Input should be None) #47568

Description

Bug

Reproduction

Scope

Impact

Activity

github-actions commented on Sep 6, 2026

opencodejr commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions