Earlier quoted context omitted.
I've done a couple side by sides on web chat with the same prompt on Opus 4.6, 4.7, and 4.8 and the output gets longer/more verbose on version increment. The enerr variants are definitely much wordier. 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"
I think both things can be true: new models benchmark higher and eat more tokens.
Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
171–180 of 433 posts
Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
#172Earlier quoted context omitted.
> [..] my rules do say: verify all changes with tests 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?
Rather than bake that into the prompt - wouldn’t it be better to just set up a pre commit hook that runs tests and linting?
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. :)
Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
#173I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, regardless of the model. What is the best harness and on-device model combination right now?
Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
#174Earlier quoted context omitted.
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…
Apologies, you're right - I used imprecise terminology. The entire initial JSON structure that was sent from Claude Claude to the LLM at the start of a session was 162k. This included the system prompt together with a list of tools (some with very extensive explanations), MCP server details, etc. I was simply supporting the article's data - their reported 33k tokens is probably roughly 150-165k.
Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
#175Earlier quoted context omitted.
Apologies, you're right - I used imprecise terminology. The entire initial JSON structure that was sent from Claude Claude to the LLM at the start of a session was 162k. This included the system prompt together with a list of tools (some with very extensive explanations), MCP server details, etc. I was simply supporting the article's data - their reported 33k tokens is probably roughly 150-165k.
A lot of people will just add as many tools as they can think of. I don’t think it’s obvious that this costs money.
I enable tools specific to each project only in that project, and have very very few in my global config. Like <5k tokens worth.
Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
#176What 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. 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…
Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
#177I am forced to use cloude code at work but a good solution is to just use --system-prompt "" and be done with it. I wish they allowed for other harnesses.
> --system-prompt "" Doesn't the model need at least a basic system prompt to understand what tools are available?
Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
#178What 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. 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…
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…
Unless they are orthogonal they most likely require similar context anyway so multiple sub agent is just wasteful.
Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
#179Earlier quoted context omitted.
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…
Apologies, you're right - I used imprecise terminology. The entire initial JSON structure that was sent from Claude Claude to the LLM at the start of a session was 162k. This included the system prompt together with a list of tools (some with very extensive explanations), MCP server details, etc. I was simply supporting the article's data - their reported 33k tokens is probably roughly 150-165k.