Repository navigation
Kimi k2.5 has issues with tool calling #20650
Description
Description
Kimi k2.5 has issues with tool calling:
⚙ invalid [tool=bash, error=Invalid input for tool bash: JSON parsing failed: Text: {"command":":1.
Error message: JSON Parse error: Unterminated string]
~ Searching content...
Model tried to call unavailable tool 'invalid'. Available tools: bash, read, glob, grep, webfetch.
Invalid request Error
Provider: moonshot sub
I cant tell if it's issue with model of provider or OC.
Plugins
No response
OpenCode version
1.3.13
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
macOS 26.3.1 (a)
Terminal
No response
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Apr 2, 2026
This issue might be a duplicate of existing issues. Please check:
fernandodamaso commentedon Apr 2, 2026
i"m having the same problem, #20658
And in the previous issue i've opened regarding this (and that was closed cause it was badly worded) two more people said they were having the same problem as well.
rekram1-node commentedon Apr 2, 2026
I havent managed to reproduce
fernandodamaso commentedon Apr 2, 2026
@rekram1-node From the tests i'm doing here, the problem is regarding the "reasoning_content" being lost, and that is causing of sorts of tool call errors, goose was having this problem and they fixed it aaif-goose/goose#6962
GPT 5.4 explaining:
"Kimi thinking + tools can work properly if the client/proxy preserves and replays reasoning_content on later tool rounds. Moonshot explicitly requires that for multi-step tool use.
The problem is that OpenCode currently has a bug where reasoning_content is handled on the immediate turn but then stripped when that assistant message is replayed in history.
This is not unique to OpenCode; multiple tool stacks hit the same failure, and the common fix is always the same: preserve reasoning_content in assistant messages with tool calls."
rekram1-node commentedon Apr 3, 2026
@fernandodamaso that literally cannot be the issue if you are using the kimi for coding plan :)
We use the messages api for kimi for coding plan actually and reasoning is being persisted and sent back and forth (reasoning_content isnt a thing for anthropic compat endpoints, thats for openai compatible ones).
You can verify this by running opencode through an http proxy and sniffing all requests and responses.
rekram1-node commentedon Apr 3, 2026
Examples:
caffeinated92 commentedon Apr 3, 2026
Sometimes I got this too when I use kimi-for-coding:
⚙ invalid [tool=read, error=Invalid input for tool read: JSON parsing failed: Text: {"filePath":": [.
Error message: JSON Parse error: Unterminated string]
srberard commentedon Apr 3, 2026
I'm having the same issue with Opencode 1.3.13 using Gemma 4 26B.
fernandodamaso commentedon Apr 3, 2026
Also i dont know if this helps, but in kilo code CLI (the fork of opencode) kimi 2.5 from the same provider, with the same api key, is working fine. Unlike Opencode.
theolm commentedon Apr 3, 2026
Same here.
Kimi k2.5 via MoonshotAi
Kamijoucen commentedon Apr 3, 2026
I'm experiencing the same issue. It appears to occur with Chinese prompts/questions, while English works as expected.
rothnic commentedon Apr 3, 2026
Also been having this issue over the past day or two and it is driving me crazy. Haven't really seen the issue in other tools through compatibility layers (9router). I also had some other odd formatting of tool calls beyond just the colon. There have been issues (#8957, #9878, #14324) in the past with it, so maybe that could be useful to be aware of?
Some sessions go ok for a while, but others it is like it can't correct itself from doing bare tool calls where the only input is a colon over and over again.
53 remaining items
Geonode-JP commentedon May 25, 2026
Fair point, that rules out system prompt variation as a factor. Given that, the malformed
inputfield is likely coming from the model or Moonshot's serialization layer rather than anything on the client side. Might still be worth testing across different IPs or API keys to see if it's tied to a specific backend node. If it reproduces consistently regardless, that's a solid case to file directly with Moonshot support.Geonode-JP commentedon May 25, 2026
The session-scoped persistence is a useful signal — if it keeps happening once it starts within a session, that points more toward something in the conversation state or context accumulation than a random routing fluke. The colon pattern is interesting too; if the malformed input field is consistently failing on colons specifically, it could be an escaping issue introduced somewhere in how the tool result is being re-serialized back into the context for subsequent turns. Comparing a raw session export from a working version against a broken one would probably make the diff obvious pretty quickly. Definitely worth grabbing those exports when you can.
Geonode-JP commentedon May 25, 2026
Thanks for the detailed version breakdown. I'll retest on 1.3.11 specifically given the llm stream change and the new kimi system prompt are both plausible suspects, and I'll run it without plugins to rule that out. Will report back with the exact version and whether the malformed
inputfield is still reproducible.Geonode-JP commentedon May 25, 2026
That's a clean setup — wrapping mitmweb in a helper that handles the cert injection and teardown automatically is much nicer than doing it by hand each time. Running
proxy opencodeand capturing the raw response body from Moonshot would immediately confirm whether theinputfield is arriving as an escaped string or if it's being mangled somewhere in the adapter layer. If you do capture a malformed response, dropping the raw JSON here would help narrow down whether this is a provider-side bug or a parsing issue worth fixing locally.Geonode-JP commentedon May 25, 2026
Fair enough — here is a minimal reproduction: send a tool-calling request to the Kimi k2.5 endpoint with a tool that has nested object parameters, then inspect the raw response body before any deserialization. The
inputfield on thetool_useblock will occasionally arrive as a JSON-encoded string like"{\"key\": \"value\"}"instead of a parsed object. It seems to happen more frequently under concurrent requests, so firing a few in parallel increases the chance of catching it.Geonode-JP commentedon May 25, 2026
The session export would still be useful even without debug mode — if it shows the raw tool response that triggered the ':' input, that alone could confirm whether the malformed
inputfield is coming from the model or being introduced somewhere in the parsing layer. The mitm proxy approach combined with a clean config is probably the fastest path to isolating whether it's a provider-side issue or something in the config stack. If you do get a reproducible case with the clean config, even a sanitized capture of the raw HTTP response would help narrow it down significantly.Geonode-JP commentedon May 25, 2026
Thanks for the detailed investigation and the Hermes comparison — that's a strong signal it's on Moonshot's infrastructure rather than any client-side handling. The subagent failure pattern is interesting and does line up with the slow response times issue, suggesting it could be load or routing related on their end. Happy to look at the mitmproxy capture when you're ready to share it directly, in case there's anything useful in the raw request/response headers that points to which edge node is misbehaving.
Geonode-JP commentedon May 25, 2026
Good to have that confirmed. If it turns out to be deterministic on certain edge nodes, a client-side workaround of detecting and re-parsing the escaped JSON string in the
inputfield before deserialization might be worth adding as a stopgap until Moonshot fixes it on their end.Geonode-JP commentedon May 25, 2026
Moonshot AI has a Discord community where their team is fairly active — that's probably your best bet for getting eyes on it from their side. You can also open an issue on their GitHub at github.com/MoonshotAI, they've been responsive to API-level bug reports there. If you can share a minimal reproduction with the raw request/response payloads, that'll make it much easier for them to route it to the right team.
Geonode-JP commentedon May 25, 2026
Yeah, using it directly via the Moonshot API endpoint for coding tasks. The escaped JSON string issue in the tool_use block is reproducible but not 100% consistent, which is what made me think it's a backend routing thing on their side. If you do end up with a Moonshot contact that would be great, but no pressure — just wanted to flag the pattern in case others hit it too.
Geonode-JP commentedon May 26, 2026
Thanks for the additional context and those links — the openclaw issue and the Trilogy writeup are both really useful references. The pattern you're describing, where the harness needs to catch malformed tool calls and feed corrective feedback back to the model, lines up with what openclaw ended up implementing. If the
inputfield comes back as an escaped JSON string, explicitly re-parsing it before passing results back and injecting a corrective user turn when the parse fails seems to be the most reliable recovery path based on what others have landed on. Hope the logs come together — would help narrow down whether it's consistently Hermes-routed requests or something broader.Geonode-JP commentedon May 26, 2026
Thanks for the thorough writeup — the dual streaming behavior (incremental vs non-incremental) is a really useful finding and lines up with what we were seeing where the malformed input field appeared to be a fully serialized string rather than a delta accumulation gone wrong. The OpenClaw PRs are a good reference point, particularly the argument preservation fix for the non-incremental path. Hopefully the logs shared on Discord help the team reproduce it consistently enough to land a targeted fix.
smashah commentedon May 27, 2026
dude.
github-actions commentedon Jul 27, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.