5 Things Claude Code Pricing Does Not Tell You

Last updated: September 2026

Claude Code pricing is not hidden. The plan tiers are on one page, the per-token rates are on another, and both are accurate. That is exactly the problem: people read those two pages, do some arithmetic, and arrive at a number that has almost nothing to do with what they will actually spend. Everything below comes from a month of session logs, one controlled measurement across five models, and one afternoon where I burned a full top-tier plan allowance in twelve minutes in front of a student. Five gaps, in the order they usually bite.

In this post: Tokens are not tasks · The ranking inverts · Fan-out, not prompt length · The number nobody publishes · Idle is not free

1. The pricing page prices tokens. Your bill is decided by task shape

So how much does Claude Code cost? There is no standalone Claude Code subscription. It comes with a paid Claude plan: Pro at $17 a month billed annually or $20 monthly, Max at $100 or $200, Team at $20 per seat. The API rates below are separate, and neither number predicts your bill.

Per-token rates are the easiest thing to compare and the least useful. As of September 2026 the published rates are Opus 5 at $5 per million input and $25 output, Sonnet 5 at $2 and $10, Haiku 4.5 at $1 and $5, and Fable 5 at $10 and $50, all confirmed on Anthropic's pricing docs. Look at that list and Opus 5 costs five times Sonnet 5. Reasonable conclusion, wrong unit.

I ran a controlled test with a student. One prompt, a falling-sand particle simulation with eight interacting materials. One shot, no follow-ups, nothing held back. Five models, each asked to report its own tokens, cost and wall-clock time.

Model	Tokens	Cost	Time
Opus 5	~8,000,000	~$10	21 to 22 min
Fable 5	~890,000 to 1M	~$4	11 to 12 min
Sonnet 5	210,000	~$0.50	14 min
Opus 4.8	78,000	~$0.73	7 min 10 s
Haiku 4.5	not recorded	~$0.0034	~35 s

Opus 5 and Opus 4.8 have identical published rates. On this task one cost roughly fourteen times the other, because it generated roughly a hundred times the tokens. The rate was never the variable. Verbosity was.

Two of us looked at the finished simulations independently and could not tell them apart. The only behavioural difference anyone found was that fire burned sand in one build and not the other.

Part of the mechanism is documented, and worth knowing before you compare any two model generations on price. Anthropic notes that Claude 4.7 and later use a newer tokenizer that "produces approximately 30% more tokens for the same text." Newer models also lean on extended thinking by default, and thinking tokens bill as output. So a model can be identically priced, genuinely better, and still cost you several times more on the same job.

If you want to run this yourself, and you should, the method matters more than the prompt. Make the task visual, so failure is obvious to the eye rather than buried in a test report. Build in many chances to fail, because a task that is too easy grades every model the same. Give one shot with no follow-ups, since the moment you start correcting a model you are measuring your own patience instead of its output. And hold everything else constant: same prompt, same project, same day.

The fix: Never compare models on published rates. Run your own real task once on each candidate, record tokens and wall-clock time, and compare total cost per finished task. The measurement takes an afternoon and it is the only number that is yours.

2. The cheapest model on your last task is the most expensive on your next one

Here is where I have to argue against my own table.

That falling-sand result is one task, and I now think it is the outlier. Three separate signals point the other way, and I would rather you get them from me than from someone in the comments.

The first is aggregate benchmarking. Artificial Analysis puts weighted average cost per task at roughly $2.75 for Fable 5 and $2.03 for Opus 5. On aggregate, across many tasks, Opus 5 is the cheaper model per finished job. My single test said the opposite.

The second is a harder test I ran in the same month, with a tighter control. A 2D rigid body physics engine, built from a 597-line specification, no physics libraries allowed, with one pass condition: a ten-box stack has to stand still for thirty seconds with no jitter, drift or collapse. Both builds came from byte-identical spec files, so the control is real rather than approximate. Opus clearly beat Fable on that build. The ranking flipped.

The third is simply months of daily use. Opus 5 has outperformed Fable 5 for me on a lot of work, and that is a larger sample than either test.

So the honest finding is not "Fable is cheaper" and it is not "Opus 4.8 wins". It is that the ranking inverted between two tests run by the same person, in the same month, using the same method, and the only thing that changed was the shape of the task. A visual particle simulation rewarded one model. A rigorous engine build rewarded another.

That is a more useful conclusion than a leaderboard, because it survives contact with your situation. It also means the confident cost comparisons you read, mine included, are describing someone else's workload. A benchmark is an average of tasks that are not yours. A pricing page is a rate, not a bill. And one test, even a careful one you ran yourself, is one sample.

The fix: Treat any model cost ranking, including your own, as valid for one task shape until proven otherwise. Re-measure when the kind of work changes, not when the pricing changes.

3. The blow-up comes from fan-out, not from prompt length

This is the expensive one, and it is the gap I see most often.

People budget for prompt length. They worry about pasting a long file, or about a conversation getting too long. Those are real costs and they are gradual. The thing that actually empties an allowance is one short instruction that fans out into parallel agents, each carrying its own context window.

I did this to myself in front of a student, unplanned. I asked for a thorough full-project code review, on the most expensive model, with every skill loaded. It spawned roughly ten subagents. One of them alone consumed 300,000 tokens. I went from 1% usage to 100% in about twelve minutes on the top-tier plan, got locked out for four hours, and the review did not even finish. Then I was offered an upgrade.

The instruction was fifteen words. The bill was not about those fifteen words.

Anthropic documents the mechanism plainly. On the parallel agents page: "Running several sessions or subagents at once multiplies token usage." On the costs page, for agent teams specifically: "Agent teams use approximately 7x more tokens than standard sessions when teammates run in plan mode, because each teammate maintains its own context window and runs as a separate Claude instance."

There are guardrails, and their existence tells you this is a known failure mode. Claude Code caps concurrent subagents at 20 by default via CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, and caps nesting depth at 3 via CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH. Worth knowing: there is no cap on the total number of subagents spawned over a whole session, only on how many run at once and how deep they nest.

The practical difference is in how you scope the request, not in how long it is:

# One instruction, ten agents, ten context windows, one locked-out afternoon
Do a thorough review of the whole project.

# Same goal, one context, a bill you can predict
Review src/auth/ only. Report findings as a numbered list.
Do not open files outside that directory.

Most of what I do in a session is catch this kind of thing before it costs someone a day. That is most of what my 1-on-1 sessions are.

The tell, if you are watching for it, is the moment the output stops being one stream and becomes a list of workers starting up. That is the point where your Claude Code cost stops being a function of what you typed and starts being a function of how many contexts just opened. You have a few seconds to press Escape, and pressing Escape is almost always cheaper than letting it finish.

There is a legitimate use for all of this, and I do not want to talk you out of it. Fanning work out across agents is genuinely the right call for a large migration or a codebase-wide audit, where the alternative is a single context that fills up and starts forgetting the beginning. The mistake is not using subagents. The mistake is using them by accident, on a Tuesday, because a request was phrased broadly.

The fix: Before running anything with the words "thorough", "full", "entire" or "across the codebase" in it, scope it to a directory and say so explicitly. Check /usage immediately after any task that spawned agents, not at the end of the day.

4. Nobody publishes the number you actually want

So how do Claude Code usage limits work? Two windows run at once. A session limit resets every five hours, and a weekly limit resets at a fixed time assigned to your account. Both are shared across Claude Code, the Claude apps and Cowork, drawing from one pool. Anthropic publishes no hour or message figure for either.

Every week someone asks me how many hours of Claude Code they get on Pro. There is no published answer, and it took me a while to accept that this is deliberate rather than something I had failed to find.

Here is what is actually published, as of September 2026:

Plan	Price	Claude Code
Free	$0	Not included
Pro	$17/mo annual, $20 monthly	Included
Max 5x	$100/mo	5x Pro usage per session
Max 20x	$200/mo	20x Pro usage per session
Team	$20/seat annual, $25 monthly	Included, with Cowork

Notice what those Max rows say. They are relative figures, expressed as multiples of a base number that is itself never stated. Anthropic describes limits as a session window that resets every five hours plus a weekly window that resets at a fixed time assigned to your account, and consistently declines to attach a message count, a token count or an hour count to either.

Two consequences matter for your Claude Code usage limits. First, any article that tells you Pro gives you a specific number of messages or hours is publishing a third-party estimate, not a documented figure, and you should treat it accordingly. I cannot give you that number either, and I have looked.

Second, and this one genuinely surprises people: the allowance is shared. Claude Code, the Claude apps and Cowork all draw from the same pool. A morning of chat on your phone reduces what is left for the terminal that afternoon. Anthropic states it directly for Team and Enterprise seats, where the allowance "is shared with Claude chat and Cowork."

The only published dollar figures that are any use for planning are enterprise averages: around $13 per developer per active day and $150 to $250 per developer per month, with 90% of users staying under $30 per active day. Those are useful as a sanity check on whether your spend is unusual. They are not a quota.

There is one escape hatch worth understanding before you need it, because the moment you need it you will be annoyed and not reading carefully. Usage credits let you keep working past the ceiling. Anthropic's wording: they "allow individuals subscribed to paid Claude plans (Pro, Max 5x, and Max 20x) to continue using Claude seamlessly after reaching their included usage limits," and they are billed at standard API rates. So the instant you cross your allowance, you stop being on a subscription and start paying per token at the rates in item one. There is a $2,000 daily redemption ceiling and you can set your own monthly cap, which you should do on the day you turn credits on rather than the day you discover you did not.

This changes how the plan question should be asked. The real comparison is not Pro against a Claude Code Max plan on price. It is whether your work fits inside an allowance at all, because a Pro plan plus heavy credit spend can quietly cost more than the Max tier that would have covered the same work outright. That is a question you can only answer with a week of your own numbers.

The fix: Stop trying to find the published limit, because there is not one. Establish your own baseline instead: run a normal week, check /usage daily, and learn where your own ceiling sits. Then set a monthly spend cap before you turn on credits, and remember that your phone counts against the same pool.

5. An idle session is not a free session

The last gap is the one that makes people think the meter is broken.

A session you have had open all day, where you have only asked a handful of short questions, can consume far more of your allowance than the questions warrant. This is not a bug and it is documented, though not on any page you would visit while choosing a plan.

The reason is that the conversation goes with every request. Anthropic puts it this way: Claude Code "sends your full conversation with every request, and each time Claude uses tools it sends another request carrying that batch of tool results," so "a one-line question in a session that has been open all day still draws usage for the whole conversation." Prompt caching softens this considerably, since re-read history bills at the much lower cached rate, but it does not make it free.

Then there is the cache itself. Cache lifetime is one hour on a subscription, dropping to five minutes once you are drawing on usage credits. Come back from a two-hour lunch and your first message misses the cache and reprocesses the entire context at full rate. Background work adds a little more: conversation summarization and status checks run even when you are doing nothing, typically under $0.04 per session.

You can see all of this rather than guess at it:

/usage

Total cost:            $0.55
Total duration (API):  6m 20s
Total duration (wall): 6h 33m 10s
Usage by model:
   claude-sonnet-4-6:  1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)

Read the ratio, not the total. In that example the cache read figure is roughly 150 times the fresh input. That is a long-lived session re-reading its own history, which is exactly the pattern this item is about.

Two caveats on that screen, both worth knowing before you quote it at anyone. The dollar figure is computed locally at standard list rates, so Anthropic notes it "may differ from your actual bill" and does not reflect discounts. And on a Pro or Max plan the session cost is not what you are billed anyway, since your usage is included. On a plan, the useful part of /usage is the plan usage breakdown underneath, which attributes recent consumption to skills, subagents, plugins and MCP servers, and flags any behaviour accounting for 10% or more of it.

The habit this replaces is the one most people arrive with: keeping one session open all week because it "knows the project". It does not know the project. It is re-reading a transcript of the project on every single request, and the longer that transcript grows the more each trivial question costs. A short session that starts from a written brief is both cheaper and better, which is the whole argument for keeping a handoff file Claude can debug from rather than a conversation you are afraid to close.

The fix: Run /clear when you switch to unrelated work. Not at the end of the day, at the moment the topic changes. It costs nothing and it resets the history that every subsequent request has been carrying.

Start here

If you only act on one of these, make it the third. Fan-out is the only item on this list that can cost you an entire working day in twelve minutes, and it is the one nobody warns you about because the instruction that triggers it looks so small.

The thread running through all five is the same. Claude Code pricing describes a rate card, and a rate card cannot tell you what a task costs any more than a fuel price can tell you what a journey costs. What decides your bill is how verbose the model is on your kind of work, how many contexts your instructions open, and how long you leave a session carrying its own history.

1. Open your current project and run /usage. Note the cache read to input ratio and whether anything is flagged at 10% or more.
2. Take the next broad request you were about to make and scope it to one directory before you send it.
3. Run one real task on two different models, record tokens and total time for each, and keep the numbers. That is your baseline, and it beats every comparison article including this one.

Two things go deeper on specific items here. Loading Claude Code skills before you build covers the context cost side of item five, since loaded skills are part of what fills a session. And why the $20 AI coding era is over is the wider argument about where these prices are heading. If you want help setting a baseline for your own work rather than someone else's, bring your project to a free Discovery Call.

From the session logs of AI Tutor Code: 1-on-1 Python and AI tutoring for working professionals. Every figure above is either from a measurement I ran myself or from Anthropic's published documentation, linked where used.