[BUG] Silent billing change in v2.1.51: 1M context moved to extra-usage-only without notice — JSONL data proves identical workload billed differently

Open 💬 16 comments Opened Feb 26, 2026 by paulseongminpark

Summary

After updating Claude Code from v2.1.50 to v2.1.51, all 1M context model usage began consuming Extra Usage instead of the Max plan subscription allocation. This change was not documented in the changelog, no in-app notification was provided, and the Extra Usage charges were not reflected in real-time — only appearing a day later.

Environment

  • Plan: Max ($100/month)
  • Platform: Windows (MSYS2/bash)
  • Versions affected: v2.1.51, v2.1.52, v2.1.53
  • Version before (working): v2.1.50

Evidence: Same workload, different billing

I extracted token-level usage from my JSONL session transcripts:

| Date | CC Version | Opus 1M API Calls | Cache Read Tokens | Extra Usage Impact |
|------|-----------|-------------------|-------------------|-------------------|
| Feb 23 | v2.1.50 | 644 | 85,100,082 | None |
| Feb 25 | v2.1.51+ | 392 | 80,173,520 | +17% ($48.79 total) |

Feb 23 had MORE usage than Feb 25, yet Extra Usage was unaffected. The only variable that changed was the Claude Code version.

Timeline

  1. Feb 23 (v2.1.50): Used Opus 1M heavily (644 API calls, 85M cache_read tokens). Current Session usage increased normally. Extra Usage: unchanged.
  2. Feb 25 ~05:00 KST: Auto-updated to v2.1.51/52/53.
  3. Feb 25 all day: Used Opus 1M normally. Unknown to me, ALL sessions were now consuming Extra Usage.
  4. Feb 25 evening: Checked Extra Usage — it had NOT increased yet (delayed billing).
  5. Feb 26: Extra Usage jumped from ~80% to 97%. $48.79 charged.

Three distinct problems

1. Silent billing change (no notification)

The v2.1.51 changelog says:

"Model picker improvements: now shows human-readable labels with upgrade hints"

What it actually did: Added "Billed as extra usage" labels to 1M models AND changed the billing behavior. The changelog does not mention any billing change.

v2.1.50 prepared for this silently:

  • Added CLAUDE_CODE_DISABLE_1M_CONTEXT env var (why disable something that's free?)
  • Added /extra-usage command (why monitor something that wasn't being charged?)

2. No real-time billing feedback

Extra Usage charges from Feb 25 sessions were NOT reflected on Feb 25. They only appeared on Feb 26. Users cannot monitor or control spending if charges are delayed by 24+ hours.

3. Contradictory documentation

  • Model picker UI: "Billed as extra usage" (no threshold mentioned — implies ALL tokens)
  • Official docs (code.claude.com): "Standard rates until 200K, extra usage after 200K"

Which is correct? Users cannot make informed decisions with conflicting information.

Impact

  • Max plan ($100/month) subscribers lose access to 1M context without additional payment
  • The feature that was previously included is now paywalled
  • No migration path or notice was provided
  • Disabling Extra Usage to prevent charges also disables 1M models entirely

Request

  1. Acknowledge that 1M billing changed in v2.1.51 and was not documented
  2. Credit Extra Usage charges incurred between v2.1.50 → v2.1.51 transition (users had no way to know)
  3. Fix real-time billing feedback — charges must be reflected immediately, not 24h later
  4. Clarify the documentation: is it ALL tokens or only >200K that count as extra usage?
  5. Add opt-in consent before switching to extra usage billing (similar to what the model picker now shows, but as an explicit confirmation dialog)

Related issues

  • #23680 — Max subscribers should have full Opus 4.6 access without Extra Usage
  • #27603 — Rate limit on Sonnet 1M ("Extra usage is required for long context requests")
  • #26428 — Sonnet 1M disappeared from model picker after v2.1.45
  • #22435 — Undisclosed quota accounting changes (10x variance in burn rates)

Reproduction

  1. Have JSONL transcripts from v2.1.50 sessions using Opus 1M
  2. Compare Extra Usage meter before and after updating to v2.1.51+
  3. Observe that identical (or lower) usage now consumes Extra Usage

I have full JSONL session transcripts with token-level data available for investigation.

View original on GitHub ↗

16 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/26428
  2. https://github.com/anthropics/claude-code/issues/22435
  3. https://github.com/anthropics/claude-code/issues/27603

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

paulseongminpark · 4 months ago

Important correction: 1M context WAS included in Max plan

To clarify my timeline: I upgraded from Pro to Max plan specifically to get more usage. After upgrading to Max, 1M context usage did NOT consume Extra Usage — it was fully covered by the Max subscription for weeks.

This is not a case of "1M was always extra usage and I didn't notice." The data proves it:

  • Feb 22 (v2.1.50, Max plan): ~$442 worth of Opus 1M usage (3,562 API calls, 473M cache_read tokens) → Extra Usage: unchanged
  • Feb 23 (v2.1.50, Max plan): ~$168 worth of Opus 1M usage (1,366 API calls, 158M cache_read tokens) → Extra Usage: unchanged
  • Feb 25 (v2.1.51+, Max plan): $105 worth of Opus 1M usage (738 API calls, 101M cache_read tokens) → Extra Usage: +$48.79

The Max plan was covering 1M context. After the v2.1.51 update, it stopped covering it. Same plan, same price, reduced coverage — with no notification.

This makes the billing change even more problematic: it's not just an unclear policy from launch. It's a retroactive reduction of Max plan benefits delivered through a silent software update.

paulseongminpark · 4 months ago

Critical clarification: Current Session had remaining capacity

I need to correct my earlier framing. The core issue is simpler and more serious than I initially described.

Setup:

  • I purchased $50 of Extra Usage credits while on Pro plan (for session limit overflows)
  • I upgraded to Max plan ($100/month)
  • After upgrading, my Current Session limits were sufficient — Extra Usage was never touched
  • I used both Sonnet 1M and Opus 1M for weeks with no Extra Usage consumption
  • The $50 credits sat untouched

What happened on Feb 25 (after v2.1.51 auto-update):

  • Current Session usage still had remaining capacity
  • Despite this, Extra Usage started being consumed
  • $48.79 of my $50 credits were drained in one day

This is the real bug:

The normal billing flow should be:

Current Session (subscription) → exhausted → Extra Usage kicks in

What actually happened after v2.1.51:

1M context usage → bypasses Current Session → goes directly to Extra Usage

The 1M context models stopped counting against the subscription allocation and started billing directly to Extra Usage, even when the subscription had remaining capacity. This is not a case of "I used too much" — the system changed which billing bucket 1M tokens are assigned to.

This also explains why the model picker now shows "Billed as extra usage" for 1M models — it's not just a label, it's a fundamental billing routing change introduced in v2.1.51.

paulseongminpark · 4 months ago

The usage UI actively misled me

One more critical detail: I was monitoring usage throughout my sessions. The Claude Code usage indicator only showed Current Session usage increasing. There was no indication that Extra Usage was being consumed simultaneously.

What the UI showed:

Current Session: ████████░░ (increasing normally)
Extra Usage:     (not displayed / no change shown)

What was actually happening:

Current Session: ████████░░ (increasing normally)
Extra Usage:     silently draining $48.79 in the background

I only discovered the Extra Usage charges by separately checking my account balance on claude.ai the next day. The Claude Code interface gave no signal that anything was different from normal subscription usage.

This means even a diligent user who actively monitors their usage (as I was doing) has no way to detect that 1M context requests are being routed to Extra Usage. The UI presents a "normal" current session consumption pattern while silently billing to a different account.

This is not just a missing notification — it's actively misleading billing UX.

paulseongminpark · 4 months ago

Correction to my previous comment

I want to correct my last comment — the Extra Usage meter IS visible in the Claude Code UI. I was monitoring both meters throughout all sessions:

  • Current Session usage: always visible, always tracked
  • Extra Usage: always visible, always tracked

Timeline of what I observed:

Pro plan era: Current Session would fill up → Extra Usage would increase (normal overflow behavior)

After Max plan upgrade (weeks before Feb 25): Current Session would increase normally → Extra Usage stayed flat, never moved. This was true even when using Opus 1M and Sonnet 1M heavily for weeks.

Feb 25 (after v2.1.51 update): Current Session was increasing normally AND Extra Usage started increasing simultaneously — even though Current Session had NOT been exhausted.

The issue is not that Extra Usage was hidden. The issue is that Extra Usage started being consumed in parallel with Current Session, instead of only after Current Session was exhausted. This broke the established billing flow that I had observed for weeks on the Max plan.

Before v2.1.51: Current Session → (only if exhausted) → Extra Usage
After v2.1.51: Current Session going up + Extra Usage going up simultaneously

paulseongminpark · 4 months ago

Additional Evidence: Per-Call Context Analysis Confirms v2.1.51 Billing Change

I analyzed JSONL session transcripts across all projects to check per-call context window sizes (input_tokens + cache_read_input_tokens per API call) before and after v2.1.51.

Data Table

| Date | Version | Sessions | API Calls | >200K calls | % | Extra Usage |
|------|---------|----------|-----------|-------------|---|-------------|
| 2/21 | v2.1.49/50 | 10 | 1,992 | 448 | 22% | ❌ None |
| 2/22 | v2.1.50 | 9 | 2,193 | 321 | 14% | ❌ None |
| 2/23 | v2.1.50 | 11 | 2,771 | 626 | 22% | ❌ None |
| ↑ v2.1.51 update | | | | | | |
| 2/25 | v2.1.52/53 | 4 | 794 | 209 | 26% | ✅ Appeared next day |

Key Finding

200K+ per-call context was happening before v2.1.51 too — 14~22% of all API calls exceeded 200K context on Feb 21-23. Zero extra usage was charged.

After v2.1.51, the same pattern (26% of calls >200K) resulted in extra usage charges appearing the next day.

Additional Observation: 24-Hour Billing Delay

The extra usage charges do not appear in real-time. I was monitoring the meter in real-time during the Feb 25 e2e test session — extra usage showed no change. The charges only appeared on Feb 26 morning, making it impossible for users to see the impact while working.

The Feb 25 session (v2.1.52) breakdown:

  • Total API calls: 392
  • Max context per call: 359K
  • Calls exceeding 200K: 209/392 (53%)
  • >300K: 84 calls
  • >200K: 125 calls

Conclusion

This data rules out "user workload increased" as an explanation. Identical or higher 200K+ call rates in Feb 21-23 produced zero extra usage under v2.1.50. The billing change is clearly tied to the v2.1.51 update.

paulseongminpark · 4 months ago

Core Contradiction: 1M Context Is Effectively a Paid Add-On, Not a Subscription Feature

The Problem

Max plan (\00/month) advertises 1M context models. However, since v2.1.51:

  • Any API call where context exceeds 200K → excess tokens billed as extra usage
  • 1M context sessions naturally exceed 200K mid-session (as conversation history accumulates)
  • This means using 1M context as intended inevitably generates extra usage charges

The Billing Split

Two independent meters are running simultaneously:

| Meter | What it tracks |
|-------|---------------|
| Current session usage | Only counts the ≤200K portion of each call → subscription budget |
| Extra usage | Counts the >200K portion of each call → billed separately |

These two meters operate independently. My current session usage was at ~70% (30% subscription capacity remaining) when extra usage charges were accumulating. The subscription budget is not exhausted — it's simply bypassed for any tokens above 200K per call.

Before v2.1.51

This split did not exist. All tokens — regardless of per-call context size — were processed through the subscription. I used 1M context Opus daily for weeks with identical workloads (14-22% of calls exceeding 200K per our JSONL analysis) and zero extra usage charges.

The Implication

If 200K+ tokens per call always route to extra usage regardless of subscription capacity, then 1M context is not a subscription-included feature — it's a paid add-on that requires extra usage credits to function. This was not communicated to Max plan subscribers, and it contradicts the previous billing behavior under v2.1.50.

What I'm Asking

  1. Was this billing change intentional or a bug introduced in v2.1.51?
  2. If intentional, why was there no announcement or changelog entry?
  3. Will the charges incurred under this new behavior be refunded?
paulseongminpark · 4 months ago

Definitive Proof: v2.1.50 vs v2.1.52 — Same Workload, Different Billing

Session-Level Comparison

Here is a direct comparison between the heaviest session under v2.1.50 and the session that triggered extra usage under v2.1.52:

| Metric | 2/23 session (v2.1.50) | 2/25 session (v2.1.52) |
|--------|----------------------|----------------------|
| Total API calls | 1,567 | 392 |
| Opus calls | 814 | 392 |
| Calls >200K context | 517 | 209 |
| Max context per call | 305K | 359K |
| Cache read tokens | 263.7M | 80.2M |
| Extra usage charged | None | Yes (appeared next day) |

The Feb 23 session was 2-3x heavier by every metric — yet generated zero extra usage.

Full Session Breakdown (Feb 20-26)

Date         Version   Calls  Opus  >200K  MaxCtx  Cache
─────────────────────────────────────────────────────────
2026-02-21   v2.1.50    484     0    165   315K    75.6M   ← No extra
2026-02-21   v2.1.50    454     0    180   360K    77.9M   ← No extra
2026-02-21   v2.1.49    381     0    103   309K    57.9M   ← No extra
2026-02-22   v2.1.50    713     0    193   298K   101.0M   ← No extra
2026-02-22   v2.1.50    393   393      0   161K    39.0M   ← No extra
2026-02-22   v2.1.50    162   162     12   210K    19.7M   ← No extra
2026-02-23   v2.1.50   1567   814    517   305K   263.7M   ← No extra
2026-02-23   v2.1.50    265   265    109   239K    45.3M   ← No extra
──────────── v2.1.51 update ─────────────────────────────
2026-02-25   v2.1.52    392   392    209   359K    80.2M   ← EXTRA CHARGED

Conclusion

  • Before v2.1.51: 2,696 calls exceeding 200K context across multiple sessions → zero extra usage
  • After v2.1.51: 209 calls exceeding 200K context in one session → extra usage charged next day

The workload did not change. The version did. This is a billing behavior change introduced in v2.1.51 without any notice to subscribers.

mik3fly · 4 months ago

Hello, any news on this bug?

cyruszad · 4 months ago

Okay, so I'm really disappointed, I don't understand what's going on. Wasn't the 1000000 token context window supposed to be included in this max plan?

wiggy9999 · 4 months ago

maybe they'll add it back in the future, it's very likely due to capacity reasons

cyruszad · 4 months ago

Well I just cancelled my subscription. Sucks. Very misleading claims.

On Mon, Mar 9, 2026 at 11:31 PM LEW @.***> wrote:

wiggy9999 left a comment (anthropics/claude-code#28927) <https://github.com/anthropics/claude-code/issues/28927#issuecomment-4029033193> maybe they'll add it back in the future, it's very likely due to capacity reasons — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/28927#issuecomment-4029033193>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKEK54M2CZ6MAYO2DG33QQD4P6ZFDAVCNFSM6AAAAACWAJYLTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMRZGAZTGMJZGM> . You are receiving this because you commented.Message ID: @.***>
SDpower · 3 months ago

I've done extensive JSONL analysis on this problem. One session: API real cost $1.47, total billed $64.98 — 97.7% was cache overhead. Cache also degrades instruction following in long sessions (verified with per-turn data).
Full analysis: https://blog.sd.idv.tw/en/posts/2026-03-25_claude-code-cache-trap/
10 practical tips: https://blog.sd.idv.tw/en/posts/2026-03-25_claude-code-10-tips-save-money/
Tool: https://github.com/SDpower/ccusage_go

anarolabs · 2 months ago

Confirming this is still happening as of 2026-05-12.

  • Plan: Max
  • Symptom: "Extra usage is required for 1M context" errors during normal Claude Code sessions
  • Extra usage charges accumulating despite Max plan utilization being well below the included limit
  • Approximate extra spend incurred so far: ~€5

Happy to share session data or extra-usage receipts if it helps narrow this down.

This is insanely annoying - preventing proper work from working. Is this a bug or has this been removed by policy? Honestly Anthropic what a way to burn through CX trust...

ThatDragonOverThere · 2 months ago

Confirming another variant as of 2026-05-12, v2.1.139. 10 agent-mode windows configured as Sonnet, billing ran Opus for 11 hours overnight. 80% of weekly usage consumed for crons and polls and nothing completed. The model picker shows the correct model on step 1, reveals Opus on step 2 — after the billing has already been running all night.

Same core problem you documented here: billing behavior diverges silently from what the interface displays, and the first signal is the usage wall. Full incident: #58450.

wozcode-helper · 8 days ago

ngl that silent switch in v2.1.51 making 1M context consume extra usage even though your jsonl shows identical workload is a huge bug, and the 24+ hour delay on charges made it impossible to monitor spend. fwiw wozcode cut my token spend ~50% with better caching, might help while this gets sorted https://wozcode.com