Repository navigation
opencode-go kimi-k3 intermittently emits raw <|...|> chat-template delimiters and pathological parallel tool-call bursts #46411
Description
Description
Environment
- opencode build: 0.0.0-dev-202608271917 (and later dev builds) (own fork with own bug fixes and features, however, the issue is not in the opencode client, but upstream in the servers hosting the Kimi K3 model)
- model: kimi-k3, provider: opencode-go
- runtime: ai-sdk, llm.runtime=ai-sdk
- observed over long autonomous "build" runs (multiple hours), context kept small via compaction (~17k–200k tokens)
Summary
On long-running sessions, kimi-k3 (served through opencode-go) periodically produces malformed responses in two ways that both look like the model "glitching," and both seem to stem from the model's thinking→answer→tool-call structure markers being mishandled.
Symptom 1 — raw template delimiters leak into visible output, then the stream truncates
Reasoning parts intermittently end with literal delimiter tokens instead of a real answer or tool call, e.g.:
reasoning| ... via images:<|close|>response<|sep|><|open|>tools<|sep|><|open|>call t…
<|close|>, <|open|>, <|sep|>, plus the response / tools / call markers, appear to be the model's internal separators for thinking → response → tool-call. They leak as raw text and the stream dies mid-token (cut off at call t…). Result: a turn that ends finish="stop" with reasoning but no answer and no tool call — to the client it looks like "the model thought and then just stopped." We've also captured turns that are literally finish="stop", tokens.output=0, tokens.reasoning in the thousands (pure thinking, zero output).
Symptom 2 — pathological burst of identical parallel tool calls
In one assistant message the model emitted 100 identical tool calls (tessera_get_session_id), and in the next message 97 more — same tool, empty input, all in parallel (callID values like tessera_get_session_id_93, _94, …). A total of ~193 calls landed in a ~2-minute window. The model then reportedly self-detected ("I'm doing this 100 times") but relapsed into another burst. One such message carried 100 tool parts; the next 97.
Why this matters
- Symptom 1 makes long runs silently lose turns (the model appears to halt after thinking).
- Symptom 2 burns a large number of tokens/context per message and forces the user to add client-side loop detection to survive autonomous runs.
Suspected root cause
Both symptoms are consistent with opencode-go's kimi-k3 adapter (or the upstream served template) not consuming/parsing the model's <|open|>/<|close|>/<|sep|> structured-output delimiters correctly — the tokens leak into the text stream and the generation terminates abnormally (empty finish → "unknown"/"stop", or runaway repeated tool calls).
Requested
- Confirm whether kimi-k3 over opencode-go is expected to emit these delimiters, and whether the served chat template should be stripping them.
- Any known fix/workaround (template version, model revision, stop-token config) for kimi-k3 structured output.
Plugins
No response
OpenCode version
not about the opencode software version, it's about your servers
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
github-actions commentedon Aug 31, 2026
This issue might be a duplicate of or related to existing issues. Please check:
<|...|>special tokens into error messages causing cascading tool-call failures — directly related to your Symptom 1 (raw delimiter leakage) and shares the same root cause of chat-template tokens not being strippedtessera_get_session_idcalls with no burst detection)finish="stop", thousands of reasoning tokens, and zero output tokensopencodejr commentedon Oct 28, 2026
Thanks for the detailed write-up, @gschadow. Before we can look into this, we need a few things:
0.0.0-dev-202608271917). Can you reproduce it with an official release, ideally the current v2 (npm i -g @opencode/cli, thenopencode --version)? That would rule out the fork's changes and tell us which client version this concerns.tessera_get_session_idlooks like a custom tool), and what you saw on screen when it happened.<|close|>response<|sep|><|open|>tools...) and one burst message. Please remove any secrets first.You can reply here with the details or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know you're done.
opencodejr commentedon Oct 31, 2026
We're closing this for now because we haven't heard back. To look into the kimi-k3 problems on OpenCode Go (leaked
<|open|>/<|close|>/<|sep|>delimiters and the bursts of identical tool calls), we need three things:opencode --version) rather than your forkIf you can share these, please comment here and we can reopen it, or open a new issue that links to this one. Thanks for taking the time to report it.