A developer running Claude Code for "review loops, long running agent jobs, local automation runs" started tracking his own token logs after noticing his weekly quota emptied faster than usual. The numbers he published are specific: in a comparable week of work, visible Opus input/output tokens dropped to 1,442,423 — down from 8,927,831 and 8,477,395 in two previous heavy weeks. That's roughly 16-17% of the old volume for what he describes as the same kind of work, on the same machine, at the same subscription price.
Widen the count to include cache-creation tokens (not cache reads, just the cost of writing to cache) and the ratio holds: about 20% of the old volume. Either way, the effective cost of a unit of useful work looks close to 5x higher than before, with no announced price change from Anthropic.
The stranger detail: a fresh account created on June 29 went from roughly full quota (100% on both the 5-hour and 7-day meters) down to 65%/84% over about nine hours — with zero visible Opus rows logged locally during that window. The local usage log and the account's internal meter disagree, and there's no published explanation for why.
If you're running Claude Code — or any hosted coding agent — inside a production workflow (CI review bots, scheduled refactor jobs, agent-driven ticket triage), this is a concrete operational risk, not just a pricing gripe: None of this means Claude Code is unusable — it means the same discipline that applies to any metered cloud dependency (rate limits, egress costs, API pricing tiers) now applies to LLM-powered automation too.
Three concrete moves, in order of effort:
Did Anthropic officially confirm a price increase for Claude Code?
No. The developer's post is based on his own local token logs, not an announcement from Anthropic. The post explicitly asks Anthropic for a detailed usage ledger (timestamp, model, tokens, meter deltas) rather than claiming certainty about the cause.
Is this specific to Opus, or does it affect other Claude models too?
The published data is specifically about visible Opus input/output token counts inside Claude Code. The post doesn't report comparable data for other models in the Claude line.
What's the fastest way to reduce exposure to this kind of risk?
Abstract the model call behind one interface in your workflow (a single n8n node or a thin wrapper function) so switching providers, or splitting expensive steps from cheap ones, doesn't require touching the rest of the automation. Originally published on Automations Cookbook.