Claude Code cost in 2026: what Pro, Max and the API charge for the same work
The plan prices are flat and the token prices are public, so the comparison looks like arithmetic. It isn't quite, because Claude Code caches your conversation differently depending on how you pay, and the tool most people use to put a dollar figure on subscription usage prices the cache you had, not the one you would get.
Contents
Claude Code costs $20 a month on Pro, $100 on Max 5x and $200 on Max 20x, or whatever your tokens come to if you sign in with an API key instead. Anthropic’s own figure for API-billed teams is about $13 per developer per active day, $150 to $250 a month, and under $30 a day for 90% of users. Every price below is dated, because these change more often than the docs that quote them.
The harder question is the one behind the search: for the work you actually do, is the subscription or the API cheaper? The usual method is to run ccusage over your local transcripts, get an “API-equivalent” total, and compare it with the plan price. That works, with one catch. Claude Code writes its prompt cache with a one-hour lifetime on a subscription and a five-minute one on an API key, and the two are priced differently. I fed ccusage a synthetic transcript to see what it does with that: one million one-hour cache writes on Opus 5.5 came out at $8.00, one million five-minute writes at $5.00. It prices the cache you had, which is not the cache you would get after switching, and the error runs in either direction depending on how you work.
How much does Claude Code cost per month?
On a subscription, a flat fee: Pro is $20 a month ($17 a month billed annually), Max 5x is $100 and Max 20x is $200, all with Claude Code included, per claude.com/pricing and the Help Center on October 24, 2026. On an API key you pay per token, bounded by your account tier’s rate and spend limits and whatever caps you set yourself.
What the flat fee buys is an allowance. Max 5x and 20x give five and twenty times Pro’s per-session usage, the session allowance resets every five hours, and both Pro and Max have weekly limits on top. On Max, Fable gets 50% of the weekly limits, per the pricing page; on Pro it runs only on usage credits. Anthropic doesn’t publish how many tokens any of that is. Past the allowance, Pro and Max can turn on usage credits, billed at standard API rates.
The API side has a benchmark. Anthropic’s costs page says: “Across enterprise deployments, the average cost is around $13 per developer per active day and $150-250 per developer per month, with costs remaining below $30 per active day for 90% of users.” At that average, the Max 5x price buys about eight active days of API usage, and Pro about a day and a half. It is an enterprise average, so treat it as a sanity check, not a forecast for your own month.
What do Claude Code’s models cost on the API?
Per million tokens, as listed on the pricing page on October 24, 2026:
| Model | Input | 5-minute cache write | 1-hour cache write | Cache read | Output |
|---|---|---|---|---|---|
| Claude Opus 5.5 | $4 | $5 | $8 | $0.20 | $20 |
| Claude Sonnet 5.5 | $2 | $2.50 | $4 | $0.10 | $10 |
| Claude Haiku 5.5 (up to 100K prompt) | $0.10 | $0.125 | $0.20 | $0.01 | $0.50 |
| Claude Haiku 5.5 (over 100K prompt) | $0.50 | $0.625 | $1 | $0.05 | $2.50 |
| Claude Fable 5.1 | $10 | $12.50 | $20 | $0.25 | $50 |
The headline input price matters less than three other columns. Cache reads on Opus 5.5 and Sonnet 5.5 cost 0.05 times base input, so a long conversation that stays cached is cheap to continue. Cache writes cost 1.25 times base for the five-minute lifetime and 2 times base for the one-hour lifetime. And Haiku 5.5 reprices the whole request above 100,000 prompt tokens, a line a Claude Code subagent crosses quickly; I went through that in the post on running Haiku 5.5 as a subagent.
Two modifiers sit on top. US-only inference (inference_geo: "us") multiplies everything by 1.1. Fast mode on Opus 5.5 costs $8 input and $40 output, and on a Pro or Max plan it is billed to usage credits rather than drawn from the allowance, so fast-mode work never counts as “included”.
Why do a Claude Code subscription and an API key bill the same work differently?
Because Claude Code picks a different prompt cache lifetime for each. Per the prompt caching docs, Claude Code requests the one-hour TTL “only on a Claude subscription within your plan’s included usage,” and only for the main conversation. With an API key, a cloud provider, or usage credits, the main conversation gets five minutes unless you choose otherwise. Subagents, compaction and other side requests get five minutes on either, apart from a few helper requests Anthropic controls.
Here is what that does to the cached part of one Opus 5.5 conversation holding 150,000 tokens of context, at list prices. New input and output come on top and are the same either way:
Opus 5.5, 150K-token cached prefix only, list prices
Turn while the cache is warm 150K cache read $0.03
First write, 5-minute TTL 150K x $5/MTok $0.75
First write, 1-hour TTL 150K x $8/MTok $1.20
Back after a 20-minute break
1-hour TTL (subscription default) cache read $0.03
5-minute TTL (API key default) full rewrite $0.75A one-hour write is priced 60% higher than a five-minute one, and in exchange a pause of five to sixty minutes costs almost nothing. With five minutes, writes are cheaper and each pause longer than five minutes rewrites the whole context. Someone who works in tight bursts comes out ahead on five minutes. Someone who reads a diff, gets coffee and comes back comes out far ahead on one hour.
The API is not stuck with five minutes. Set promptCacheTtl to 1h in settings, or CLAUDE_CODE_PROMPT_CACHE_TTL=, and the main conversation gets the hour on an API key too; subagentPromptCacheTtl does the same for side requests. Both need Claude Code 2.1.242 or later. So “the same work” on the API depends on a setting, and the default doesn’t behave like the subscription.
How do you check which cache TTL your Claude Code session uses?
Run one headless prompt and read the cache write split. It is the check from the docs that I also used for idle compaction:
claude -p "hello" --output-format jsonOn Claude Code 2.1.310 with a subscription login, the usage.cache_creation field came back like this:
{
"ephemeral_1h_input_tokens": 36048,
"ephemeral_5m_input_tokens": 0
}All writes on the hour. On an API key with no TTL setting you should see the opposite split. Current Claude Code versions record the same two fields on each assistant message in the local transcripts, which is what the next step depends on.
How do you measure what your Claude Code usage would cost on the API?
Use ccusage on your local transcripts, and scope it to Claude Code. In ccusage 20.0.42 the bare ccusage monthly reports “all detected coding (agent) CLI usage,” Codex, Gemini CLI and other agents included. For Claude Code alone:
npx -y ccusage@20.0.42 claude monthly --mode calculate --breakdown
npx -y ccusage@20.0.42 claude daily --since 20261001 --mode calculate--mode calculate makes ccusage compute every figure from token counts at list price instead of using a cost field from the log, and --breakdown splits it by model. --json gives you the raw numbers.
I wanted to know whether ccusage prices one-hour and five-minute cache writes differently, since that is the whole difference between the two ways of paying. So I gave it a synthetic transcript, no real usage, with four Opus 5.5 entries on four days, and ran ccusage claude daily --mode calculate:
1M one-hour cache write tokens $8.00
1M five-minute cache write tokens $5.00
1M cache read tokens $0.20
1M input + 1M output tokens $24.00It matches the pricing page line for line. When a transcript carries the TTL split, ccusage charges each write at its own rate.
That accuracy is the catch. Run on a subscriber’s transcripts, ccusage answers “what did this exact token stream cost at list price, with one-hour writes.” It does not answer “what would this work cost on an API key with defaults,” because that would be a different token stream, and the error runs both ways. For someone who rarely pauses longer than five minutes, ccusage overstates the API bill: every write is priced at the one-hour rate the API default wouldn’t charge. For someone who takes breaks, it understates it, by roughly one full context rewrite per break that the API default would pay. Set promptCacheTtl to 1h on the API and the two streams converge, which is the only case where ccusage’s total is a fair token estimate for the API.
Two more limits on the number. Claude Code deletes local session data older than cleanupPeriodDays, 30 days by default, so “a month” of transcripts is the last 30 days at most, and only from this machine. And ccusage counts tokens, not server tool charges such as web search at $10 per 1,000 searches.
The dollar figure on a subscription is an exchange rate, not a bill. I made the same point about the statusline cost field: it converts tokens you already paid for with a flat fee into list-price dollars, which is useful only for exactly this comparison.
What does Claude Code’s /usage show on a Pro or Max plan, and on an API key?
On an API key, the Session block of /usage is your running cost estimate at list price. On Pro or Max, the docs say that figure “isn’t relevant for billing purposes”; what matters there is the plan usage bars and the breakdown under them.
That breakdown is the most useful thing Claude Code itself gives a subscriber. It attributes recent usage to skills, subagents, plugins, individual MCP servers and /loop tasks, and suggests changes for anything behind 10% or more of it, with d and w switching between 24 hours and 7 days. The figures come from local history only, “so usage from other devices or claude.ai is not included.” The plan limits themselves are shared with claude.ai, so the account-wide numbers are the rate_limits fields on statusline stdin. In a browser, Claude Usage Deck, an extension I wrote, shows the same claude.ai meters as a badge.
On the API side, the Console usage page is authoritative. The Usage and Cost API gives the same data programmatically with Admin API credentials, and “The Admin API is unavailable for individual accounts.” A solo developer reads the Console page; a team gets per-user Claude Code costs from the Claude Code Analytics API.
What drives a Claude Code bill up?
Context size first: every request re-sends the whole conversation, so a one-line question in a session open all day still pays for all of it, at the cache-read rate if warm and the write rate if not. The costs page names “long sessions that were never cleared” and “Opus left as the default model” as the usual causes of unexpectedly high API spend.
After those, in roughly the order they show up:
- Cache misses. A break longer than the TTL, a model switch, turning on fast mode for the first time in a conversation, or connecting an MCP server mid-session when tools load upfront all force a rewrite. Each model has its own cache.
- Effort and thinking. Thinking tokens bill as output, and thinking can’t be turned off on Opus 5.5, Sonnet 5.5, Haiku 5.5 or the Fable models. Lower
/effortinstead. On Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1 the docs say changing effort keeps the cache by default, outside Bedrock, Google Cloud’s Agent Platform and gateways. - Subagents and workflows. Each sends its own requests and builds its own cache, on five minutes by default even on a subscription. Route simple ones to a cheaper model.
- Agent teams. The docs put them at about 7 times the tokens of a standard session when teammates run in plan mode.
- Compaction.
/compactre-reads what it summarizes, cheap while the cache is warm, expensive on a cold resumed session./clearcosts nothing. - Background work. Typically under $0.04 per session for summaries and status checks, plus scheduled tasks, which send the full context on every run.
When is the API cheaper than a Claude Code Max plan?
When your adjusted ccusage total stays under the price of the cheapest plan whose limits fit your work. Under $20 a month, the API wins outright. Between $20 and $100, Pro is cheaper if its allowance holds; between $100 and $200, Max 5x; above $200, Max 20x, and the further above, the bigger the margin. Add any usage credits and fast-mode spend to the plan side, since those are billed separately.
“Fits your work” is the part the pricing page can’t tell you, because the allowance has no published size. A current subscriber can read it off the /usage bars and the rate_limits percentages: if the weekly figure ends the week under 100% without usage credits, the plan fits. Someone coming from an API key has no way to know short of a trial month.
Headless jobs change the answer. Max plans now come with monthly API credits, $100 or $200, for self-run claude -p and Agent SDK jobs that use a key from the linked Console organization, but not for interactive Claude Code. If part of your ccusage total is that kind of job, the credit pays for it and tilts the comparison toward Max. Jobs several people own, or that need a bill per job, belong on an API key anyway. And if you hit your limits and turn on usage credits, you pay standard API rates and, unless you have chosen a TTL yourself, Claude Code drops the main conversation to five minutes: for that overflow you are an API customer with the defaults.
My read: measure the last 30 days with ccusage claude monthly --mode calculate, check your TTL with the one-line claude -p test, and before comparing with the API, decide whether you would run it with promptCacheTtl set to 1h. If not, discount the ccusage figure if you work in bursts and add to it if you take breaks. Your transcripts carry a timestamp on every message, so counting the gaps over five minutes is a short script, and it tells you which of the two you are.
01 / Discussion
No comment section here — all discussions happen on X.
02 / More articles
Claude auto mode becomes the default in the Claude apps: what the check blocks and what 89% measured
Anthropic's study is honest about its setup: tired testers against one planted command. It reports no false-positive rate and no miss rate on real traffic, and in cloud sessions there is no Manual mode to switch back to.
Claude Code hooks: good at steering, weak as a gate
A hook runs whether the model agrees or not, which makes it good at chores like formatting and at steering an agent toward the route you want. As a gate it is weaker than it looks: it checks only the tools you point it at, a broken check lets the call through unless you opt into blocking, and in some setups a mod answers after it.
Claude Code sandbox on Linux: what srt walls off, and what bypassPermissions opens
The built-in sandbox is a real OS boundary around shell commands, and only around them. How strong it is depends on two things the setup screen never shows: your permission mode, and what existed when the command started. A test on Ubuntu of what srt blocks and leaves open, the Linux bug that still breaks it, and when a container or VM fits better.