The Hidden Cost of Claude Code — And Why People Keep Paying It

A breakdown of where your token budget actually goes, and why reliability still beats efficiency for most developers.

If you use Claude regularly — chat, Claude Code, or both — you've probably hit a usage limit at a moment that felt completely unreasonable. Not after hours of heavy work. Sometimes after a handful of messages. The frustration is real, and it's not just you: there's a structural reason behind it, and it has a lot to do with what happens before your prompt is even read.

An independent benchmark run by the team at Systima placed a logging proxy between Claude Code and OpenCode, two coding harnesses running the exact same underlying model, to measure byte by byte what actually travels to Anthropic's servers. The simplest possible task — a one-line answer — cost Claude Code roughly 32,800 tokens before it had processed a single word of the user's request. OpenCode, same model, same task: 6,900 tokens.

Where does the gap come from. Claude Code loads a system prompt of 27,344 characters split across three blocks, plus tool definitions — 27 of them — that alone weigh close to 100,000 characters. OpenCode gets by with one block of 9,324 characters and ten essential tools. Even stripping out every tool, Claude Code's bare system prompt still runs around 6,500 tokens, more than triple OpenCode's 2,000. That's not tooling overhead anymore. That's pure behavioral doctrine — tone rules, safety instructions, task management logic — baked into every single call.

Subagents are where the bill really explodes

Delegating the same job to two parallel subagents pushed Claude Code's token count from 121,000 to 513,000 — a 4.2x multiplier. The reason is almost embarrassingly simple: every subagent re-reads its own system prompt and its own tool definitions from scratch, on every turn. Nobody caches that for you.

And then there's the cache problem, which is honestly the part I find most interesting. Prompt caching is supposed to be the thing that saves you money — you pay full price once, then subsequent calls hit a discounted cache read. Except Systima found that Claude Code rewrote its cache mid-session repeatedly, in some captured sessions up to 54 times the cache-write tokens of OpenCode on the identical task. Three distinct request patterns, each with its own cache prefix. Three prefixes competing for the same context. That's not a rounding error, that's an architectural choice with a real cost attached.

Worth noting, though — and this is the part a lot of quick takes on this study skip — the gap isn't constant. On a multi-step coding task (write, run, fix), Claude Code closed the job in 3 requests by batching tool calls into a single parallel block, while OpenCode needed 9 sequential ones. Total tokens: roughly 121,000 versus 132,000. Almost a wash. The overhead story is real, but it's not the whole story.

It's not only Claude Code. It's the whole account.

Here's the detail that matters most if your frustration is really about Claude.ai and not specifically about the CLI tool: usage on paid plans runs on a shared pool. Chat conversations, Claude Code sessions, and Cowork all draw from the same allowance — burn tokens in one surface, you lose capacity in the others. A long afternoon of coding in the terminal can leave you with almost nothing for a chat conversation an hour later, and vice versa.

The system works on two layers. A five-hour rolling window opens with your first message of the day and covers everything until it resets. On top of that sits a weekly cap — one for all models combined, one specifically for Sonnet-class models on Max plans — that resets on a fixed day and time tied to your account, regardless of when you started using Claude that week. Anthropic doubled the five-hour Claude Code limits on May 6, 2026, and removed the reduced allowance that used to apply during peak hours. Before that date, plenty of the advice floating around online about "how many messages you get" was already stale.

What actually eats your allowance, beyond raw message count: conversation length, file attachments, tool usage — web search, research, connectors — model choice, the effort level you've selected, and artifact creation. Caching helps more than people realize. Content stored inside a project doesn't count against your limit when reused, and Claude retains context from earlier in the same conversation without re-billing it every turn. If you're not using projects for recurring work, you're leaving savings on the table.

Context window size depends on the model. On paid plans, the newest models support up to 1 million tokens; others sit at 500K or 200K. None of that is your daily message allowance, though — length limits and usage limits are two separate mechanisms, and mixing them up is the single most common source of confusion I see when people complain about "running out of tokens." One governs how long a single conversation can get. The other governs how many conversations you can have before a reset.

So why does everyone still reach for Claude Code anyway?

Because the token bill and the actual outcome are two different questions, and most developers care a lot more about the second one. In the same benchmark, a ten-session quality run gave both harnesses the identical result — 5 out of 5 tasks passed — while the average cost per session landed at 268,000 tokens for Claude Code against 72,000 for OpenCode. Same quality. Wildly different price. And people keep paying the higher one.

My honest read, after watching this debate play out in developer forums for weeks now: the premium buys predictability, not intelligence. A developer running full-stack workflows across an eight-repo workspace, twelve hours a day, isn't optimizing for token efficiency — they're optimizing for not getting surprised mid-task. Parallel tool-call batching, diff verification before commit, orchestration that doesn't require babysitting. That's worth paying for, until the day it isn't.

Whether that calculus holds for lighter, occasional use is a separate question — and probably one where the answer is no, or at least not obviously yes.