Error Writing Large Files (at least with Kimi K2.5) #7821

Closed
opened 2026-02-16 18:08:22 -05:00 by yindo · 5 comments
Owner

Originally created by @marcoschwartz on GitHub (Jan 28, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

Got an error while using the new Kimi K2.5 model - Invalid input for tool write: JSON parsing failed

Image

Plugins

No response

OpenCode version

1.1.39

Steps to reproduce

Just use Kimi K2.5 with any provider and ask to edit/write a large file

Screenshot and/or share link

No response

Operating System

macOS 26

Terminal

iTerm2

Originally created by @marcoschwartz on GitHub (Jan 28, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description Got an error while using the new Kimi K2.5 model - Invalid input for tool write: JSON parsing failed <img width="2331" height="887" alt="Image" src="https://github.com/user-attachments/assets/1676a875-7baa-4f80-9e3a-f50b80cd3443" /> ### Plugins _No response_ ### OpenCode version 1.1.39 ### Steps to reproduce Just use Kimi K2.5 with any provider and ask to edit/write a large file ### Screenshot and/or share link _No response_ ### Operating System macOS 26 ### Terminal iTerm2
yindo added the bug label 2026-02-16 18:08:22 -05:00
yindo closed this issue 2026-02-16 18:08:22 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 28, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #10855: Qwen3 Coder on OpenCode Zen: Tool call metadata being printed to chat instead of actually being called (similar tool execution failures with specific models)
  • #10850: Added Kimi API key invocation and the new model Kimi-k2.5 (existing issues with the Kimi K2.5 model)
  • #10953: Google Models cannot call tools anymore (broader pattern of tool calling failures across models)
  • #10820: Add metadata awareness and data type validation/blacklists for LLM tool execution (addresses root cause of data type validation issues)

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 28, 2026): This issue might be a duplicate of existing issues. Please check: - #10855: Qwen3 Coder on OpenCode Zen: Tool call metadata being printed to chat instead of actually being called (similar tool execution failures with specific models) - #10850: Added Kimi API key invocation and the new model Kimi-k2.5 (existing issues with the Kimi K2.5 model) - #10953: Google Models cannot call tools anymore (broader pattern of tool calling failures across models) - #10820: Add metadata awareness and data type validation/blacklists for LLM tool execution (addresses root cause of data type validation issues) Feel free to ignore if none of these address your specific case.
Author
Owner

@ideallove commented on GitHub (Jan 28, 2026):

I also encountered the same issue. I was working on Agent Skill yesterday and today. Yesterday it was completely correct, but today it failed.
The SKILL I was using involved generating JSON, HTML, and escape characters, and the same problem occurred with the write component.
I was using the Windows platform, with LLM being Claude Opus 4.5 and Minimax M2.1.
Just now, I removed OpenCode and Desktop for version 1.1.39. After reverting to version 1.1.36, there were no abnormalities.

Therefore, the temporary solution is to revert to version 1.1.36.
I am currently attempting to analyze and review the updates from 1.1.37 to 1.1.39.
Thank you to the developers for their work.

@ideallove commented on GitHub (Jan 28, 2026): I also encountered the same issue. I was working on Agent Skill yesterday and today. Yesterday it was completely correct, but today it failed. The SKILL I was using involved generating JSON, HTML, and escape characters, and the same problem occurred with the write component. I was using the Windows platform, with LLM being Claude Opus 4.5 and Minimax M2.1. Just now, I removed OpenCode and Desktop for version 1.1.39. After reverting to version 1.1.36, there were no abnormalities. Therefore, the temporary solution is to revert to version 1.1.36. I am currently attempting to analyze and review the updates from 1.1.37 to 1.1.39. Thank you to the developers for their work.
Author
Owner

@ideallove commented on GitHub (Jan 28, 2026):

@marcoschwartz I have fixed the problem I encountered. Maybe your problem has also been resolved.

@ideallove commented on GitHub (Jan 28, 2026): @marcoschwartz I have fixed the problem I encountered. Maybe your problem has also been resolved.
Author
Owner

@Mithrillion commented on GitHub (Jan 28, 2026):

I think equally frustrating is that when you encounter this issue with Kimi K2.5, the agent just stops instead of retrying or continuing the task with a different approach, like in typical tool failures. And if it is in a subagent and the subagent fails, you often have to scrap the whole run, because you cannot simply ask it to continue.

@Mithrillion commented on GitHub (Jan 28, 2026): I think equally frustrating is that when you encounter this issue with Kimi K2.5, the agent just stops instead of retrying or continuing the task with a different approach, like in typical tool failures. And if it is in a subagent and the subagent fails, you often have to scrap the whole run, because you cannot simply ask it to continue.
Author
Owner

@ideallove commented on GitHub (Jan 28, 2026):

Why This Causes invalid Tool Errors?

  • Without maxOutputTokens: The AI SDK doesn't send a max_tokens parameter to the provider
  • Provider uses default limit: Many providers default to a low value (e.g., kimi K2.5 default 32768 from https://platform.moonshot.ai/docs/guide/kimi-k2-5-quickstart)
  • Large tool calls get truncated: When writing files with substantial content, the JSON output exceeds the default limit
  • JSON becomes incomplete: Output is cut mid-string, e.g., {"content": "# -*- coding... (missing closing "})
  • Parse error occurs: JSON Parse error: Unterminated string
  • Fallback to invalid tool: The experimental_repairToolCall handler marks it as invalid

It is more likely to trigger in the subagent. In conclusion, hardcoding will definitely cause problems.

Apart from reverting to the previous version, adding a detection for JSON parsing might make the system more stable.

@ideallove commented on GitHub (Jan 28, 2026): Why This Causes invalid Tool Errors? - Without maxOutputTokens: The AI SDK doesn't send a max_tokens parameter to the provider - Provider uses default limit: Many providers default to a low value (e.g., kimi K2.5 default 32768 from https://platform.moonshot.ai/docs/guide/kimi-k2-5-quickstart) - Large tool calls get truncated: When writing files with substantial content, the JSON output exceeds the default limit - JSON becomes incomplete: Output is cut mid-string, e.g., {"content": "# -*- coding... (missing closing "}) - Parse error occurs: JSON Parse error: Unterminated string - Fallback to invalid tool: The experimental_repairToolCall handler marks it as invalid It is more likely to trigger in the subagent. In conclusion, hardcoding will definitely cause problems. Apart from reverting to the previous version, adding a detection for JSON parsing might make the system more stable.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#7821