I've been writing code since 1986, which means I've lived through enough "efficient" tools that turned out to be nothing of the sort. So when I read this breakdown on Hacker News comparing the token overhead of Claude Code against OpenCode, I felt that familiar itch. Someone's finally counting the beans properly.
The numbers are stark. Claude Code apparently ships around 33,000 tokens of system prompt and tooling scaffolding before it's even looked at your actual question. OpenCode does the equivalent job in roughly 7,000. That's not a rounding error, that's a five-fold difference in overhead for essentially the same category of task: an AI agent helping you write or edit code.
Why This Matters More Than It Sounds
If you're a hobbyist firing off the odd prompt, this is academic. But if you're running anything at scale, and I include myself here with the Masher suite, this overhead compounds fast. Every API call carries this baggage whether you asked for it or not. Multiply that by thousands of automated content generations, article rewrites, or video scripting jobs a day, and you're paying for scaffolding you never see and rarely benefit from.
This is the bit that gets glossed over in most AI tool marketing. Everyone talks about model quality, context windows, benchmark scores. Nobody wants to talk about the plumbing costs baked into every request before your prompt gets a look in. It's a bit like buying a car and discovering the fuel gauge doesn't count the diesel burned idling in the car park before you've even turned the key.
The Alchemy Problem: Turning Overhead Into Gold, Not Waste
I built the Masher tools on a simple principle: raw content in, valuable content out, as efficiently as possible. Every token spent on overhead is a token not spent on the actual transmutation happening in your pipeline. When I'm architecting anything that calls out to an LLM repeatedly, whether that's RSSMasher chewing through feeds or Article2Video turning a blog post into a script, I'm constantly asking what percentage of the token spend is doing real work versus what's just system tax.
The uncomfortable truth is most developers don't check. They pick a tool because it's popular or because the docs are slick, and they never audit what's actually going out the door on each call. If you're building anything usage-based, that's a mistake you can't afford to make twice, because by the time you notice your margins have evaporated, you've already burned through a client's trust as well as your budget.
What To Actually Do About It
A few practical things I'd suggest to anyone running AI-driven automation:
Log your actual token usage per call, not just the aggregate. Most platforms give you a breakdown if you look. If you're not looking, you're flying blind.
Test alternatives before you commit to a stack. The Claude Code versus OpenCode comparison is a good reminder that "better known" doesn't mean "leaner." Sometimes the less flashy tool is doing the job with a fraction of the ceremony.
Question every system prompt you didn't write yourself. If a tool is injecting 30k tokens of instructions and tool definitions before your content even starts, ask why. Sometimes it's justified. Often it's legacy bloat nobody's bothered to trim.
Build your own thin wrappers where it counts. This is exactly why I keep a lot of the Masher pipeline logic close to the metal rather than leaning entirely on someone else's agent framework. Control over the prompt is control over the bill.
The Bigger Picture
This story is a symptom of something wider in the AI tooling world right now. As agents get more capable, they're also getting heavier, wrapped in more instructions, more guardrails, more scaffolding to make them behave reliably. Some of that overhead earns its keep. A lot of it doesn't, and it's the user footing the bill either way, in dollars or in dollars per second of latency.
If you're building products on top of these models, the token overhead isn't a footnote, it's a line item. Treat it like one. Audit it the way you'd audit any other recurring cost in your business, because at scale, invisible waste has a nasty habit of becoming very visible indeed on your invoice.
Efficiency isn't glamorous, but it's the difference between a tool that scales profitably and one that quietly eats your margin while everyone's busy admiring the demo.
— Wayne