[BUG] Excessive token usage (~20k–30k tokens) for trivial prompts in Claude Code CLI

[dripcreate]

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,000

Steps to Reproduce

1. Create an empty folder (e.g. C:\claude-clean)
2. Open terminal and navigate to the folder
3. Run: claude --verbose
4. Enter: "hi"
5. 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.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Per-turn overhead ~6-8k tokens on Sonnet 4.6 — content complexity irrelevant #51809
2. [Bug] Excessive token consumption from system prompt and slow response times in Claude Code #51747
3. [BUG] Using tens of thousands of tokens for trivial work #52413

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[dripcreate]

👎 This appears related but not an exact duplicate.

My reproduction shows significantly higher baseline token usage:

• Clean empty folder (no repo, no CLAUDE.md)
• Prompt "hi" → ~31k tokens
• Prompt "what colour is the sky?" → ~19k tokens
• Reproduced consistently on Claude Code 2.1.119
• Occurs across models (haiku, sonnet) and effort levels

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]

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/cozempic

[dripcreate]

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]

---

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 CLAUDE.md, ~16 KB of auto-memory total. Pristine baseline, same as the original report.

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)

Prompt in every case: "what colour is the sky?"

Two observations:

1. Haiku-low is essentially unchanged across 8 days and 4 patch versions (~31k tokens for a one-line prompt in an empty directory).
2. Opus 4.7 medium effort uses fewer baseline tokens (26,575) than Haiku 4.5 low effort (31,877) for an identical prompt. Since the user-content is identical, this strongly suggests the inflated baseline is in CLI-side system prompt / context construction, not in model behaviour.

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

• [BUG] 🚨 Excessive Token Usage in Claude, Small Prompts Consuming more than 80% Quota, Think before claude subscription #53925 — Excessive token usage on small prompts (macOS)
• [Sonnet 4.6 / Opus 4.7] Unexpected token consumption increase with medium effort after recent update #54410 — Unexpected token consumption increase with medium effort after recent update
• [BUG] Routines struggle with MCP tools: excessive API calls, token waste, and stream timeout errors #54596 — Token waste in routines/MCP (different surface, but plausibly same root)

This 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]

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,575

Two questions to clarify:

1. 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?
2. 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.

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,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]

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]

Update — debug log reveals the per-prompt cost is actually multiple separate API calls

Ran with ANTHROPIC_LOG=debug claude --debug --verbose on 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:

Source	Model	max_tokens	When
quota_check	Haiku 4.5	1	Boot
generate_session_title	Haiku 4.5	32000	First prompt
repl_main_thread	Opus 4.7 (default)	64000	First prompt

The 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: 32000 for 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.31 was 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:

1. Is max_tokens: 32000 for generate_session_title intentional? The title visibly returned is a single short sentence; that suggests max_tokens could be ~50–200 instead.
2. Is the displayed token count in --verbose supposed 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]

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

Setup	Tokens displayed
Laptop, Windows, 2.1.123	26,793
Laptop, Windows, 2.1.126 (post-update)	26,821
VPS, Linux, 2.1.126 (recent activity)	22,147

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 /usage and /stats:

1. The /usage per-model breakdown reveals the displayed token count conflates four classes: input, output, cache_read, and cache_write. For the same trivial prompt the underlying breakdown is roughly 6 input + ~40 output + ~0–19k cache_read + ~7–26k cache_write depending on cache state. Cache reads cost 0.10× input rate; cache writes cost 1.25×. So the displayed 26,821 tokens actually represents only ~$0.06–0.17 in real billed cost depending on cache hit rate, not ~26k tokens of full-rate input.

2. The /stats view appears to exclude cache tokens entirely from the headline figure. My account shows Opus 4.7: In: 24 · Out: 432 over 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 /stats showing cache transparency too, or --verbose excluding 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]

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 /clear between each test to ensure fresh state. Same Windows machine, same auth, same network conditions.

Claude Code version	Model	Token count
2.1.90	Opus 4.6 (1M context)	15,982
2.1.101	Opus 4.6 (1M context)	16,887
2.1.116	Opus 4.7 (1M context)	26,576
2.1.123	Opus 4.7 medium	26,793
2.1.126	Opus 4.7 medium	26,821
2.1.128	Opus 4.7 medium	~26,800

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 Trap — --resume / --continue invalidates cached prefix on first turn
• Telemetry-disabled trap — silently halves cache lifetime
• Billing-word trap — certain conversation content triggers cache invalidation

I have telemetry enabled and don't use --resume for 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

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

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