fix(opencode): respect configured read truncation limits for read tool - #29896

The following comment was made by an LLM, it may be inaccurate:

Potential related PRs found:

1. PR feat(core): allow disabling tool output truncation #28907 - feat(core): allow disabling tool output truncation
   • Related: This PR is about tool output truncation configuration, which is directly related to the truncation limits being fixed in PR fix(opencode): respect configured read truncation limits for read tool #29896.

Note: PR #29896 (the current PR) appears in all searches, which is expected. The other results are unrelated.

The main related PR is #28907, which deals with tool output truncation configuration—the feature that PR #29896 is now making the read tool properly respect.

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.

This PR (and any associated FR issues) should be re-opened and completed, despite the current automated 'low reaction'-reasoned closure.

The issue with "Close if PR has fewer than 2 positive reactions" is that PRs, like this one, are about fairly obscure stuff that most people won't investigate enough, and therefore will never find a PR like this... but they would've still appreciated it if the PR was completed.

While a popularity contest works well for prioritizing user-facing features, it fails for obscure architectural limitations like tool output truncation because users are unlikely to find and read the message.state.output which is inaccessible to the DOM itself, let alone the front-facing UI.

LLMs do not say "I did not read the full thing" or "My response is based on a truncated reading", it will either:
- respond based on incomplete data - resulting in the user believing the agent gave a 'dumb' or incorrect answer, leading to re-prompting (and a wastage of tokens)
- it'll attempt to bypass the limit on its own, in many cases, writing python scripts to parse the file, executing them, hitting syntax & run time errors, and recursively solving them (massively wasting tokens).

This isn't just beneficial to users. OpenCode pays for DeepSeek v4 Flash and similar models, if they want to reduce their costs, increasing the truncation limit or providing configurability would do just that. As it reduces the unnecessary wastage of tokens, as discussed earlier, via re-prompting or unnecessary recursive python debugging just to read a file.

Just watched it struggle with writing a python file

Its Struggle

I see - the write tool truncated at 2000 lines/chars. The file got cut off in the middle of a string. I need to delete this partial file and write the complete one differently. Let me write it as a proper Python script that generates the markdown, but break it into smaller pieces or use a different approach entirely.

Actually, let me just delete this incomplete file and rewrite it properly. The issue is that the content was too long for a single write call. I'll need to either:

Write it in parts using edit (append)
Use bash/python to create the file
Keep the script shorter
Let me use python via bash to write the complete file since I can't pass the full content through the write tool due to length limits.

So It's not sure what the issue is, just that when its writing / checking its not matching up

Its Struggle

The Right Approach I Should Have Taken

Write the script in 2-3 medium-sized files using only write (no editing), keeping each under ~1800 chars. No shell commands for file writing at all — just write + edit. That way there's no escaping nightmare and no partial writes to debug.

Its Struggle

Good, 58 lines written. Now I need to create additional files that import from _core and generate the rest of the markdown. Let me create _static.py with hardcoded static table rows, then _inventories.py for the dynamic parts, and finally regenerate.py to tie it all together.

But wait - this multi-file approach is getting overly complex. Let me reconsider...The real issue is that I can't write more than ~2500 chars in a single write call. The generator script needs to be much longer than that.Let me try a different strategy: use the edit tool's replace feature to ADD content after the last line of _core.py. Each edit will add a small section.Actually, edit replaces strings - it doesn't append. But I can replace the file ending with itself plus more content.

Its Struggle

OK this is getting extremely tedious - every write gets truncated at ~80 lines / 2500 chars because my Python code has long lines and the tool truncates mid-content.I need to completely abandon the approach of trying to write a comprehensive generator script through these tools.

So many 1000's of tokens wasted, If it just knew the issue and stopped I new method could of been suggested.

FWIW, here's my current solution / workaround for my situation.

I'm doing a lot of data manipulation and analysis. Long story short, even after condensing, one of the files in working on is 32k lines and 2 million characters long - 2KB in file size.

After a day of struggling with the LLM through it's python scripts. I decided I struggle one last time and get it to split the 2KB file into 45 files of <50 KB.

After doing that, it practically blizted the task I set for it (in comparison, at least). And with a much higher accuracy.

Same content, same task. But 45 files ranging from 16-50 KB (and 1 72kb exception) rather than 1 file 1866KB. Millions of tokens saved.

However, this will not work in all cases. Being able to configure the max file size is the one solution to this problem of unnecessary wastage of tokens, and thus OpenCode's own money.