[BUG] Claude Code usage meter drops ~10% from trivial session despite only ~15k visible context overhead

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Problem

In a fresh Claude Code session, /context shows roughly ~15k tokens of fixed
overhead. However, after only a trivial 3-message exchange, the 5-hour Pro
usage meter drops by about ~10%.

If the Pro 5-hour budget is roughly equivalent to ~4.4M tokens, then 1%
should represent about ~44k tokens. A 10% drop would imply roughly ~440k
tokens consumed.

That does not match the visible /context numbers. The session did not
contain anywhere near 440k input/output tokens.

So the issue is either:

1. The usage meter includes hidden overhead not shown in /context,
2. /context is under-reporting what is billed against the 5-hour budget,
3. The 5-hour usage meter is not token-linear,
4. Or there is a bug/regression in how Claude Code accounts for fresh-session

overhead.

What Should Happen?

Expected behavior

Claude Code should clarify how /context maps to the 5-hour Pro usage meter.
If the usage meter includes hidden tool/schema/system overhead, that should
be visible or documented. If the meter is not token-linear, the UI should not
imply that visible context size explains usage consumption.

Error Messages/Logs

Session                                                                 
 Total cost:            $1.38
 Total duration (API):  2m 29s
 Total duration (wall): 29m 17s
 Total code changes:    0 lines added, 0 lines removed
 Usage by model:
    claude-sonnet-4-6:  3.2k input, 5.0k output, 662.4k cache read, 183.6k cache write ($1.38)
     claude-haiku-4-5:  503 input, 16 output, 0 cache read, 0 cache write ($0.0006)

 Current session
 ██████                                             12% used
 Resets 2:20pm (Asia/Bangkok)
                                                                             Current week (all models)
 █████████████████████                              42% used
 Resets Jul 3, 6pm (Asia/Bangkok)


  ⎿  Context Usage
     ⛁ ⛁ ⛀ ⛀ ⛀   Sonnet 4.6
     ⛁ ⛁ ⛁ ⛀ ⛶   claude-sonnet-4-6
     ⛶ ⛶ ⛶ ⛶ ⛶   49.8k/200k tokens (25%)
     ⛶ ⛶ ⛶ ⛶ ⛶
     ⛶ ⛝ ⛝ ⛝ ⛝   Estimated usage by category
                 ⛁ System prompt: 7.8k tokens (3.9%)
                 ⛁ System tools: 12.6k tokens (6.3%)
                 ⛁ Custom agents: 152 tokens (0.1%)
                 ⛁ Memory files: 1.5k tokens (0.7%)
                 ⛁ Skills: 7.1k tokens (3.5%)
                 ⛁ Messages: 21.2k tokens (10.6%)
                 ⛶ Free space: 116.8k (58.4%)
                 ⛝ Autocompact buffer: 33k tokens (16.5%)

     Auto-compact window: 200k tokens

     MCP tools · /mcp (lo
     └ 51 tools · 0 tokens

     Custom agents · /age
     └ 3 agents · 152 tokens

     Memory files · /memo
     └ 3 files · 1.5k tokens

     Skills · /skills
     └ 127 skills · 7.1k tokens



Another session
  Before asking:
  Usage: 0 input, 0 output, 0 cache read, 0 cache write
  Session meter: 18%

  After one prompt "1+1":
  3 input, 5 output
  35.2k cache write
  Cost: $0.2123
  Session meter: 19%
  Context: 35.6k / 200k

  That means the first real prompt caused Claude Code to write almost the
  entire visible context into cache:

  35.6k visible context ≈ 35.2k cache write

  So yes, skills contribute:

  Skills: 7.1k / 35.6k = about 20% of cache write

  But cutting all skills would only reduce part of the problem. The actual
  issue is:

  Claude Code charges/writes the whole static session context to cache on the
  first prompt, even for a 3-token input and 5-token output.

  Your report should say:

  A trivial prompt "1+1" produced only 3 input tokens and 5 output tokens, but
  Claude Code wrote 35.2k cache tokens and charged $0.2123. `/context` showed
  35.6k visible context, so the cache write appears to include almost the
  entire static context: system prompt, tools, memory, skills, and messages.

  Claude suggested trimming skills, but skills are only 7.1k of the 35.6k
  context. The larger concern is that all static context is cache-written on
  the first prompt, making even trivial fresh sessions expensive.
The breakdown:

- System tools: 12.6k — user has zero control
- System prompt: 7.8k — user has zero control
- Skills: 7.1k — partial control
- Memory + messages: ~8k — minimal

~21k of the 35.6k is entirely outside user control. Cache-writing it on session open is a Claude Code architectural decision, not a user configuration problem. The $0.21 would cost ~$0.18 even if you deleted every skill.

The accurate bug framing: Claude Code unconditionally cache-writes the full static context on first prompt, with no deferred/lazy loading for MCP tools or skills, making session startup cost O(total_config) regardless of prompt complexity. Users can't opt out or defer it.

Skills trimming is a valid secondary optimization (~$0.04 savings at most), but it doesn't address the root: the minimum session cost on a zero-work prompt is ~$0.18 and rising with each tool/MCP server added.

Steps to Reproduce

-

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.195 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_