claude-code - 💡(How to fix) Fix [Bug] Opus 4.7 metering: cache_read_input_tokens consuming 5-hour bucket at input-token rate (Max $100) [2 comments, 1 participants]

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?

After Opus 4.7 rolled out, my Claude Code 5-hour usage bucket is being consumed ~7x faster than with Opus 4.6 on identical workloads. The data strongly suggests cache_read_input_tokens are being metered against the 5-hour bucket at full input-token weight instead of the documented reduced rate.

Ratio observed on the same account, back-to-back days:

• Opus 4.6 (Apr 15): ~190M total tokens in a 5h window → never hit the limit
• Opus 4.7 (Apr 16): ~30M total tokens in under 2h → 100% of 5h bucket consumed
• Effective cost-per-token is ~7x higher on 4.7 for workloads dominated by cache reads.

I already opened a support ticket with Anthropic. Support confirmed this behavior is "inconsistent with documented behavior" and referred me here.

What Should Happen?

Per Anthropic's documented pricing, cache_read_input_tokens should be charged at a heavily reduced rate (~10% of input tokens). This was clearly the case with Opus 4.6 — 186M cache-read tokens in a 5h window did not hit the limit.

Opus 4.7 should apply the same reduced rate. Metering behavior should not regress between model versions.

Error Messages/Logs

No runtime errors — this is a metering/billing anomaly visible in the Claude Code usage panel.

5-hour limit panel shows 100% used, resets in 3h, after only ~60 assistant responses in Opus 4.7.

Steps to Reproduce

1. On Max $100 plan with default Claude Code config, work a full session with Opus 4.6 → observe that a workload of ~700+ assistant responses and ~180M+ cache_read_input_tokens fits comfortably inside a 5h window.
2. Switch to Opus 4.7 (via /model claude-opus-4-7[1m] or by starting a new session after the 4.7 rollout).
3. Send a handful of normal requests (~60 assistant responses) with a typical cached context (~400k cached tokens per request).
4. Observe the 5h usage panel jump to 100% in under 2 hours — dramatically faster than with 4.6 on the same workload.

Data from my session (JSONL usage objects aggregated by hour, UTC)

Opus 4.6 — no limit hit:

Opus 4.7 — 100% hit:

Session JSONL with per-message usage available on request: ~/.claude/projects/-Users-lck-Documents-Unna-Towers-Interfaz/19adaea6-....jsonl

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

claude-opus-4-6 (Opus 4.6) — metering worked correctly until switching to 4.7 on Apr 16, 2026

Claude Code Version

2.1.111 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Support ticket already open — Anthropic support agent confirmed this pattern is inconsistent with documented cache pricing and directed me to file this bug.

Account plan: Max $100/month

Hypotheses (in order of likelihood):

1. cache_read_input_tokens weighting regression in Opus 4.7 — being counted at input-token rate instead of reduced rate.
2. Cache hits misreported — returning as cache_read in usage objects but billed as cache_create or full input.
3. Model-switch invalidation — switching from 4.6 → 4.7 invalidates cache entries in a way that inflates metering beyond what the usage field shows.

Willing to provide:

• Raw session JSONL (18MB) with all usage objects
• CSV hourly breakdown
• Screen recording of the 5h usage panel

Impact: On Max $100 plan I went from a normal working day (700+ responses) to hitting the limit in <2h with the same work patterns — effectively a 10x reduction in Opus throughput per dollar without any change on my end.