Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k (systima.ai)

OpenAI, to their credit, seems to be focusing pretty heavily on token efficiency in GPT 5.5 and beyond.

> prompts such as “Hey” or “commit” sometimes triggered 30+ tool calls

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.

Why are you asking the LLM to commit? Can’t you do that yourself?

Read through it an I'm curious whether setting the date and cmd on every system prompt call will cause the cache to invalidate.

I was here looking for this comment = )

This is interesting, because if I start a fresh session of Claude Code right now and run /context, I see the following:

   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.

  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%)

Why turn thinking off? I mean, yes, it uses less tokens, but you're using the best model OpenAI offers, but then making it as dumb as cheaper models.

> --system-prompt ""

Doesn't it need at least a basic system prompt to understand how to call tools?

Yep, have been using this for a long time now. No idea why everyone doesn’t.

Do you start Claude with this option? Or do you send this with every prompt?

You can't afford the best model. What are your specs and what models + quants have you tried?

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

> and on-device model combination right now

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.

Pi.dev requires some plugins to work well. Using Qwen3.6-27B/35B locally at Q8, I was quite frustrated with failed tool calls and tried many things.

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.

I have just re-analysed most common failed tool-calls and adjusted the tool so that it works. I have a manual repair step on failure that programmatically attempts to fix some things. On failure, the harness reports the error, the repaired function, and the result. Overall, seems to work fine. But it's very model-specific. Most commonly the model fails on shell commands where it hallucinates some programs. If it does it often enough, I just promote those to commands in the PATH. Over time, it has happened less.

Intellectual property is a dead concept.

You're making the opposite argument. Anthropic is incentivized to use less tokens in Claude Code because people are paying a fixed monthly fee for subscriptions.

the amount of system prompt wastage going on in orgs is insane. we identified 400k in annual burn for zero value in just one section of our large company.

and the interesting thing about system prompt wastage is its a cost that scales non linearly with subagent use.

> I use pi btw

Not sure if intentionally meant as a reference, but it gives "I use Arch btw" vibes.

Once I realized that Anthropic is a token merchant, I start to understand Anthropic’s decision more. They are always finding reasons for you to use more tokens through them unless the users revolt or demand some guardrails.

> My opinion is that claude code uses more tokens simply because Anthropic makes more money that way and forces people into their subscriptions.

OTOH, this makes typical subscriptions usages consume more tokens, which are included in their flat fee.

This sounds more like incompetence than malice.

> I use pi btw.

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.

Anecdotally at least Claude code uses less api money for me than other harnesses. I think people might be missing some caching discount?

Nice!

> 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?

What settings have you tried since it "became more opaque"? They've got a lot more settings now.

I use both now and agree they're basically interchangeable.

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.

6 minutes, 6 months, $6 million, 6 million tokens?

As a counterpoint: in a complex project, Fable's "curiosity" may be exactly what you want for an exploration and planning stage - not just for the orchestrator that turns your prompt into different angles with which to explore, but for each subagent whose task is to search the codebase for one of those "angles." If you truly want no stone unturned, letting those subagents spawn their own discoveries, and recursively grow the surface area of the inquiry, then it's quite reasonable to want Fable throughout.

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!

Sub agents each have to read part of your code base again to get enough context for the task. And if they take too long, your orchestrator's context is no longer in cache so you pay full price for that again once the subagents finish

If you do it sequentially you only read those files approximately once, and everything hits the same prefix cache

> What really burns tokens is sub agents. I once gave Claude Code a pretty big task, and it immediately launched 7 sub agents which burned through my budget before even one of them was finished. Tried again 5 hours later: same result.

Probably because the general purpose subagents inherit the parent model.

I tell Claude explicitly to use Explore subagents, which use Haiku only, now.

This is why I happily use Codex.

I run it basically 24/7 on a ~500k line repo, and only rarely run out of quota before the end of the week.

My experience with Claude Code was very good until about 2.5 months ago, and then it suddenly turned unbelievably terrible for me.

I have not and will hopefully never look back.

I still have PTSD from how ungodly terrible it was that last week of using it.

--disallowedTools Task

Spawning a bunch of agents seems to happen randomly. I almost never want this.

Subagents with a fat tailed latency distribution completely masks the trough filling that puts the most downwards pressure on per-token COGS.

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...

It's in the best interest for AI companies to gobble up tokens. I feel like every new release - Fable, etc - is just a way to extract more tokens/money.

For a while everyone was saying sub agents is how you save tokens, use lower quality models with limited context to do simple parts of the job after a smart planning agent has put it all in place. Is that no longer true or is this just the result of sub agent being used at the wrong time?

It’s funny too because I’ll ask fairly simple things and it’s fine, similarly simple question might spin up a bunch of sub agents and I don’t know why….

I feel like maybe it could have asked for clarification or something rather than go and try to calculate all the digits of pi all of a sudden.

They did recently change it so the default explorer agent inherits the session agent (capped at Opus). Before Explore was always haiku. I had Claude write a skill that extracts the built in Explorer agent skill, and then writes an identical Explore agent that uses Haiku

Same for me. I never use them. I use Fable on highest effort to plan things and then record the plan in tickets. I use Kata, which is CLI and agent oriented, but I suppose Jira or other systems would work too. I tell it to put enough context in each ticket to on-board a fresh coding agent to implement it. Then I just do /goal, telling to to run `kata ready` to get new tickets to work and continue until they're all closed according to acceptance criteria or until they're blocked on actions from me. I need to play around with getting it to switch to smaller models (or spawning 1 subagent) to do ticket implementation and then auto compact after each. Either way, it results in really easy workflows and uses very few tokens compared to the built in subagent flows that doing this completely avoids.

I had learnt that trick, so now I explicitly disallow Fable subagents.

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.

Probably both. The default subagent orchestration is designed for infinite pockets.

Maybe when they realize there is need to change this they come up with a more configurable interface for us mere mortals who can't afford to gamble their house on a pay as you go subscription.

lol I asked fable to help me estimate my TAM and it launched 102 agents and blew my $120 quota in 6 minutes. I do realize I can limit the agent count , hah

There is a negative incentive to fix problems that result in customers picking a more expensive plan to work around it. There are probably several engineers who have ideas about fixing this and they get apathy from many people and obstruction from a few, and sometimes active hostility by a manager somewhere in the chain.

The best you can do in such an environment is seek to introduce new features at the top tier, and then pull old features down the stack as the cost of those features has been amortized out, or to hurt your competitors by raising the ladder.

I’ve had similar experiences. I now have an explicit line in AGENTS.md to not use subagents unless explicitly requested. It also helps that for the tasks that are big enough to benefit from subagents are also the ones with high chances of going off-rails and/or a poor review phase. I’d rather do the orchestrator role and that way I can split up the review phase in a much more manageable chunk.

Yesterday I gave Claude Fable a difficult task. It then proceeded to spawn 415 agents. It got it done, but damn was it expensive.

They optimized it to burn more token in the recent months I feel. I made a small ~100 line change to a codebase by hand and threw claude at it to review. It spawned several sub-agents and burnt a ton of tokens. I guess the word 'review' now triggers some sort of in-built skill or something. It's absurd how rapid enshittification is taking over.

True. For Claude Code, I disabled explore subagents globally by adding this to ~/.claude/settings.json:

  "permissions": {
    "deny": [
      "Task(Explore)"
    ]
  }

Subagents are quite inefficient and the lossy context transfer between them does lead to more cost and more waiting. However I have found it to produce more reliable output, whether that is worth it for a given task has been a consideration.

I like to use subagents a lot, but I find them to be most useful when explicitly specified. E.g. "assign these tasks to 2 Sonnet, 2 Opus and 1 Fable subagent". Helps keep allocation consumption under control.

Not only a Claude Code issue. Started using OMP with GPT 5.6, and gave up, but it loves to use subagents, and it's basically unusable subagents with GPT 5.6 Sol there with Plus limits.

i have globally disabled subagents for claude. otherwise one prompt ended my Pro account

GLM isn't good enough yet.

It pays to be marginally ahead of people stuck on open models.

Thanks, I'm looking forward to this!

I wonder if a lot of the 33k is context, like from recent conversations.

If cost were the only factor of course you'd use B, but presumably you also care about quality quite a bit.

This isn't accurate since the main reason I'm using Claude Code instead of these other interesting sounding harnesses is the subscription service with highly discounted token usage. With OpenCode, you're paying the full price.

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?

They sort of are, in that they want subscription users to have clients that behave well with the KV cache etc.

If you don't use a subscription, and pay per token instead, you can easily move to another harness.