This is all there is that it will show me:
So it is nice that this below exists—although this is out of date, from eight months ago, which is I don’t know what fifty-six dog years? It run through the roughly 90% off pricing for your first $200/month of use for the “Pro” tier, and roughly 93% off for your first $1500 or $3000/month of use for theMax 5x” or “Max 20x” tiers:
<https://she-llac.com/claude-limits> <https://she-llac.com/>
If you’re reading this, you’re probably aware that Claude’s subscription plans are a much better deal than the API. But how much better exactly, and what are the actual limits? I pulled out the exact values through two unrounded floats and found some notable things. I’ll explain how I did it later, but first, the results.
The 20× plan is not as good of a deal as you might expect. On Anthropic’s site, all mentions of “20× more usage*” have that pesky asterisk. It’s doing a lot of work. The five-hour session limits really are 20× higher than in Pro, but the real question is, how much work can you get out of it? The answer is: only twice as much per week as the 5× plan.
On the other hand, the 5× plan gives you great value for money. It overdelivers on what it promises pretty significantly. It’s the sweet spot of the pricing table. You get a six times higher session limit than Pro (not five), and more than eight times the weekly limit (more than the eponymous five).
Compared to API pricing, all plans come out looking fantastic. The value estimates in the table are lower bounds, since caching makes the effective API-equivalent even more favorable (as I’ll explain in a moment). In any case, if you can use plan pricing instead of the API, go for it.
There’s one thing that’s not in this table that’s very important.
Cache reads. They’re entirely free.
This makes the math even more stacked in favor of the plans. In an agentic loop (e.g. Claude Code), the model makes dozens of tool calls per turn. After every tool call, the model is invoked again. Cache read of the entire context. The API charges 10% for every read; subscriptions charge nothing. This adds up fast, as we’ll see in a second.
Cache writes are also discounted, they cost 1.25×/2× 1 the input price in the API, while on the plan they’re charged the regular input price. Every chat turn gets written to cache before it can be read, so this matters as well.
So what are these credits I keep talking about?
They’re the unit used internally to keep track of your plan usage. “Credits” is my arbitrary name for it, these values don’t appear directly in any API field so there’s no obvious word for them. I think “credits” sounds fine.
How do we get from credits to token counts? Here’s the formula:
credits_used = ceil(input_tokens × input_rate + output_tokens × output_rate)
...and the values you plug into it:
The specific values are pretty arbitrary-looking, but the ratios between them mirror API pricing: output costs 5× input, you’ll pay 5× more for Opus than Haiku, etc.
Let’s try it out on some practical numbers.
We’ll start with the realistic worst case: caching is enabled, but the cache is cold. (The true worst case is caching disabled entirely, but that’s rare.)
Subscription credits
ceil(100K × 2/3 + 1K × 10/3) = 70,000
API cost
Cache write: 100K × $5/M × 1.25 = $0.625
Output: 1K × $25/M = $0.025
Total: $0.650
Max 5× weekly
floor(41,666,700 / 70,000) = 595 req/wk
595 × $0.650 = $386.75/week
$386.75 × 52/12 = $1,676/mo
You're paying $100/mo -> 16.8× value
This is already great value, and it’s the real-world baseline (even with caching off, it was still ~13×). Once you’re in a loop and the cache is warm, it gets a lot better:
Notice we only count the 1K new tokens on the subscription side. On the API side, the 100K cache read still costs 10% of input.
Subscription credits
ceil(1K × 2/3 + 1K × 10/3) = 4,000
API cost
Cache read: 100K × $5/M × 0.1 = $0.05
Cache write: 1K × $5/M × 1.25 = $0.00625
Output: 1K × $25/M = $0.025
Total: $0.08125
Max 5× weekly
floor(41,666,700 / 4,000) = 10,416 req/wk
10,416 × $0.08125 = $846.30/week
$846.30 × 52/12 = $3,667/mo
You're paying $100/mo -> 36.7× value
Over thirty-six times more value than the API.
Okay, enough of the takeaways. I promised suspiciously precise floats.
How did I get all these numbers?
Last fall, a new tab appeared on the Claude.ai settings page. The usage tab, showing your remaining limits as two progress bars. 2 Very soon after, I found myself flipping back and forth between my Claude chats and that page. Especially if your chats are long (and uncached, but that’s a different story), those limits can run out
I decided to make an extension. 3 First, I looked at how the usage page itself was implemented. Pretty straightforward, a
/usage
endpoint returning a tiny JSON snippet with the numbers rounded to the nearest percentage point. That was enough for me, since what I really wanted was an easier way to view those numbers.But I kept digging, and soon found something interesting. On a Max 5× account, the SSE responses from the generation endpoint had usage values as unrounded doubles: 0.16327272727272726
.
Suspiciously specific. Almost looks like some kind of fraction converted to decimal. Can we recover the underlying fraction and get the real limits? Turns out we can.
When a real number becomes a float, it rounds to the nearest representable value. That float represents ALL rationals in a tiny interval [L, U) that would round to it. The width of that interval is ~10−17 for values in the 0–1 range we’re working with.4
The original fraction (before it became a float) must lie in that [L, U). We want to get the simplest fraction from that interval.
Why the simplest? Any decimal fraction can be converted to a common one, but that doesn’t give us any more info (in this example: 16327272727272726/100000000000000000). What we want to get is the original (which presumably has a denominator smaller than 100 quadrillion).
But wait, suppose the source fraction is 2/10, we would recover 1/5! Won’t getting the simplest fractions give us false positives? With one sample, yes. This is why we get multiple samples and later compute the lowest common denominator. If the true denominator were 10, we’d sometimes recover 5 or 2 (because everything gets simplified), but we’d never recover a denominator that doesn’t divide 10. So the LCM can only grow, it can’t overshoot the real limit. After a few samples, the chance of the real denominator being higher becomes vanishingly small.
So back to the bucket, how do we find the simplest fraction in it?
The Stern-Brocot tree is a binary search over ALL positive fractions, ordered by value, but constructed so that simpler fractions are found first. Starting from 0/1 and 1/0 (infinity), each step narrows toward the target interval. Here’s an example for finding the fraction for 0.4:
In our use-case, we’re not aiming for the exact number, but instead a very very small interval (~10−17). The process looks essentially identical either way.
Back to our original 0.16327272727272726
. The first in-bucket hit is a very small-denominator fraction (often the minimum-denominator one):
step 00: left=0/1 right=∞ mediant=1 -> mediant ≥ U, move left
step 01: left=0/1 right=1/1 mediant=1/2 -> mediant ≥ U, move left
step 02: left=0/1 right=1/2 mediant=1/3 -> mediant ≥ U, move left
step 03: left=0/1 right=1/3 mediant=1/4 -> mediant ≥ U, move left
step 04: left=0/1 right=1/4 mediant=1/5 -> mediant ≥ U, move left
step 05: left=0/1 right=1/5 mediant=1/6 -> mediant ≥ U, move left
step 06: left=0/1 right=1/6 mediant=1/7 -> mediant < L, move right
step 07: left=1/7 right=1/6 mediant=2/13 -> mediant < L, move right
step 08: left=2/13 right=1/6 mediant=3/19 -> mediant < L, move right
... 57 more steps ...step 66: left=8/49 right=417/2554 mediant=425/2603 -> mediant ≥ U, move left
step 67: left=8/49 right=425/2603 mediant=433/2652 -> mediant ≥ U, move left
step 68: left=8/49 right=433/2652 mediant=441/2701 -> mediant ≥ U, move left
step 69: left=8/49 right=441/2701 mediant=449/2750 -> HIT
Round-trip check: 449/2750
prints as 0.16327272727272726
✓
Each sample gives a denominator. The true limit D must be divisible by all of them. Example: 449/2750
and 11401/75000
both scale to a denominator of 3,300,000
.
Why does the limit have to be divisible by all of them? Because the utilization number is literally “used / limit”. When we recover a fraction from the float, we get it simplified. So the denominator we recover can only be a divisor of the real limit.
So you take a few samples, collect the denominators, and take their LCM. At first it will jump around. Then it stops. Once it stops across a bunch of different usage amounts, that LCM is your limit. You can still get unlucky, but after a few samples the odds get really small.
Lastly, how did I get the credit-token formulas and model multipliers? A whole bunch of manual data collection, then automated data collection after I modded my extension to save that data as I chatted. I put them all in a table and stared at them a lot. Asked Claude. Asked GPT. Came up with hypotheses, tested them, and ultimately ended up with the tables and formula above. I wish I had more to say on this but it was a bit of a chaotic process and I didn’t keep notes on it, the important part is that I’ve validated the final numbers and they check out exactly.
Side channels are everywhere. I don’t think anyone at Anthropic expected to leak their exact pricing table just by forgetting to round two numbers.
You should get a plan if you can. Claude Code on API pricing just doesn’t make financial sense compared to the plans for most people. The main exception is if you’re forced onto the API for organizational reasons (enterprise/team setups, procurement, etc.), in which case the comparison is less relevant.
If you care about Claude’s usage limits (and you’re at the bottom of an article that extensively explains them, so I assume you do), try my Claude Counter extension. It shows you the cache timer, the usage bars right in the composer box (with full precision) and more.
As of writing, the floats remain unrounded and suspiciously precise. I expect if this post gets any attention, that might not last very long. I’ll be a little sad about it because it’ll make my extension slightly worse. (I’ll have to rely on the /usage
endpoint, the same one the official usage page uses, which is rounded)
Comments on Hacker News or 𝕏Twitter.
1 1.25× for 5 minute cache, 2× for 1 hour cache.
2 Yeah, I know it’s 3 on the Max plans.
3 To be fair, first I found
4 IEEE-754 floats have a fixed number of mantissa bits, so precision is relative to magnitude. Larger floats have wider rounding buckets: ~10
5 1. Write down the problem. 2. Think very hard. 3. Write down the solution.
“SternBrocotTree.svg” by Aaron Rotenberg, modified and used under CC BY-SA 3.0 (source: Wikimedia Commons).
<https://she-llac.com/claude-limits> <https://she-llac.com/>
- Brad DeLong here*: My sense is that, what with all of Anthropic’s opaque moving pricing parts, Anthropic has maintained the rough relative relationship between subscriptions and API’s in terms of pricing-per-output-token, while delivering about 50% more value per dollar charged on the API tier. The subscription tiers are still enormous loss leaders: $20/month for your first $200/month of tokens at API rates for the “Pro” tier, and $100 or $200/month for your first $1500 or $3000/month of tokens at the “Max 5x” or “Max 20x” tiers.
What are the implications of this, for “AI” as a technology, as a source of user surplus, as a source of producer value, and as a source of financier, engineer, and investor fortunes?
