Repository navigation
Tool Calls Section End Token (<|tool_calls_section_end|>) Parsing Failures #1021
Description
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
- Configure OpenCode with Kimi K2 through OpenRouter:
{ "model": "moonshotai/kimi-k2", "provider": "openrouter" } - Request a task that requires tool calls (e.g., "Create a file named test.py")
- Observe the raw response output (if possible)
- 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
Activity
kajdo commentedon Jul 15, 2025
not directly related - but just a thought ... if the providers of kimi-k2 act differently (as mentioned in #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
scottyeager commentedon 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.
rekram1-node commentedon Dec 28, 2025
[automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!
feat(team-builder): use `claude agents` command for agent discovery (a…