Live data from Hacker News

Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k

systima.ai

171–180 of 433 posts

Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k

#171
post #149

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.

From my experience new models are slower and use more tokens even on questions which gpt 4 answered correctly. It is mostly because newer models tend to be more verbose (even with prompt requesting short answers).

Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k

#172
post #35

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

Maybe, depends on their workflow. In my human workflow, I tend to use commits as checkpoints and then squash before pushing. I'd usually only run time-consuming tests before squash+push.

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

#173

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

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.

Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k

#174
post #96
post #50

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

That’s entirely dependent on how many plugins, MCP tools, agents you have, and if you have pre-filling of all available tools enabled. Best way to avoid unnecessary expense is to avoid it all and use CLI tools instead.

Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k

#175
post #96

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

A smarter approach (progressive disclosure) for tools has been implemented by (I presume all) the harnesses over recent months, but you're 100% right in any case.

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

#176
post #53

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

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

Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k

#177
post #52
post #13

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

No, tool definitions are provided via some other mechanism.

Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k

#178
post #76
post #53

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

But how is that better than a single agent searching those "angles" sequentially?

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

#179
post #96
post #50

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

Ah that makes sense, wasn't trying to be pedantic. Thanks for clarifying.

Re: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k

#180
We should discuss cache performance if we haven't already. That 33k tokens may be a cache hit (I am not certain it's automatically a cache hit) but after the first call, it should certainly be a cache hit. Cache hit tokens are billed at 1/10th the price of cache misses. This is quite opaque, but it's necessary when you're asking "is the system prompt worth its stay" if you can save 33k tokens worth of dynamic discovery across the next few turns, the break-even point is quick and if the system prompt makes task performance increase and/or makes the system more autonomous so that it can string together more cache hits in a row, it becomes way way better. On a personal note, I think of things as aa function of 'supervised time to desired result' and 'cost'. because I find it harder to reason about tokens. I do think they could introduce a "minimal" mode (something like this is probably doable with the Claude agent SDK today)
Post reply on HN