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

[mcotdev]

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

[kajdo]

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]

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]

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