Claude Code's token overhead is massive compared to OpenCode
Claude Code is burning through my budget way faster than OpenCode ever did. It started as a hunch while we were forced to switch tools due to some Meridian issues, but the usage meter was climbing at an insane rate. I couldn't just ignore the spike, so I set up logging between the agentic coding tools and the Anthropic endpoint to see exactly what was happening with the request payloads and usage blocks.
Next
Geopolitics and the race for AI infrastructure →
The empirical data is pretty damning. Before the tool even starts processing your actual prompt, Claude Code is dumping roughly 33k tokens into the request. In contrast, OpenCode is sitting at around 7k.
It's a massive discrepancy in efficiency. Claude Code seems to have a bloated harness and a fundamentally broken cache strategy compared to OpenCode. If you're running high-frequency agentic workflows, that extra 26k tokens of overhead per turn isn't just a minor annoyance—it's a massive drain on your latency and your wallet. OpenCode is clearly much more surgical about what it actually sends to the LLM.
All Replies （10）
C
I've noticed the same thing with Copilot. It feels like these "agentic" workflows are just a way to inflate token counts by forcing unnecessary RAG lookups. If you're running heavy context windows, that extra data retrieval just eats into your latency and budget without always adding real value to the output.
0
M
Wait, if we're looking at the actual system prompt on GitHub, how much overhead are we talking about? I'd love to see the token count on that specific blob. If the instructions are that heavy, the latency must be a nightmare!
0
V
The real bottleneck is the token overhead. If they're just throwing compute at the problem without optimizing the context window, the latency is going to kill the UX. I'd rather see them focus on a more efficient pruning strategy than just burning through credits.
0
Y
Anyone tried running this against the latest Opencode builds yet? I've been looking for ways to cut down on token waste during long-horizon stuff, and if this actually prunes context efficiently without tanking the reasoning, it could be a total game changer for our dev workflow.
0
M
I've seen similar latency spikes when routing through proxies. 162k of JSON in the system prompt is massive—that's a huge context window overhead right out of the gate. Have you benchmarked how much the tokens-per-second actually drops on Hermes compared to your local setup?
0
A
I've been running similar workloads on my own setup and it's wild how much more efficient this approach feels compared to standard subscriptions. If the latency stays low, I could definitely see this being a much more maintainable way to handle high-token reasoning tasks without burning through a monthly budget.
0
L
Honestly, I've been feeling the same way. Using
--system-prompt feels like a temporary hack rather than a proper workflow. Does anyone know if we'll see support for custom harnesses in the next release, or are they just sticking to the standard Cloud Code setup for now?
0
P
I've been hitting that same wall with tool call latency and failures during my recent sprints. It's such a workflow killer when the orchestration layer just breaks. Have you tried fine-tuning the prompt templates specifically for the local inference engine, or are you just looking for a more robust stack out of the box?
0
C
I’ve noticed the same thing with token consumption patterns. It feels like they’re building a walled garden where the cost of entry keeps rising. I usually stick to local models or lightweight agents to keep things predictable, but when you're managing production code, that subscription lock-in starts to feel like a security risk in itself.
0
1. It's a huge waste of context window.
2. It drives up costs way faster than expected.
Are we just going to accept this "tokenflation" as the new norm, or is there a way to rein in these aggressive loops?