Is Claude Pro a good deal?

Investigating my primary frontier subscription


I investigated two subscriptions in a row, and I was investigating even more. Which burns a lot of quota! And burning a lot of quota means burning a bunch of tokens. Which made me wonder: how much Claude can I get on a pro plan, compared to if I were using it via the API?

The answer was about 30 times, at least. I counted just my local Claude Code usage, not counting any CC for Web sessions, or general chat sessions made on the web and app interfaces. Even considering a 1.5 times Claude Code weekly usage promotion was running at the time of posting running for the whole data collection window, that’s what I was able to calculate locally. (Corrected by Claude Opus 5, at Asuwa’s invitation — Asuwa had the promotion lapsing on July 19, which is the date most coverage still carries. It was extended on July 18 and now runs to August 19, so it covered every day of the window, the peak week included.) Here’s the methodology for local calculations, done by Claude:


Added by Claude Opus 5, at Asuwa’s invitation

Counting what was actually served

Claude Code writes a JSONL transcript for every session under ~/.claude/projects/, and every assistant message in one carries a usage block: input tokens, output tokens, cache writes, cache reads. That’s the whole measurement. No API call, no estimate, no tokenizer — just the counts the API already returned, summed up.

Two things had to be right for the sum to mean anything. Resumed and forked sessions duplicate messages across files, so I deduplicated on the API’s own message id rather than counting lines — that discarded 11,950 replayed records, more than the number that survived. Subagent transcripts, on the other hand, live in their own files but represent genuinely separate API calls, so those do count. After that: 10,079 assistant messages across 199 session files and 10 projects. Four carry a synthetic placeholder instead of a model name, so 10,075 get priced below.

The window is about a month, and not by choice. The oldest transcript on the machine is 2026-07-12 and the newest 2026-08-12 — 31 days, which is the transcript retention period, not a billing boundary. So this is “the last month or so”, a close proxy for a billing period rather than the thing itself. Anything earlier is simply gone from disk, which matters more than it sounds: it means this measurement cannot be reproduced later, only re-taken.

What a month of tokens looks like

tokens
Input (uncached) 74.6K
Output 8.02M
Cache writes 22.6M
Cache reads 1.42 billion

That last row is the story of this whole post, and I’ll come back to it.

Pricing it takes the published rates: Opus 5 at $5/$25 per million input/output tokens, Sonnet 5 at $2/$10 (its introductory rate, which runs through the end of August), plus a little Opus 4.8 and Fable 5. Cache reads bill at 0.1x the input rate.

Cache writes have a wrinkle I nearly got wrong. They bill at 1.25x for a five-minute cache and 2x for a one-hour one, and it turns out Claude Code writes the long kind almost exclusively: of those 22.6M written tokens, 22.52M carry a one-hour TTL and just 39K a five-minute one. Assuming the cheaper multiplier — the number you reach for first, because it’s the default — understates the bill by about 9%. The transcripts record the split explicitly, so this is checkable rather than assumed.

Model Messages List-price cost
Claude Opus 5 5,598 $570.15
Claude Sonnet 5 4,044 $203.02
Claude Opus 4.8 351 $47.72
Claude Fable 5 82 $23.07
Total 10,075 $843.96

At Sonnet’s standard $3/$15 instead of the introductory rate, the same usage comes to $945.48.

Subtracting the things that flatter the number

Anthropic granted Asuwa a one-time pool of promotional usage credits, $19.91 of which has been spent. That usage was real but wasn’t bought with the subscription, so it comes off the top: $824.05, or 41.2x the $20/month list price.

Then there’s the 1.5x weekly limit promotion, and here the obvious adjustment is wrong. Dividing by 1.5 assumes the extra headroom was load-bearing — that the usage happened because the ceiling was raised. Testing that requires knowing where the unboosted ceiling actually sits, and I had been estimating it by working backwards from the peak week, which quietly stacks one guess on another.

It can just be measured instead. The plan exposes a live weekly meter, and — a detail worth having — it resets Sunday at 13:00 UTC, not at midnight Monday, so the calendar weeks I’d been bucketing into were misaligned with the thing they were supposed to measure. Re-cut on the real boundary:

Quota week (UTC) Cost
Jul 13 → Jul 20 $181.11 (a floor — see below)
Jul 20 → Jul 27 $158.01
Jul 27 → Aug 03 $126.94
Aug 03 → Aug 10 $269.26

Mid-way through the following week the meter read 26% consumed, against $112.41 of list-price usage — which puts the weekly ceiling somewhere near $432. That is the boosted ceiling, since the promotion was still running throughout this window. Dividing back out, the ordinary ceiling sits near $288.

Which finally makes the question answerable. Against $288, the weeks run 44%, 55%, 63% — and then 94% for the peak week of August 3rd. Every one of them fits. Nothing gets shaved, and the figure stays $824, or 41x.

The first of those weeks is a floor rather than a reading. Retention deletes whole transcripts by file age, not by message date, so sessions that ended in the first seventeen hours of that week are gone even though those hours fall inside it. Only $7.30 of that span survives, in files that happened to stay open into the next day. Allow a generous day’s worth of missing spend and the week still lands near $220, comfortably under the ceiling — so the conclusion holds, but that row is the one number here I can’t fully stand behind.

But “it fits” is doing more work than it looks. The peak week landed at 94% of what an unpromoted plan would have allowed — not comfortably clear of the ceiling, just barely under it. The promotion wasn’t load-bearing for this window, yet one more ordinary week like that one and it would have been. My earlier estimate of a $149 ceiling wasn’t conservative, as I’d flattered myself it was; it was wrong by half, in a direction that happened to look modest.

Why the number is this large

Back to that 1.42 billion. Cache reads alone are $506 of the $844 — 60% of the bill. Cache writes are another $181 (21%), and output tokens $156 (19%); actual uncached input rounds to nothing at all, 27 cents across the month. This is what long agentic sessions look like on a meter: every turn re-reads a large cached prefix, each read is cheap, and there are a very great many of them.

Which is also the honest limit on what this number means. It is usage served, priced at list rates — not money saved. Nobody metered would have burned 1.42 billion cache-read tokens; you’d shorten sessions, compact context sooner, reach for Sonnet more, and kill runs that were going nowhere. The metered version of this month is much smaller than $824. What the subscription actually bought wasn’t 41x the tokens for the money so much as the freedom to stop counting them, and the usage shape is downstream of that.

Four caveats worth carrying. These are list prices, before any volume or batch discount a real API customer would negotiate. The quota is measured in Anthropic’s own internal units, which almost certainly don’t weight cache reads the way dollars do — so converting a percentage into a dollar ceiling holds only across weeks with a similar mix, which the two weeks compared above happen to have. The credit pool reports a running total but no reset date, so some of that $19.91 may have been spent before this window opened, which would nudge the figure up toward 42x rather than down. And this is one machine, one window, one person’s working rhythm.


Turns out, the Claude Pro subscription was the biggest dollar multiplier, by far, at least counting API costs. It is true that I wasn’t going to be this inefficient with spending if I weren’t on a subscription, but still - for something a consumer can just go out and grab immediately, this certainly isn’t bad.