anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Tool Calls Section End Token (<|tool_calls_section_end|>) Parsing Failures #735

New Issue
Closed
opened 2026-02-16 17:28:03 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 17:28:03 -05:00
Owner
Copy Link
Copy Source

Originally created by @mcotdev on GitHub (Jul 15, 2025).

Originally assigned to: @thdxr on GitHub.

OpenCode.ai's parsing system appears to rely on the <|tool_calls_section_end|> token to properly delimit tool calling sections, but this token is frequently missing, malformed, or incorrectly handled by various AI models, leading to parsing failures and broken tool execution.

Environment

  • Provider: OpenRouter
  • Model: moonshotai/kimi-k2
  • OS: Linux

Issue Description

The <|tool_calls_section_end|> token appears to be critical for OpenCode.ai's response parsing, but many models fail to generate it consistently, causing:

  • Incomplete tool execution
  • Parsing errors
  • System hanging/time out issues
  • Malformed responses

Steps to Reproduce

  1. Configure OpenCode with Kimi K2 through OpenRouter: 
    {
  "model": "moonshotai/kimi-k2",
  "provider": "openrouter"
}
  2. Request a task that requires tool calls (e.g., "Create a file named test.py")
  3. Observe the raw response output (if possible)
  4. Note missing or malformed <|tool_calls_section_end|> token

Expected Behaviour

  • All models should consistently generate the required section end token
  • Parser should handle missing tokens gracefully
  • Tool execution should work regardless of minor token variations
Originally created by @mcotdev on GitHub (Jul 15, 2025). Originally assigned to: @thdxr on GitHub. OpenCode.ai's parsing system appears to rely on the `<|tool_calls_section_end|>` token to properly delimit tool calling sections, but this token is frequently missing, malformed, or incorrectly handled by various AI models, leading to parsing failures and broken tool execution. ## Environment - **Provider:** OpenRouter - **Model:** moonshotai/kimi-k2 - **OS:** Linux ## Issue Description The `<|tool_calls_section_end|>` token appears to be critical for OpenCode.ai's response parsing, but many models fail to generate it consistently, causing: - Incomplete tool execution - Parsing errors - System hanging/time out issues - Malformed responses ## Steps to Reproduce 1. Configure OpenCode with Kimi K2 through OpenRouter: ```json { "model": "moonshotai/kimi-k2", "provider": "openrouter" } ``` 2. Request a task that requires tool calls (e.g., "Create a file named test.py") 3. Observe the raw response output (if possible) 4. Note missing or malformed `<|tool_calls_section_end|>` token ## Expected Behaviour - All models should consistently generate the required section end token - Parser should handle missing tokens gracefully - Tool execution should work regardless of minor token variations
yindo added the model-problem label 2026-02-16 17:28:03 -05:00
yindo closed this issue 2026-02-16 17:28:03 -05:00
yindo commented 2026-02-16 17:28:04 -05:00
Author
Owner
Copy Link
Copy Source

@kajdo commented on GitHub (Jul 15, 2025):

not directly related - but just a thought ... if the providers of kimi-k2 act differently (as mentioned in https://github.com/sst/opencode/pull/932) - it might be an option to implement a "Provider Routing" for kimi-k2 and "only use" the moonlight.ai version ... this might also fix the tool calls if openrouter decides to use novita

here is the docu from openrouter: https://openrouter.ai/docs/features/provider-routing

if i missed some configuration option on user-side and somebody knows ... please let me know

@kajdo commented on GitHub (Jul 15, 2025): not directly related - but just a thought ... if the providers of kimi-k2 act differently (as mentioned in https://github.com/sst/opencode/pull/932) - it might be an option to implement a "Provider Routing" for kimi-k2 and "only use" the moonlight.ai version ... this might also fix the tool calls if openrouter decides to use novita here is the docu from openrouter: https://openrouter.ai/docs/features/provider-routing if i missed some configuration option on user-side and somebody knows ... please let me know
yindo commented 2026-02-16 17:28:04 -05:00
Author
Owner
Copy Link
Copy Source

@scottyeager commented on GitHub (Jul 16, 2025):

I also found that there were tool calling problems specifically with the DeepInfra provider for K2 on OpenRouter. New providers are being added and sometimes they have other funny behaviors too.

There's a solution for this directly inside the OpenRouter settings. On the top level settings page there are options for Allowed Providers and Ignored Providers. While it doesn't give the same level of control as selecting providers via the API, it is possible to exclude problematic providers this way or use certain providers exclusively.

My strategy so far has been to check the Activity panel in OpenRouter whenever I noticed an issue and ignore the provider that served the request.

Heavier users of OpenRouter might find this approach limiting. For example if you wanted to use the problematic K2 providers to serve other models, that's not going to be possible simultaneously.

@scottyeager commented on GitHub (Jul 16, 2025): I also found that there were tool calling problems specifically with the DeepInfra provider for K2 on OpenRouter. New providers are being added and sometimes they have other funny behaviors too. There's a solution for this directly inside the OpenRouter settings. On the top [level settings page](https://openrouter.ai/settings/preferences) there are options for *Allowed Providers* and *Ignored Providers*. While it doesn't give the same level of control as selecting providers via the API, it is possible to exclude problematic providers this way or use certain providers exclusively. My strategy so far has been to check the *Activity* panel in OpenRouter whenever I noticed an issue and ignore the provider that served the request. Heavier users of OpenRouter might find this approach limiting. For example if you wanted to use the problematic K2 providers to serve other models, that's not going to be possible simultaneously.
yindo commented 2026-02-16 17:28:04 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 27, 2025):

[automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!

@rekram1-node commented on GitHub (Dec 27, 2025): [automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label model-problem
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#735
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?