Subscription vs API cost calculator

The question no vendor will answer for you

Anthropic sells both flat-rate subscriptions and metered API access, and has no reason to tell you which one is cheaper for your specific usage — the honest answer is "it depends," and a calculator that might point you toward the cheaper option isn't something a seller builds voluntarily. This tool exists to answer it with your numbers: how many messages you send per day, your typical input and output length, how much context gets re-sent on each turn, and how many days a month you're actually working.

What it computes

Enter your usage shape and the calculator prices the same workload two ways — metered API, per model, and against the subscription cost you tell it you're paying. It then names the break-even point in plain language: below a certain number of messages a day the API is cheaper, above it the subscription is. It also lets you toggle the two levers that move the API side of that comparison the most: prompt caching and batch processing. Every rate it uses renders from this site's dated facts module, including the per-model cache-read prices that stopped being one number across the lineup with Fable 5.1.

Why the price box starts empty

The subscription field opens blank on purpose. Anthropic publishes list prices — they're on Claude plans explained, dated and sourced — but what you actually pay depends on your currency, your tax treatment and whether you bill monthly or annually, and plan terms change without a changelog. A number pre-filled here would be right for some readers and quietly wrong for the rest. So the calculator shows the metered API cost on its own until you give it a price: type what your plan costs you, or tap one of the US list prices under the field to start from it. Either way, the comparison runs on a figure you chose.

The plans page also covers what each plan includes: relative usage, Claude Code access, which plans reach the Fable models, and where a plan's usage starts being billed at API rates — the detail that decides whether a given plan can carry your usage at all.

A worked example you can open

Take a support-bot integration: a few hundred messages on each working day, each carrying a couple of thousand input tokens — most of it a repeated system prompt and retrieved context — and producing a few hundred output tokens. Open that example in the calculator with caching switched off and note the metered total. Then switch caching on.

The input side drops sharply, because the repeated prefix is now billed as cache reads — a small fraction of the standard input rate — while the output side, which can never be cached, stays exactly where it was. That asymmetry is the whole lesson of the example: caching attacks input, so the more of your bill is output, the less caching can do for you. Change the output length and watch the gap between the two totals move.

The example is deliberately simplified. It models one cache write per working day rather than the exact pattern your traffic produces, and it doesn't choose between the short and long cache TTLs. The prompt-caching savings calculator does both, using your actual request pattern rather than an assumed hit rate.

The levers, and where each pays off

Prompt caching pays off once a stable prefix is re-read within its TTL; below the break-even request count, the write premium is never earned back. The exact counts for both TTLs are on the prompt-caching reference. Batching trades latency for a large per-token discount — a strong trade for anything that doesn't need a synchronous answer and a bad one for anything that does; the Batch API reference has the discount and the completion window. Both levers are folded into this calculator's API-side total, so the comparison you get already reflects whichever combination is cheapest for the usage you entered, not the naive metered price alone.

When the answer is "both"

A flat plan and the API are not mutually exclusive, and the plans themselves now meet the API at a defined point: once a paid plan's included usage runs out, usage credits bill at standard API rates. If your traffic is bursty, the realistic comparison may be a plan for everyday work plus API-rate overflow — run your quiet weeks and your busy weeks through the calculator separately rather than averaging them.

If you're also on the OpenAI side

Comparing the same workload against OpenAI's ecosystem is a different sourcing problem, since the two vendors publish neither the same figures nor the same mechanics. CodexHow answers the same questions for the Codex side, so one described workload can be priced on both.