I ran a small practical comparison between TokenSave and the standard OpenCode tools to see whether TokenSave actually improves speed and reduces context usage on a large Java codebase.
Test Environment
- MacBook Pro M1
- 16 GB RAM
- Lima Ubuntu
- OpenCode 1.18.9
- GPT-5.5
- Multi-project Java codebase
- 300k lines of code
The same task was executed twice:
- Using only the standard OpenCode tools
- Using only TokenSave
The task itself was a focused codebase exploration request involving one controller and its related dependencies and tests.
Results
| Metric | Without TokenSave | With TokenSave |
|---|---|---|
| Execution time | 1:28 | 1:15 |
| Context size | 41,926 tokens | 49,535 tokens |
| Response quality | Slightly better | Slightly lower |
TokenSave reduced execution time by 13 seconds, which is approximately a 14.8% improvement.
At the same time, context usage increased by 7,609 tokens, or approximately 18.1%.
Observations
The standard OpenCode run produced a slightly more complete answer. It discovered more surrounding details while using fewer visible context tokens.
The TokenSave run was somewhat faster, but required more tool calls and produced a slightly narrower result.
This suggests that the indexing and code navigation features provided by TokenSave can reduce lookup time, but the additional tool interactions and metadata may offset the expected token savings.
Conclusion
OpenCode’s built-in tools already appear to be sufficiently optimized, even on a multi-project Java codebase with approximately 300,000 lines of code.
In this test, TokenSave made the task slightly faster, but used more context and produced a slightly less complete answer.
The overall practical advantage was therefore limited.
This is only a single test, not a comprehensive benchmark. Results may differ for broader architectural analysis, repeated queries, or much larger repositories.
Top comments (0)