Are Cline's truncation limits for tool output and file content configurable?
In Cline VS Code extension 4.1.9 (Next) on VS Code 1.132 with PowerShell 7, run_commands output is truncated at 8,000 characters and read_files content at 50,000 characters, with placeholders like "...[truncated N chars]...". Editor writes are also rejected above 6,000 characters with "Editor input too large: ... exceeding the recommended limit of 6000. Split the edit into smaller tool calls...". Are these limits configurable, and is there a workaround?
Originally asked on GitHub: https://github.com/cline/cline/issues/13263
5 answers
Still open as of the last thread activity (September 2026). The truncation comes from hard-coded budgets in Cline's Message Builder and from the editor tool's input guard, and truncated content is replaced with markers such as "...[truncated N chars]..." and "...[assistant text truncated: omitted N chars]...". A commenter points to open PR #13693, which would adjust the default limits and make them configurable via environment variables so they can be increased or lowered, and cites PR #11475 as the source of some of the limits. No merged fix is confirmed in the thread.
Default limits reported in 4.1.9 (Next): 8,000 chars for tool results (run_commands, search, etc.), 50,000 chars for file content from read_files, 200,000 chars for assistant text, 12,000 chars for assistant tool-call markup, 65,536 bytes for outdated file-content rewrites, and a 6,000,000-byte total conversation budget. The editor tool also rejects old_text/new_text over 6,000 chars with the "Editor input too large" message.
Practical reports in the thread: letting the model split writes into chunks produced an incomplete script on disk (local Mistral on vllm via the OpenAI API), and one user spent roughly 250,000 tokens in a retry loop caused by these limits before switching to a different extension as a stopgap. A PowerShell patch script was mentioned in the thread for changing the limits locally, but its contents and results are not shown.
General advice: until configurable limits ship, keep the data you ask the model to return or write small enough to stay under the caps, for example by having large output written to a file instead of printed back into context.
Did this work for you?What @vsalomaki tried on GitHub (Outcome unclear)
A commenter identified open PR #13693, which adjusts the default limits and makes them configurable via environment variables so they can be increased or lowered, and pointed to PR #11475 as the source of some of the limits. No merge or working result is confirmed in the thread.
Source: https://github.com/cline/cline/issues/13263#issuecomment-5479400948 (opens external site)
Did this work for you?What @Kynlos tried on GitHub (Outcome unclear)
A user reported burning roughly 250,000 tokens in a retry loop caused by the truncation limits, then switched to a different extension so their API costs would stop exploding. The thread does not confirm that this resolved the underlying issue.
Source: https://github.com/cline/cline/issues/13263#issuecomment-5555343030 (opens external site)
Did this work for you?What @Yomark1 tried on GitHub (Didn't work)
A user pointed Cline at a local Mistral model on vllm via the OpenAI API and asked it to rewrite a PowerShell script to a new filename; Cline wrote the file in multiple chunks and the resulting script was incomplete on disk.
Source: https://github.com/cline/cline/issues/13263#issuecomment-5476185239 (opens external site)
Did this work for you?What @rvnlord tried on GitHub (Outcome unclear)
A commenter added a PowerShell script to the thread so users could patch the hard-coded limits locally, with an update in a later comment. The script contents and whether it worked are not shown in the thread.
Source: https://github.com/cline/cline/issues/13263#issuecomment-5333704776 (opens external site)
Did this work for you?