[BUG] Fixed per-session token overhead increased ~75% (30k→52k) mid-day on 2026-06-16, independent of context window usage or content

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?

Increased start up token cost for claude code with zero config changes between session confirms my noticing token burning at faster rates for the exact same work steps. THe change occurred when I started a new session immediately aft ending a prior session. The ctx session limit changed from 200k to 1Mk, and then the token consumption for the same work went up. This was confirmed by my startup token load changing from 29k to 50k at baseline.

What Should Happen?

Title: Fixed per-session token overhead increased ~75% (30k→52k)
mid-day on 2026-06-16, independent of context window usage or content

Environment:

• Claude Code 2.1.179
• Model: claude-sonnet-4-6
• ~/.claude.json shows sonnet1m45MigrationComplete: true — appears to

have flipped during this window

• Linux, project-scoped CLI sessions

Observed:
Pulled usage data directly from session JSONL transcripts
(~/.claude/projects/<project>/<session-id>.jsonl) for every session
started that day, looking at the first API call of each fresh session —
pure fixed overhead (system prompt + tools + skills + memory + cache),
before any conversation content accumulates.

┌─────────────────────┬───────────────────────────────────┐
│ Session start (UTC) │ Total input tokens, first message │
├─────────────────────┼───────────────────────────────────┤
│ 2026-06-16 20:55 │ 29,906 │
├─────────────────────┼───────────────────────────────────┤
│ 2026-06-16 23:45 │ 52,535 │
├─────────────────────┼───────────────────────────────────┤
│ 2026-06-17 01:48 │ 52,568 │
├─────────────────────┼───────────────────────────────────┤
│ 2026-06-17 03:00 │ 47,102 │
└─────────────────────┴───────────────────────────────────┘

Baseline jumped ~22k tokens (≈75%) in the 3-hour window between the
first two sessions, and stayed elevated since. No project config, MCP
servers, skills, or CLAUDE.md files were modified in that window. This
is not a content/compaction artifact — these are first-message totals
before any conversation history exists.

Suspected cause: Coincides with a mid-day account migration to the 1M
context window for Sonnet (sonnet1m45MigrationComplete flag). If the
new context-window tier ships with a larger default fixed payload, that
would explain a fixed-cost jump like this independent of context
window size or actual work performed.

Impact: On a Pro plan with rate limits tied to token consumption, a
fixed tax added to every message materially shrinks usable throughput
per 5-hour/weekly window, for identical work to what ran fine that
morning.

Ask: Confirm whether the 1M-context migration changed fixed per-message
overhead for Sonnet sessions, and whether Pro-tier usage limits were
adjusted to account for it.

Error Messages/Logs

┌─────────────────────┬───────────────────────────────────┐
  │ Session start (UTC) │ Total input tokens, first message │
  ├─────────────────────┼───────────────────────────────────┤
  │ 2026-06-16 20:55    │ 29,906                            │
  ├─────────────────────┼───────────────────────────────────┤
  │ 2026-06-16 23:45    │ 52,535                            │
  ├─────────────────────┼───────────────────────────────────┤
  │ 2026-06-17 01:48    │ 52,568                            │
  ├─────────────────────┼───────────────────────────────────┤
  │ 2026-06-17 03:00    │ 47,102                            │
  └─────────────────────┴───────────────────────────────────┘

Steps to Reproduce

Session start. No config changes, no messages, just pure start up.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.179

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Windows Terminal

Additional Information

Is this a system change in tokenizer? So an intentional known change in token consumption behavior or a bug??