Repository navigation
[BUG] Excessive token usage (~20k–30k tokens) for trivial prompts in Claude Code CLI #52979
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report (please file separate reports for different bugs)
- I am using the latest version of Claude Code
What's Wrong?
Excessive token usage for trivial prompts in Claude Code CLI.
In a completely clean environment (empty folder, no repository, no CLAUDE.md), very simple prompts are consuming tens of thousands of tokens.
Examples:
- Prompt: "hi" → ~31,000 tokens
- Prompt: "what colour is the sky?" → ~19,000 tokens
This occurs consistently even in a fresh session using:
- claude --verbose
- different models (sonnet-4.6, haiku-4.5)
- different effort levels (low/medium)
Expected behavior:
Simple prompts should use ~50–200 tokens.
Actual behavior:
There appears to be a large fixed token overhead (~20k–30k tokens) per request, even with no files or tools involved.
Impact:
This significantly increases cost and makes the CLI impractical for lightweight usage.
Additional notes:
- Issue reproducible in empty directory (C:\claude-clean)
- No repo, no agents, no commands executed
- ccusage shows very high cache read tokens for these simple prompts
This suggests excessive system prompt/context injection or a context/caching issue where tokens are not being trimmed properly.
What Should Happen?
For trivial prompts (e.g. "hi" or "what colour is the sky?"), Claude Code should use a minimal number of tokens (~50–200).
There should not be a large fixed baseline token overhead per request in a clean environment with no files, tools, or context.
Token usage should scale with the size and complexity of the prompt.
Error Messages/Logs
No explicit error messages.
Observed via:
- Claude Code verbose mode token display (~19k–31k tokens per trivial prompt)
- ccusage showing very high cache read tokens
Example:
Prompt: "hi"
Observed tokens: ~31,000Steps to Reproduce
- Create an empty folder (e.g. C:\claude-clean)
- Open terminal and navigate to the folder
- Run: claude --verbose
- Enter: "hi"
- Observe token usage in the top-right (~30k tokens)
Repeat with:
- "what colour is the sky?"
- different models (haiku, sonnet)
- different effort levels
Result is consistent across all tests.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Earlier versions (and API/chat usage) showed ~50–200 tokens for trivial prompts. Exact CLI version unknown.
Claude Code Version
2.1.119 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
- Issue occurs in completely empty directory with no repository or CLAUDE.md
- No tools or commands are executed during tests
- Token usage is consistently high (~20k–30k) regardless of prompt size
- ccusage shows extremely high cache read tokens for simple prompts
- Suggests large fixed system prompt or context not being trimmed properly
This makes Claude Code significantly more expensive for simple interactions compared to expected usage.
Activity
github-actions commentedon Apr 24, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
dripcreate commentedon Apr 24, 2026
👎 This appears related but not an exact duplicate.
My reproduction shows significantly higher baseline token usage:
This suggests a larger fixed overhead than #51809 (~6–8k tokens).
#52413 seems closest, but this issue highlights the baseline cost in a completely clean environment.
junaidtitan commentedon Apr 24, 2026
20-30K for "hi" is painful. Most of that bloat accumulates from stale tool results, metadata, and old attachments that get re-sent every turn. Cozempic's strategies (stale-reads, tool-result-age, metadata-strip) strip that accumulated bloat so each API call sends only what matters.
pipx install cozempic && cozempic treat— https://github.com/Ruya-AI/cozempicdripcreate commentedon Apr 29, 2026
Still reproducible on Claude Code 2.1.123, Windows 11.
Confirmed clean environment: no MCP servers, no user skills, ~16 KB auto-memory.
Symptom unchanged after initial report. Likely related to #54410 (medium-effort regression) and #53925.
dripcreate commentedon Apr 29, 2026
Update — still reproducing on Claude Code 2.1.123, Windows 11 (8 days after original report)
Re-ran the original test in a fresh empty directory. No MCP servers, no user skills, no project context, no
Model + effort | Original (v2.1.119) | Today (v2.1.123) -- | -- | -- Haiku 4.5, low effort | 31,642 tokens | 31,877 tokens Sonnet 4.6, medium effort | 19,122 tokens | — Opus 4.7, medium effort | — | 26,575 tokens (new datapoint)CLAUDE.md, ~16 KB of auto-memory total. Pristine baseline, same as the original report.Prompt in every case: "what colour is the sky?"
Two observations:
Effective impact: a 5-hour Claude Max session is delivering noticeably less work than 7 days ago. The same routine tasks now consume materially more of the session quota.
Likely related (please link/cluster as appropriate):
mediumeffort after recent update #54410 — Unexpected token consumption increase withmediumeffort after recent updateThis setup has no MCP and no skills, so the issue is reproducible without either of those subsystems being involved.
Happy to provide further reproductions, version-by-version comparisons, or a diagnostic dump if useful. Screenshots from both today's runs are attached.
dripcreate commentedon Apr 29, 2026
Update — referencing your 2026-04-23 post-mortem
I've read the post-mortem covering the thinking-block clearing bug fixed on 2026-04-10. Appreciated the transparency and the quota reset.
I'm still seeing high baseline tokens on Claude Code 2.1.123 / Windows 11, post-fix:
Test (clean empty dir, no MCP, no skills, no project) | Tokens -- | -- Haiku 4.5, low effort, "what colour is the sky?" | 31,877 Opus 4.7, medium effort, same prompt | 26,575Two questions to clarify:
If useful, I can provide a
mitmproxycapture of the actual POST + responseusageJSON breaking down what'scache_creation_input_tokensvscache_read_input_tokensvs plaininput_tokenson a clean first turn.Cross-references: #41930 (parent), #38335, #53925, #54410, #54596.
Update — referencing your 2026-04-23 post-mortemI've read the post-mortem covering the thinking-block clearing bug fixed on 2026-04-10. Appreciated the transparency and the quota reset.
I'm still seeing high baseline tokens on Claude Code 2.1.123 / Windows 11, post-fix:
Test (clean empty dir, no MCP, no skills, no project) Tokens
Haiku 4.5, low effort, "what colour is the sky?" 31,877
Opus 4.7, medium effort, same prompt 26,575
Two questions to clarify:
The post-mortem mentions Sonnet 4.6 and Opus 4.6 were affected. Were Haiku 4.5 and Opus 4.7 also touched, or are these models supposed to be unaffected?
The thinking-block bug specifically caused cache misses on subsequent turns. My reproduction is on the first turn of a fresh session — would that even be affected by the cached-thinking-block code path? If not, my symptom is something separate.
If useful, I can provide a mitmproxy capture of the actual POST + response usage JSON breaking down what's cache_creation_input_tokens vs cache_read_input_tokens vs plain input_tokens on a clean first turn.
Cross-references: #41930 (parent), #38335, #53925, #54410, #54596.
daliovic commentedon May 3, 2026
I am also so confused about this. It's been a while and I never took the time to investigate what on earth is going on. But this basically the exact same what I've been experiencing. I tried different models and different versions
(going back to v 2.0.64)with no luck.Edit: actually it seems to be reproduceable after v 2.1.100.
dripcreate commentedon May 4, 2026
Update — debug log reveals the per-prompt cost is actually multiple separate API calls
Ran with
ANTHROPIC_LOG=debug claude --debug --verboseon 2.1.123 (Windows 11), clean empty directory, single prompt "what colour is the sky?". Debug log shows the CLI fires three separate API calls per user-visible exchange:quota_checkgenerate_session_titlerepl_main_threadThe CLI displays 26,556 tokens for this single user-visible exchange, but that figure is the sum across all three calls, not one request's overhead. The session-title generator alone uses
max_tokens: 32000for a title that's typically a few words — appears to be a budget mismatch.Also visible in the response headers:
anthropic-ratelimit-unified-5h-utilization: 0.31was already at 31% on a fresh session — i.e. the boot itself contributed measurably to the 5-hour window before any user prompt was processed.Two clarifying questions:
max_tokens: 32000forgenerate_session_titleintentional? The title visibly returned is a single short sentence; that suggestsmax_tokenscould be ~50–200 instead.--verbosesupposed to be the per-prompt cost or the cumulative session cost? If the latter, the displayed number is essentially correct but misleading; if the former, the aggregation across the three calls is a UI bug.Also confirming this is now reproduced by @daliovic across multiple versions back to 2.0.64, which suggests the inflated baseline isn't tied to the specific 2.1.110–2.1.117 caching regression covered by the April 23 post-mortem — both of us are seeing this on first turn of a fresh session, which the post-mortem's "thinking blocks dropped on follow-up turns" mechanism wouldn't cause.
Cross-references: #41930 (parent), #38335, #53925, #54410, #54596.
dripcreate commentedon May 4, 2026
Update — 2.1.126 doesn't change the cold-cache reading on Windows
Tested same trivial prompt across machines today, all on Max OAuth, Opus 4.7, medium effort, fresh empty directory each time, prompt: "what colour is the sky?".
The version bump 2.1.123 → 2.1.126 produced no measurable change on the same Windows laptop. The lower VPS reading appears to be cache-state difference (recent activity = warmer cache), not a CLI fix — the prompt cache is device-specific even on the same Max OAuth identity.
Two related observations from
/usageand/stats:The
/usageper-model breakdown reveals the displayed token count conflates four classes: input, output,cache_read, andcache_write. For the same trivial prompt the underlying breakdown is roughly6 input + ~40 output + ~0–19k cache_read + ~7–26k cache_writedepending on cache state. Cache reads cost 0.10× input rate; cache writes cost 1.25×. So the displayed26,821 tokensactually represents only ~$0.06–0.17 in real billed cost depending on cache hit rate, not ~26k tokens of full-rate input.The
/statsview appears to exclude cache tokens entirely from the headline figure. My account showsOpus 4.7: In: 24 · Out: 432over the last 7 days despite sending multiple 26k-displayed prompts. Implies Stats is reporting only plain input + output, treating cache reads/writes as separately accounted (consistent with how the pricing actually works).The mismatch between
--verbose(shows everything summed together, alarming 26k+) and/stats(shows just billed input/output, modest) is what drives the felt-cost perception in this issue cluster. A UX fix on either end — either/statsshowing cache transparency too, or--verboseexcluding cache tokens to match/stats— would largely resolve the reporting around this specific bug surface.The underlying cold-cache fresh-session cost itself appears stable across 2.1.119 → 2.1.126 (~26k tokens displayed regardless of version). So it's not a regression-still-present so much as a UX-reporting-issue that has been making a stable-but-large baseline feel worse than it is.
Cross-references: #41930, #38335, #53925, #54410, #54596.
dripcreate commentedon May 5, 2026
Update — version-by-version comparison reveals residual issue post April 10 fix
Tested the same trivial prompt across multiple Claude Code versions on the same Max OAuth account, with
/clearbetween each test to ensure fresh state. Same Windows machine, same auth, same network conditions.Two genuinely interesting findings
1. There's a clear inflection point between 2.1.101 → 2.1.116 — token count jumped from ~17k to ~27k for the same trivial prompt. That's roughly a 60% increase across that version range, which corresponds to the cache regression period (Mar 26 → Apr 10).
2. The April 10 fix appears to have stabilised the regression but NOT restored the pre-March 26 baseline. Post-fix versions (2.1.123, 2.1.126, 2.1.128) still show ~26k tokens for trivial prompts — the same as 2.1.116 (during the bug period). Pre-bug versions (2.1.90, 2.1.101) showed ~16k.
This leaves approximately 10,000 tokens of residual overhead per fresh-session call that wasn't restored by the April 10 fix.
Connection to community-documented residual bugs
The community analysis at Claude diagnosed its own cache bug: a six-month timeline describes residual cache-invalidation mechanisms that persist post-fix:
--resume/--continueinvalidates cached prefix on first turnI have telemetry enabled and don't use
--resumefor the test runs above, so those traps don't account for my readings. The residual ~10k overhead appears to be present on the simplest possible code path.Discussion: Hacker News thread.
Two clarifying questions
Was the April 10 fix scope-limited? Specifically, did it address the "thinking blocks dropped on follow-up turns" mechanism described in the post-mortem but leave other cache-invalidation mechanisms in place?
Is the increase from 2.1.101's ~17k to 2.1.116's ~27k baseline considered a regression worth restoring, or is the post-March 26 ~26k count now treated as expected baseline behaviour for Claude Code 2.1.x?
Cross-references: #41930 (parent), #38335, #53925, #54410, #54596.
eunseokOh commentedon May 11, 2026
Adding a data point: this manifests on Python
claude-agent-sdk0.1.80 + bundled CLI 2.1.138 with multi-turn chat usingresume=<sdkSessionId>. Trivial prompts show consistent ~30Kcache_writeper turn, ~$0.13 floor cost.Root cause confirmed via proxy capture (see my comment on #43657):
toolsandsystemprefixes are byte-identical across turns, but the messages-array normalization pipeline still produces freshcache_creationeach turn. This is the same family as #43657 / #44045 / #49585.github-actions commentedon Jun 10, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Aug 12, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.