If I let the main agent do the same task sequentially, it was no problem at all. I don't know if it's really just communication and orchestration that makes sub agents so inefficient, or if Anthropic figured that most people using sub agents pay per token on a big corporate account, so this is an easy way to make more money from tokenmaxxers.
If you do it sequentially you only read those files approximately once, and everything hits the same prefix cache
https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...
Tokenflation seems very real: the number of tokens consumed by simple tasks keeps increasing.
I don’t like that Claude became more opaque around February, including the system prompts. 33k feels way too much.
My $20 sub using gpt 5.6 sol thinking-off lasts for hours using pi.
I used mitmproxy (setup assisted by Claude, natch) to capture Claude Code's entire initial system prompt and the whole thing was (I just double-checked) 162k of JSON.
This led me to start experimenting with Pi, OpenCode, and Hermes...
What matters even more is tooling quality. Bad/buggy tooling causes a lot more roundtrips that wipes out all gains from initial greedy approach.
A few months ago, I did a full benchmark run of 7 agents over 8 tasks (https://github.com/dirac-run/dirac has the data and traces). I cannot claim neutrality because of the obvious connection to one of those, but the data should be reproducible and useful. Importantly, Dirac wins there significantly on those tasks because they are mostly refactoring related (which is where approaches like hash-anchoring and AST parsing tend to shine)
We already know company is not making any profit. To break even they need ppl to use a lot more tokens AND pay for them premium price.
We also know LLMs dont give such a huge productivity boost do warrant spending of THAT size.
At this point you only wait for more and more shady plays.
This is posed as some sort of discovery, but both Claude Code and OpenCode display token usage clearly after starting a chat or agent, and 30k and 7k is exactly what you see.
Also, I have seriously used most harnesses - One feels like it's being built in a place that truly understands AI and where agentic engineering is headed. You might not like it, but peak performance exists in CC when it comes to orchestration of bulk parallel work / subagents. The open source agents are catching up or accell in different way (Im preferable to pi.dev), but I'm not sure they're architecting orchestration the right why.
I know you can give instructions to guide an agent, but they are still plain English, the interpretation still isn't absolute and the more rules, the less likely it is to respect the whole set of rules in the preamble, but the whole process seem so... "Unprofessional"?
As I see it, a tool should be reliable and the less bloat, less possible points of failure.LLMs seem overly verbose and you can't shake the feeling it might veer away from the objective at any point. You can pay to mitigate or work around the risk, but it still doesn't inspire confidence in anything with more than 30 lines
I switched to the PI CLI and have no problems with hanging processes anymore. OpenCode Go allows for API access so I'm keeping this sub.
The only interesting thing is whether OpenCode is more effective at writing code with it's reduced system prompt.
Is that true? My understanding is that the subagent only returns the result of the request without the main agent consuming its entire transcript.
Claude code seems to have a pretty robust harness and memory. It's a time saver to not include project context in our prompt, since Claude manages claude.md but I haven't used OpenCode to compare.
Wouldn't be surprised if you're paying full price for those tokens, but they cost ~$0 for the provider.
https://github.com/asgeirtj/system_prompts_leaks/blob/main/A...
1) We have added a repository reproducing the methods.
2) We have commented on output quality in the post (in addition to tokens/cost).
3) Per a previous update, we now handle Fable 5 in the post.
Remember is it not OpenAI vs Anthropic as bad guys vs good guys. They are all bad guys trying to profit from your data while maximizing dependency. Just buy or rent GPUs.
If you’re using API, on the other hand, there is absolutely no reason to use Claude Code, or Codex.
This is why the subscription plans are forced through the harness (the "OpenClaw Wars"): it creates a false equivalence in the minds of many customers between API tokens (latency sensitive, easy to measure) and Claude Code tokens (remnant backfill to stay to the right of the roofline, marginal cost often zero).
Selling sausage as sirloin is a great business if people go for it. And there's nothing inherently wrong with spot pricing, as long as you're honest about it...
Are we measuring and caring about the right thing?
The entire agent system prompt can be seen here:
https://github.com/earendil-works/pi/blob/main/packages%2Fco...
I asked both a trivial question (summarize last commit). Opus cost 50 cents, Fable about $1.
That checks out because Fable's twice as much in the API (though I think its emphasis on correctness makes the difference larger for bigger tasks).
But, at $1 per question, I think I will stick to the subscription for now! I was certainly glad GPT-5.6-Sol is included in OpenAI's subscription, and I'm curious if they'll be able to do the same for GPT-6.
All the VC money appears to have run out a few weeks ago.
After reading PUSH_AX's valid comment: ``` This is like saying contractor (A) asked for $33,000 to undertake the work and contractor (B) asked for $7,000 Are we measuring and caring about the right thing? ``` We will update the post to include:
1) A more in-depth task. 2) Qualitative results comparison. 3) As soon as possible, a reproduction of the inputs and outputs.
In our case the alternative was nothing so I'm happy to have it, but currently claude is not as competitive as I'd have maybe expected given the hype
In a pay per token situation, there is a huge conflict of interest with the harness provider and the token seller being the same party ... efficiency is less profitable.
I have accused claude code of trying to run up the meter on me and it confirmed I was absolutely right.
So not only is this article AI-written, but the testing was entirely done by AI, too? I can't see any other reason to use such an old model.
> Our traffic passes through a local LLM gateway that wraps requests in its own envelope, a constant we measured at roughly 6,200 tokens with bare calibration requests
Why do you need to do calibration requests to figure out how your own gateway is affecting requests?
> Its subagent lane did not complete cleanly through our gateway
> We attempted to toggle extended thinking in both harnesses and are declining to publish numbers. Our gateway applies its own thinking policy, neither harness's toggle demonstrably survived the path, and anything we quoted would be noise.
Why is your own gateway screwing with your testing?
It works great for long-horizon tasks, and feels like it saves a boatload of tokens.
If you plan on continuing on in the parent, and aren't going to necessarily be touching the systems the other agents are exploring, it can be worth it.
It's useful in certain situations where the parent context may need the "10,000 foot" view of something without going back in there. But subsystem-specific AGENTS.md/CLAUDE.md files are still superior and accomplish the same thing. The problem with those is they can become stale.
Yesterday, I wanted to review a complex piece after a large refactoring, and requested a review plan beforehand. The first step was 8 agents + one more to verify the findings (all Fable). Looks good, approved.
The verification step turned into an attempt to throw a party with 41 Fable verifiers.
It will find a way.
That said, if your project is "do this well-planned thing on a bunch of things in parallel" then you should absolutely be instructing to have subagents "step down" to less curious models. Their output may well be more cohesive as a result!
Probably because the general purpose subagents inherit the parent model.
I tell Claude explicitly to use Explore subagents, which use Haiku only, now.
"permissions": {
"deny": [
"Task(Explore)"
]
}I read that this is because it wastes time looking through past conversations and other context to figure one what you might want it to do - a less ambiguous prompt would be better.
I appreciate that Codex is open source and OpenAI has explicitly said using the subscription with other agents is ok. OpenAI has been much more consumer-friendly recently.
That'll be $50 — please.
im on local only AI and subagents are only valuable when they avoid polluting the context with extraneous file reads and parallel exploration when fixes are linear.
as OP is on about, subagents burn tokens because they arnt a deterministic intelligent gatherer but like pooluring water into a maze hoping the exit will illuminate.
only if you don't specify which model should be used
When using Pi, one way to significantly reduce input tokens it yields is to ignore common bookkeeping "dot directories", such as `.git`. How to do so can be found with the following interactive Pi prompt:
How do I configure Pi to ignore git related artifacts, such
as the project's .git directory?
Other local assets to consider ignoring are `.pi`, `.agents`, `*.md`, and language specific output directories such as `__pycache__`, `bin`, `obj`, `target`, etc.I haven't tested it on anything bigger but it doesn't seem to do the kind of proactive testing, that they do in bigger harnesses.
Codex at least has a system prompt that tells it not to consider a feature a complete until it has verified it. I'm not sure about Claude Code.
I suppose I could add that one line to the prompt, and it would get me much closer to agi :) I think Fable does this proactively even without a prompt, but I haven't tested that yet.
If Fable in my own harness is significantly cheaper than Claude Code, that would be very appealing. (I could actually afford to use it for most things!) But I think most of the cost comes from the testing it does. So we'll have to see.
If you don't use a subscription, and pay per token instead, you can easily move to another harness.
Ultimately this combo worked:
1. https://pi.dev/packages/pi-tool-guard —- corrects key name synonyms and common structure errors, so tool calls succeed automatically (e.g if the model hallucinates old_str instead of oldText). It also wraps top level oldText/newText in an edits array if the tool didn’t do it.
2. https://pi.dev/packages/@aboutlo/pi-smart-edit - white-space-tolerant edits, as Qwen would sometimes add a fifth space to a four space indent
Hashline edit tools didn’t work well for me at all, they confused the model and it still failed to edit correctly. Also line removals would invalidate the rest of the file requiring re-reads. I tried pi-hashline-edit-pro, though I see it now keeps a database of hashes to help keep them stable across edits. Regardless Qwen kept thinking that the hashline prefixes were part of the source.
> When context gets too long, maki compacts history automatically: strips images, thinking blocks, and summarizes older turns.
Don’t the summaries of older turns effectively invalidate the context cache, such that you consume less tokens but more expensive tokens?
> CRITICAL: Do NOT spawn sub-agents for any reason. Perform all work in the main session. If a task is too large, ask me to break it down manually.
> This is a big task, and can easily get too large. However, sub-agents make the situation worse, and eat through our token budget way too fast. Do not use them.
> Take on manageable tasks. Don't try to do everything at once. When you start on a big task, break it down into smaller tasks, and make sure you finish each task before starting on the next one.
Or actually Claude put it there for me. Maybe it's a bit much, but it seems to work.
Unless they are orthogonal they most likely require similar context anyway so multiple sub agent is just wasteful.
Opus 4.8 (1M context)
claude-opus-4-8[1m]
23k/1m tokens (2%)
Estimated usage by category
System prompt: 3.9k tokens (0.4%)
System tools: 13.9k tokens (1.4%)
Custom agents: 235 tokens (0.0%)
Memory files: 28 tokens (0.0%)
Skills: 4.9k tokens (0.5%)
Messages: 8 tokens (0.0%)
Compact buffer: 3k tokens (0.3%)
Free space: 974k (97.4%)
4k tokens is 15-20kB. I'd ask you to paste that into a gist, but it might have sensitive data in it, because I suspect what you're seeing is not just the system prompt.Or are you saying my sub agents burned so many tokens because they were all using Fable, whereas my main agent could do the same job with a lesser model?
Using VS code if it matters.
https://code.claude.com/docs/en/changelog#2-1-198
> The built-in Explore agent now inherits the main session’s model (capped at opus) instead of running on haiku
Doesn't the model need at least a basic system prompt to understand what tools are available?
Therefore, you should include the actual costs associated with the task in API token usage or subscription level. Is there a reasonable way to do apples to apples cost comparison?
Qwen 3.6 35B A3B and Qwen 3.6 27B can both do reliable tool calls on Pi at Q4_K_M using llama.cpp
I guess the cache would only be invalid if the day changed or the root directory, which would technically happen infrequently enough.
I mean, that's a very weak argument? Isn't a much more plausible explanation that with your tooling you'll have more of a lock-in than with just your model?
OTOH, this makes typical subscriptions usages consume more tokens, which are included in their flat fee.
This sounds more like incompetence than malice.
Competition is good.
Edit: consumer Claude subs are the 5%. I’d bet most all of CC subs lump in under enterprise.
- API & Enterprise: 75% to 85% of total revenue.
- Business Subscriptions: Roughly 10% to 15%.
- Individual Subscriptions: About 5%.That would depend entirely on what your device is. This sounds likely not to be an issue with the harness, but the capabilities of the models you've tried.
I experience almost no tool call failure using my nothing-special harness and DSv4 Flash.
Not sure if intentionally meant as a reference, but it gives "I use Arch btw" vibes.
and the interesting thing about system prompt wastage is its a cost that scales non linearly with subagent use.
I wonder if a lot of the 33k is context, like from recent conversations.
Cost, mainly. The runs went through a Claude Max subscription rather than metered API billing, and pinning an older stable snapshot kept run-to-run comparisons clean and cheap. The fixed harness payload (system prompt plus tool schemas), so the headline numbers shouldn't change too much.
That said, happy to re-run the matrix on Fable and publish the diff; payload figures should barely move, tool-calling behaviour might.
Gateway:
Meridian (github.com/rynfar/meridian); proxy that bridges the Claude Code SDK to a standard Anthropic endpoint so a Claude Max subscription can drive OpenCode-et-al.
It's the auth route for all agent traffic on the machine, not something built for the benchmark.
I find it hilarious people think they can build on slop or on captured output from quality engineers. Intent is the most important aspect, and no code base could ever capture that
-- note: I've been full time in Beolis for some months already, feedback welcome ;)
I vaguely understand you argument with the context, however is that not solved by sum agents handing their results in to the planner (or a third agent) to run on them again? I'd assume that's what is happening anyway. Let me know if that's wrong
> In version 2.1.63, the Task tool was renamed to Agent. Existing Task(...) references in settings and agent definitions still work as aliases.
1. Agent("Test")
2. look at your token usage
3. Repeat a few times
I didn't check again as I type this message but am somewhat sure subagent doesn't cache system prompt as of maybe last week
But I'll investigate how that works in a session. You got me curious.
Anthropic even changed this silently: https://www.reddit.com/r/ClaudeAI/comments/1sk3m12/followup_...
Except there’s a competitive incentive to either use less tokens or make the tokens go further
I'm generally against this context pruning without prompting or details. Sleev is very opaque about how it works and definitely will bust your cache.
I am a bit surprised that you're disappointed that it does exactly what you told it to - people usually have the opposite complaint.
If you're using it interactively and watching what it changes, I'd trigger the tests when you think it's needed. And if you want to go more hands-off, why not add try to encode the same nuance you'd use into the rule?
A major complaint with AI code was that AIs struggle with complex codebases, don't respect existing conventions, reinvent functionality multiple times over, etc. So, newer high end AIs are tuned with the "explore/exploit" dial turned towards "explore".
You could probably get it to do things "quick and dirty" with prompting, but that, of course, requires prompting for it.
I write a good prompt, paste the code then copy the output code and place it into my project.
So in the end I hand assemble and I only give it what it needs to know so no extra context wasted.
The human in the loop is of course the secret sauce but this way I am highly efficient, no vibecode and I work really fast too. Everything is audited.
You could probably engineer your own harness or workflow to warm the cache by running a single warmup agent, but this is not at all how the tools behave out of the box. It's mostly a cost optimizaiton, so Anthropic really don't have any incentive to do it proactively, and if they did, surely they would want to tell their customers how much they were saving?
I was simply supporting the article's data - their reported 33k tokens is probably roughly 150-165k.
On the other hand, the newer variants also tend to benchmark higher so it's not quite a clean argument of "hey the new version eats more tokens"
At this point I think Dario is just in his wellness retreat adjusting a revenue/profit dial.
Every time I read this comments I have the feeling you are talking about mcp or sub agents, otherwise this makes no sense at all.
What do you miss? I ask because I do some heavy work with pi + GLM 5.2 (using opencode Go subscription) and my workflow is plan -> implement.
no amount of alignment will stop aomeone drom just shutting up.
They get lock-in, and through that lock-in are more effectively able to inflate token usage.
To remind Goodhart's law: "When a measure becomes a target, it ceases to be a good measure".
..also to parent's point, yes the upsell is only appealing once user run's out of tokens.
I don't fully agree with the premise that they intentionally increase system prompts, but the enterprise plan usage is going to make that a huge income for Anthropic.
We put Claude Code and OpenCode on the same model, the same machine, and the same tasks, then examined everything sent and received.
Be the first to know when we publish original research or thought pieces on AI and quantum governance. NOTE: To reach out, please "Book a call" instead.
No spam. Unsubscribe at any time.
Claude Code is far hungrier:
When we asked both harnesses for a one-line reply, Claude Code used roughly 33,000 tokens of system prompt, tool schemas, and injected scaffolding before the prompt even arrived. OpenCode used about 7,000.
Claude Code is far more cache inefficient:
OpenCode's request prefix was byte-identical in every run we captured; it paid to cache its payload once per session and read it back for pennies.
Claude Code on the other hand re-wrote tens of thousands of prompt-cache tokens mid-session, run after run, and on the same task wrote up to 54x more cache tokens than OpenCode.
Cache writes of course are billed at a premium, which accounted for the usage dashboard climbing when using Claude Code.
Config further bloats the prompt:
A production repository's 72KB instruction (AGENTS.md or CLAUDE.md) file adds another (avg) 20,000 tokens to every single request. Five modest MCP servers add 5,000 to 7,000 more. By the time a real working setup sends its first request, it is 75,000 to 85,000 tokens deep before the user has typed a word.
Subagents add to the cost:
A small task that cost 121,000 tokens done directly cost 513,000 tokens when fanned out to two subagents. This is because each subagent is its own agent that re-reads its own system prompt and tools on every turn it takes, so a fan-out multiplies the number of full baselines in flight.
Having said that, the parent ingests only each subagent's returned result, not its whole transcript.
We found one result in favour of Claude Code:
On a multi-step task Claude Code's whole-task total came out lower than OpenCode's, because it batches tool calls into fewer requests while OpenCode re-pays its smaller baseline turn after turn. The meter starts higher; how the session unfolds decides who spends more. That advantage held on the first model we tested; re-run on a newer one, the same task took twice the requests and cost roughly 298,000 tokens against OpenCode's 133,000.
Every finding above was cross-checked on a second model family. The pattern held, with one nuance we cover below.
The rest of this post shows how we measured all of this at the API boundary, where the tokens go, and what prompt caching does and does not save you.
Every token of harness payload is a token of working context you cannot spend on your task.
If you operate agentic AI in production, particularly under the EU AI Act where Article 12 expects you to log and understand your system's behaviour, "what does my agent actually send" is a question you should be able to answer with data.
We spliced a logging proxy between each harness and the model endpoint.
harness (Claude Code / OpenCode)
→ logging proxy (captures request payloads + response usage)
→ model endpoint
The proxy records two things per request. The first is the exact JSON payload the harness emitted, meaning the system blocks, tool schemas, and messages. The second is the usage block the API returned, covering input tokens, cache writes, cache reads, and output tokens.
The payload capture is ground truth for what the harness sends. The usage block is ground truth for what was metered.
We tested under these conditions.
claude-sonnet-4-5, July 2026. A reduced matrix (the floor, the cache task, and the multi-step task) was later re-run pinned to claude-fable-5; where the model changed the result, we say so inline.--tools "" and OpenCode with "tools": {"*": false}, separating system prompt from tool schema weight.One full disclosure note before the numbers:
Our traffic passes through Meridian, a local gateway that bridges the Claude Code SDK to a standard Anthropic endpoint so a Claude Max subscription can drive third-party tools. It wraps every request in the SDK's own envelope, a constant we measured at roughly 6,200 tokens on the Sonnet path and 3,500 on the Fable path with bare calibration requests and subtracted from every metered figure below.
Payload-level figures come from the captured request bodies, which the gateway cannot affect, and are exact.
Character-to-token conversion for component estimates uses each harness's own measured ratio of 4.1 to 4.4 characters per token, derived from cold-cache anchors where the metered write equals the full payload, rather than a generic heuristic.
The task was 22 characters. Here is what each harness sent with it on its first request.
| Component
|
Claude Code
|
OpenCode
| | --- | --- | --- | |
System prompt
|
27,344 chars, 3 blocks
|
9,324 chars, 1 block
| |
Tool schemas
|
27 tools, 99,778 chars
|
10 tools, 20,856 chars
| |
First-message scaffolding
|
7,997 chars of <system-reminder> blocks
|
none
| |
The actual prompt
|
22 chars
|
22 chars
| |
First-turn payload (calibrated)
|
~32,800 tokens
|
~6,900 tokens
|
OpenCode's request is close to minimal. There is one system block that opens with "You are OpenCode, the best coding agent on the planet", plus ten classic coding tools, plus the user's prompt as the only content.
Claude Code's request is a platform bootstrap. The 27 tools include the coding core plus an entire background-agent and orchestration suite, from CronCreate and Monitor to the Task family, worktree management, and push notifications.
Before the user-entered prompt, its first message carries three injected reminder blocks; a catalogue of agent types for delegation, a catalogue of available skills, and user context.
Tool schemas are the dominant term for both. Roughly 24,000 of Claude Code's ~33,000 tokens are tool definitions, versus roughly 4,800 of OpenCode's ~6,900.
Stripping the tools isolates the system prompt itself. Claude Code's weighs in at 26,891 chars, about 6.5k tokens. OpenCode's is 8,811 chars, about 2.0k tokens.
Both harnesses trim their prompt slightly when tools are disabled. Even with no tools at all, Claude Code's instruction set is over three times the size of OpenCode's; the residual is behavioural doctrine, meaning tone rules, safety guidance, task-management instructions, and environment description.
T2 asked each harness to read a file and summarise it. Both produced correct summaries.
Claude Code took 6 HTTP requests and roughly 199,000 cumulative metered input tokens. OpenCode took 4 requests and roughly 41,000, plus one Haiku side call for session titling.
Most of those tokens are cache reads billed at a tenth of the input price. Three things scale with payload regardless; the first-turn cache write, the per-turn read, and context-window consumption, which no cache discount reduces.
A 33k-token baseline means every turn starts a sixth of the way into a 200k window before any code enters the conversation.
T3, the write-run-test-fix loop, inverted the expectation set by the baselines.
| Metric
|
Claude Code
|
OpenCode
| | --- | --- | --- | |
Model requests
|
3
|
9 (+1 title call)
| |
Tool-calling style
|
parallel batch in one round trip
|
one tool call per turn
| |
Cumulative metered input
|
~121,000 tokens
|
~132,000 tokens
|
Claude Code batched the entire job, two file writes and two script executions, into a single parallel tool round trip. OpenCode made exactly one tool call per turn and took nine.
Because the baseline is re-sent on every request, request count multiplies baseline. OpenCode paid its ~7k baseline nine times, Claude Code paid its ~33k three times, and the totals converged.
Whole-task input roughly equals baseline times request count, plus conversation growth. A large-baseline harness that batches aggressively and a small-baseline harness that serialises can land in the same place.
Two structural details emerged from the payloads:
<system-reminder> block as the conversation progresses, three on the first turn and four by the first tool round trip, so its scaffolding grows with turn count.We re-ran the floor on Claude Fable 5 to check whether the gap was a Sonnet artefact, and it shrank (which we didn't expect).
Claude Code's system prompt is model-conditional. It sent 27,787 chars of instructions to Sonnet but only 10,526 to Fable, with tool schemas also trimmed from 99,778 to 82,283 chars. Same 27 tools, much less doctrine.
OpenCode's payload was byte-identical across both models.
The floor gap on Fable comes out at roughly 3.3x by payload against 4.7x on Sonnet. Still far hungrier, but the ratio is model-dependent.
The multi-step convergence did not survive the change either:
On Fable, Claude Code took six requests instead of three, including an 85,686-token mid-session cache re-write, and landed at roughly 298,000 tokens against OpenCode's 133,000.
Therefore the batching advantage is model behaviour, not a harness constant.
These lanes also produced OpenCode's only mid-session cache write in the entire study, a single event of roughly 6,000 tokens; everything else it sent stayed byte-stable.
One served-model note belongs here:
Under Fable we received responses alternately as claude-fable-5 and claude-opus-4-8, consistent with those tiers sharing infrastructure.
The Fable lanes were smaller samples, two runs for the floor and cache tasks and one for the multi-step task, so treat them as directional confirmation rather than a second full study.
The floor (above) explains a session that starts lean and stays short.
Real sessions tend to be much longer and more meandering, so we tried to emulate that by measuring a longer session with stacked responses.
We dropped a real 72KB AGENTS.md from a production repository into the workspace and re-ran T1.
The effect is symmetrical and large. Both harnesses gained just over 20,000 tokens per request. OpenCode's metered total went from 13,152 to 33,336. Claude Code's went from 39,005 to 59,243.
The asymmetry is in the mechanics, and it bit us during the experiment. Claude Code 2.1.207 ignored AGENTS.md entirely and only ingested the file when renamed CLAUDE.md, injecting it into the first user message. OpenCode reads either filename and injects it into the system prompt.
Two practical consequences follow. Check which filename your harness actually honours, because an ignored instruction file is silent. And know that a heavy instruction file nearly quadruples a lean harness's baseline; it rides on every request of every session in that repository.
We attached public, credential-free MCP servers in one-server and five-server configurations.
The schemas are identical across harnesses, so the tax is nearly identical too; roughly 1,000 to 1,400 tokens per small server, per request. Five servers added 4,900 tokens to Claude Code by payload and 6,967 metered to OpenCode, growing the tool counts from 27 to 69 and from 10 to 52.
Small public servers are the gentle case. Production servers with rich APIs ship schemas several times larger, which is exactly what the everything measurement below shows.
One operational footnote. Claude Code silently ignored a project-scoped .mcp.json in print mode until passed an explicit --mcp-config flag. If you assume a server is attached, verify it at the boundary.
Story-driven workflow frameworks such as BMAD expand a slash command into a large prompt template of personas, protocols, and checklists.
We ran an 8,405-char representative template as the prompt for the same T3 story in both harnesses. The template itself is only about 2,100 tokens, but it enters the conversation history and is re-carried by every subsequent request in the session. A 9-request session re-sends it nine times.
Framework tax is template size times request count, and it stacks on top of everything above.
We asked each harness to fan the work out to two parallel subagents. This is where the totals climb fastest.
Claude Code completed the task with 9 model requests across three distinct request classes. There was the main session with its full ~33k baseline, and five subagent calls each carrying their own bootstrap of a 3,554-char agent system prompt plus 24 of the 27 tools.
Cumulative metered input reached 513,000 tokens, against 121,000 for the same work done directly. That is a 4.2x multiplier for one modest fan-out. The parent ingests only each subagent's returned result; the cost is that each subagent is a fresh agent re-reading its own bootstrap on every one of its own turns, so two subagents running several turns each add several more full-baseline requests to the session.
OpenCode's design here is notably leaner. Its subagent requests carry a reduced profile of a 1,379-char system prompt and 5 tools. Its subagent lane did not complete cleanly through our gateway, so we report the design difference from the captured payloads and leave its totals unquantified.
If your heavy sessions surprise you, this is the first place to look. Delegation is powerful and sometimes correct; it is also the single largest token multiplier we measured. We have since measured the fan-out mechanics in detail, across three model families, in The Subagent Tax.
Thinking output bills at output rates, five times the input rate, and reasoning blocks are carried forward inside the conversation.
We attempted to toggle extended thinking in both harnesses and are declining to publish numbers. Our gateway applies its own thinking policy, neither harness's toggle demonstrably survived the path, and anything we quoted would be noise.
The mechanism is not in doubt, though. On reasoning-heavy work it compounds with every multiplier above, because the thinking blocks join the history that gets re-sent.
Finally, the bridging measurement. We ran T1 again under a real working configuration.
For OpenCode that meant eleven MCP servers covering email and calendar, task management, reference management, product analytics, and others, plus the 72KB instruction file. The first request metered 90,817 tokens on a cold cache write, carrying 179 tools and 277KB of schemas, before the user had typed a word.
For Claude Code, four MCP servers plus installed plugins and the same instruction file produced a 311KB payload of roughly 75,000 tokens with 118 tools.
After subtracting the gateway envelope, that is roughly a 12x configuration multiplier against OpenCode's ~7,000-token floor. The harness sets the floor; your configuration sets the bill.
Prompt caching changes the units but not the conclusions.
Both harnesses set cache breakpoints correctly. The payload is written once, at a 1.25x premium for the 5-minute TTL, and re-read at a tenth of the price thereafter.
Three costs survive the discount.
First, the write itself, re-paid whenever a pause exceeds the TTL. A five-minute think, a meeting, a lunch; each re-primes the full stack at write rates.
Second, the read multiplied by request count, which subagent fan-outs and serial tool loops inflate quickly.
Third, context-window consumption, which is completely immune to caching. An 85k-token bootstrap occupies more than 40 per cent of a 200k window on every single request, shrinking the room for actual code before compaction kicks in and spends yet more tokens summarising.
Caching only pays if the prefix stays stable, so we hashed the tools array and system blocks of every request in the dataset.
OpenCode emitted byte-identical prefixes across every request and every run. Three separate T1 sessions produced the same tools bytes, the same system bytes, and the same message bytes; the repeat runs wrote zero cache tokens and read everything. Its nine-request T3 session held one stable prefix throughout.
Claude Code emitted three distinct request classes per session; a warmup probe, the main conversation, and subagent calls, each with its own prefix and therefore its own cache entry. Its system bytes also varied between sessions in the same workspace, and its first-message scaffolding varied between runs.
The consequence shows up in the cache-write column:
On the identical file-summarise task, Claude Code wrote 53,839 cache tokens across five requests, including one complete mid-task re-write of its full ~43k prefix. OpenCode wrote 1,003.
We re-ran the matched task to check whether that was a one-off (it was not).
The large mid-session re-write reproduced, 43,342 tokens in the first run and 36,899 in the second, while a third run against a freshly warmed cache wrote almost nothing. OpenCode showed zero mid-session re-writes in every Sonnet session we could cleanly meter.
We then repeated the matched task on Claude Fable 5:
The behaviour replicated almost exactly; another complete mid-session re-write, this time 50,053 tokens with zero cache read, and a cache-write gap of 52x against Sonnet's 54x. The multi-step task on Fable produced an even larger one, 85,686 tokens. Two model families, same pattern. OpenCode stayed byte-stable bar one write of roughly 6,000 tokens across all the Fable runs, against Claude Code's repeated re-writes of 37,000 to 86,000.
Depending on cache temperature, Claude Code's cache-write volume on the same task ranged from 5.9x to 54x OpenCode's, and cache writes bill at a premium, 1.25x base rate for the 5-minute tier and 2x for the 1-hour tier.
One attribution caveat is owed here. A single mid-task cache miss could in principle be our gateway evicting rather than the harness moving its cache breakpoints; reproduction across runs makes systematic harness behaviour the likelier explanation, and the prefix instability itself is harness-side, visible in the captured bytes before any gateway involvement.
If you have watched a usage meter climb dramatically under Claude Code but stay flat under OpenCode with the same model, this is the likeliest mechanism; bigger prefixes, more distinct prefixes per session, and more re-writes of them, multiplied by any subagent fan-out.
A fair objection to everything above is "a bill says nothing about the work", ie, paying more is rational if the output is better.
The tasks here were chosen so that quality could not be the explanation. Both harnesses completed every scored task correctly. The multi-step task was verified by an assertion script each harness had to write and then pass, and both exited clean. The file summaries were both accurate. On these tasks the token gap is the cost difference for an identical outcome, which is exactly what makes it measurable.
We then measured a first slice of it directly. A separate ten-lane benchmark gave each harness the same job, implementing two date utilities against a seeded ten-assert test suite it could not modify, in five fresh workspaces per harness; this time the suite was pre-written and hash-verified, so neither harness graded its own work. Both passed five out of five. Against that identical, independently verified outcome, the average metered cost per passing run was roughly 268,000 input tokens for Claude Code and 72,000 for OpenCode, about 3.7x, with both harnesses served the same model snapshot. OpenCode also finished each lane in a minute or two, against four to eight minutes for Claude Code.
Whether the premium buys quality on genuinely hard engineering work is a different question, and a two-function utility is a first slice of it, not an answer. Claude Code's background agents, skills, and orchestration surface may well earn their tokens on harder tasks; testing that claim needs harder tasks and more runs, and the rig here can drive both.
Two of the findings are independent of quality, though. Re-writing a byte-identical cache prefix mid-session buys no code quality at all; it is the same content, paid for again at premium rates. An instruction file the harness silently ignores buys nothing either. Whatever the capability argument for a larger platform, those two are waste on any definition.
The honest version of this experiment is "trust the captured payloads", so we treated the dataset the way we tell clients to treat production inference logs.
Every one of the 273 captured request/response records was written into a tamper-evident, SHA-256 hash-chained audit trail using our open-source library @systima/aiact-audit-log, and the chain verifies end to end.
Chain verified: 273 entries
No breaks detected
Hash chain integrity: VALID
This is the same mechanism the library provides for EU AI Act Article 12 logging; structured records, integrity you can hand to a third party, and reconstruction of exactly what was sent and returned.
The dogfooding also cut both ways. One rebuild reported more records ingested than the chain contained, a buffered-write fault we caught because the chain count refused to reconcile; we rebuilt from the raw captures and re-verified before quoting the number above.
A token benchmark is a low-stakes use of it. A credit-decisioning agent is not.
The measurement rig is roughly 200 lines of Node. It is an HTTP proxy that forwards to your model endpoint, writes each request body and response usage block to disk, and appends each pair to an audit chain.
The rig, the seeded quality benchmark, and the full aggregated results are open source at github.com/systima-ai/agentic-coding-tools-comparison.
The raw captures stay private, since they embed complete system prompts and configuration, but the rig regenerates equivalent captures for your own setup in minutes.
Point ANTHROPIC_BASE_URL at it. Give the harness a fresh config directory and an empty workspace for the floor. Then add your instruction file, your MCP servers, and your workflows one at a time, and watch the boundary.
If your traffic passes through a gateway, measure its envelope with a bare request first, and check which model actually answers.
Anthropic is fine, as long as someone else (a clueless employer drinking Dario Koolaid) is paying for it. But the moment you have to pay for it, people just bail and go for DeepSeek, Kimmi, OpenRouter, OpenCode Go and other alternatives that give more bang for the buck than Anthropic.
There is a world where, to hit the next quarters revenue projection, you add 2,000 tokens to the system prompt and "beat" expectations at the next earnings release.
All the while, it could have just done a two-line probe test and see what happens when it calls the API with "None" for that parameter. Or just assum it would act as expected and wire in debug logs in case it doesn't.
Although saying that out loud makes me question it - each per-user chat and growing cache would need eventually to own its own ~contiguous memory block.
The downside is the code isn’t as good but it is produced a lot faster and more cheaply and often it’s actually fine.
CoT has made LLMs better (say 50% improvement or something) but increases cost by an order of magnitude. That graph is going in the wrong direction and has been for a while now
Its rather frustrating, slower tokens and more tokens.
To learn yourself:
<$20 on a cloud AI api for a chunk of tokens and have the AI teach you. "help me write an AI Agent using (language) and walk me through the steps"
Realize that these agent are REPL/while loops that maintain a conversation state and then based upon the tagging syntax like <TOOL:bash:uptime>uptime for system run time</TOOL> and the agent extracts the tool and then does sub commands.
"Pi has *ALL* the tools, can you name one it does not".
https://gist.github.com/joshcartme/dd71df7b4c51c356760b28d7f...
Increase the price by 70% and then cut it by 50%, resulting in a 15% cut that sounds like a major deal.
I now have unlimited Anthropic and OpenAI plans at work because CEOs bought the hype.
But for personal projects $10/mo OpenCode Go serves me with DeepSeek V4 Flash, MiMo 2.5 and GLM 5.2.
Especially since compute is such a scarce resource.
Incidentally, I also have zero supply chain attack surface as I have zero dependencies in my agent, just go stdlib. Pi, again, has 130+ transitive dependencies asking me to trust the security of my system to 150+ additional people I've never met in exchange for a bunch of bloat I do not want.
Sure, but you have to add almost everything, no? It deliberately only comes with read, write, edit, and bash. My point wasn't that you can't add stuff, but that I'd just rather use an harness that's a bit more full featured from the start.
(Pi is a bit like old 3D printing where fettling the printer to work is a central part of the hobby. I'd rather just buy a Prusa.)
If going local, llama.cpp is going to be the more beginner friendly local inference engine that supports more processor types (AMD GPUs, Intel GPUs, CPUs, anything that supports Vulkan, not just Nvidia). LM Studio is a nice wrapper for this if you'd rather avoid cloning repo and compiling yourself, provided you don't mind closed source software; it's much less enshittified than Ollama.
If going local, you will also need model weights in the right format for your inference engine, and with a model that can fit on your hardware. This is going to be .GGUF files if you're using llama.cpp or a wrapper for it like LM Studio.
From there, pick a language, go look up the OpenAI /chat/completions API format (or Anthropic's "Responses" API format), create a DS or array or slice to store messages, and build a loop that accepts user input, formats it according to the API format, sends it to the inference server, retrieves and parses the response, adds the response to the DS/array/slice, and repeat.
There's a lot more beyond this - tool calling, other API formats (optionally), MCP servers, transport layers besides terminal stdin/stdout, permission models, starting with a system message, clearing your message stack correctly (hint: don't reset it mid tool-call), message compaction, web searching and page fetching, semantic search RAG over embeddings, memory layers - way too much to cover exhaustively in a single message.
Also I think it’s well known that OpenAI is the much less expensive option (in tokens and $$). For the same $20 you get a lot more mileage.
Curious if folks have strong opinions about the overall UX of OpenCode vs CC…
It’s like that saying “What Andy giveth, Bill taketh away”, but in this case it is one company.
There is definitely a conflict of interest.
And people paying $100 or $200 are much more likely to max it out for purely psychological reasons - it crosses that threshold where I want to see my money's worth in full. Whereas people on $20 subs are more likely to be there just to get access to better models and features, and are not necessarily even doing any substantial work.
I think that Anthropic will bill you in any case :D
But yes, anything you want to ensure really needs to be a hook.
edit: realizing with "precommit" you probably meant a git hook not one in their harness. I'd have written the same response more or less though. :)
I feel like most mainstream programming languages do this sort of work for their standard libraries and their official docs. Go and Python come to mind, but plenty others do this reasonably well to the point where one mostly doesn’t need to read the implementation code to effectively use the standard library itself.
I enable tools specific to each project only in that project, and have very very few in my global config. Like <5k tokens worth.
Depends what I want but I can give a completely new context for every generation.
I try to make everything as simple and human readable as possible because I want the audit to go fast.
I think for me I lean towards an audit optimized approach. Everything is still generated but revolves around the human-in-the-loop for review.
Give it only what it needs and do things usually 1 file at a time.
Feels like I'm a sort of manual tape editor, if the context was a tape fed into machine, I assemble that and then watch the machine output the results I need.
Current /context on a fresh session (compare to that above) is:
Opus 4.8
15.8k/1m tokens (2%)
System prompt: 4.5k tokens (0.4%)
System tools: 7.9k tokens (0.8%)
Memory files: 441 tokens (0.0%)
Skills: 3.1k tokens (0.3%)
Messages: 8 tokens (0.0%)
Free space: 984.2k (98.4%)I would also just vibe it if there is no responsibility, but if I do it that way I don't even care what happens with the project.
I get so detached from it that I stop caring and if it has huge critical bugs..I just don't care anymore because it's not my responsibility or my code at all at that point. I'm just there to nudge things along.
Just hook it up to Jira and let the managers add the features then pass it off to QA.
Real engineering is fully automated at that point.
The only issue is that Anthropic optimizes the entire experience for their bottom line. User experience and price only suffer becaue of that.
The nefarious part is because it's non optional. They could give you an option and compete by being better, instead you're given the finger as the option is taken from you. Competition is hard and banning people to create more FUD serves business need better.
You've obviously been gaslit so badly you're desperate to find a way to defend a shitty move and pretend it's the only way to increase usability. But you don't have to deny really! You're allowed to admit control is easier for a company than competition, and that they didn't have to, but did because it increases their control of the ecosystem.
If you want to defend someone, good? But at least save it for someone who actually deserves it. They don't; and you insult you and your readers intelligence by trying.
So what? When you care about optimising the entire experience, you offer sane defaults.
When you prevent people from changing the defaults, it's about control, not experience.
Its not 'nefarious' in that its in their best business interests.
But it'd be difficult to take anyone serious who thinks Anthropic's motivation was to improve the UX, and the other effect were by accident. At the time they specifically started blocking based on openclaw prompt text. Its a walled-garden tactic.
A walled garden is nefarious to people who do not want to be inside one.
Also i doubt there was jira ticket with “make llm more verbose”, rather ticket with “bug makes llms too verbose” gets prioritised taking revenue impact into account.
Your gym members who got a subscription aspirationally and don't show up are absolutely subsidizing the power lifter who is introducing wear on (tens of?) thousands of dollars of equipment three times a week, but if the regulars weren't there you wouldn't have sold those subscriptions at all. Without a poster child there's no poster.
But then you could just be storing up a lot of problems…
Yep, 100%.
Business has made it clear they don’t care, so there’s no point in burning one’s energy. Throw the whole thing on auto, check out, and go do something else during the day.
I say this as I don't actually know how Clade Code does this, since it's not open source, but I fail to see why two agents doing the same thing launched at different times would have different tools and system prompts.
I fully agree.
> It's the same conflict of interest quite literally any business has.
I know that you know what I meant ;) In the long term it is just as you say - overcharging (eventually corrected by competition forces), but in the short term it can be additional revenue, blamed on a bug, but making some manager look good.
For reference, pi-coding-agent, by itself (not including dependencies, tests, or pi-ai, pi-tui, pi-agent-core, etc), is ~41,653 SLOC taking up ~1658.9 KiB across 163 files.
My agent, excluding dependencies (all go stdlib) and tests, is 3 files, 946 SLOC, taking up 36.3 KiB, and includes a basic TUI and an XMPP transport channel (including TLS for XMPP), with dynamically configurable delivery to and receipt from either or both, including allowlists for XMPP message partners. It has tool calling, a permission model with whitelisting and interactive permission querying on a per-tool basis, full thinking support, including the ability to toggle hiding or showing it across either or both transports repeatedly throughout an individual session, the same tools as pi comes with out of the box, plus web search, and a tool to vet, build, and git commit golang projects all in one go, stopping if errors are observed. Configurable model and endpoint, too.
Incidentally, the open source xmpp server (prosody) and metasearch engine (SearXNG) are both self-hosted, too.
I've heard really good things but that being my first experience with pi didn't fill me with confidence about it's code quality either.
For now I stay with OpenCode I think - I was using zed editor and agent for the longest time anyway and think I will go back to that. CLI tools for me seem a bit too disconnected from the code.
It's still questionable but I don't think it's in the same ballpark as what you describe.
If you make a bunch of identical API calls quickly, before the initial request completes its cache write, you will have cache misses.
If you make a single API call to warm the cache, then make a bunch of subsequent identical requests, you will have cache hits.
The optimization for this sort of thing is to deduplicate in-flight requests, but i've seen no evidence that is being done; the better design pattern would be an api or tool call that explicitly launches multiple agents after a shared prompt processing stage
If that's what you're doing, you're fucked (in today's society, at least). What happens to your job when they figure out that's what you're doing?
Though, imo, the fact that pi maintains its "we only include the bare minimum!" statement is part of the draw for me. Especially considering that im in an enterprise env; being able to internally share custom implementations of out-of-the-box Codex/CC stuff is really nice.
I do wonder how they'd go about shipping a default web search tool. Big problem there is the lethal trifecta. Shipping something that arbitrarily allows untrusted content to be retrieved non-deterministically I'm sure is a long conversation on Pi's end. Pushing it off to the user to decide is easy.
I agree, that work in these places is likely short lived, if for no other reason than working in them is awful and demoralising. My point is, that these places exist, and have such a hard-on for “oh my god, AI!!!1!1!” that putting in extra effort there, is a waste of your own energy.
Edit: suppose that very well could have been tongue-in-cheek.
Side note: as someone who has been interested in programming for a while, but didn't end up in a software dev track in life, it's been pretty wild watching the ride you all have been going on lately. I used to be pretty bummed I didn't get to do that kind of work for a living, but lately I've been feeling more and more like I dodged a bullet.
Not that I don't have my own AI-related junk I have to deal with where I did end up, of course. I think most have.
You can just answer the same rote questions to different companies for max salary, then when the going gets tough you can essentially 'fire' the company and say they've moved past your core consulting paradigm. Maybe suggest a new consultant and move one. Rinse; repeat.