Claude API Pricing Explained, and How to Cut It

Claude API pricing is simple to state and easy to get wrong in production. You pay per million tokens, separately for what you send in and what comes back out, at a rate that depends on the model. Everything expensive about a real bill comes from the parts nobody looks at: how much context you resend, and which model handles the steps that did not need it.

Rates change, so check the official pricing page for current numbers before you build a business case. What follows is the structure, which does not change, and the levers that actually move a bill.

How Claude API pricing is structured#

Tokens, not words or requests. A token is roughly three quarters of an English word. Prices are quoted per million tokens.

Input and output are priced separately, and output costs several times more. This is the most important line in this article. A workflow that reads a long document and returns a one-line classification is cheap. A workflow that returns three pages is not, even with identical input.

Each model has its own rate, and the spread between the smallest and largest is large enough that model selection is a budget decision, not a preference.

Caching and batch are separate price tiers, not features you enable and hope for. They have their own rates and they are where the real savings live.

The six changes that cut a bill#

1. Cache the unchanging prefix. If every call sends the same system prompt, style guide or reference document, you are paying full input price for identical tokens thousands of times. Caching charges a reduced rate for reuse. For workflows with a large fixed context this is usually the single biggest saving available, and it changes nothing about your logic.

2. Move anything not urgent to batch. Work that can wait, such as classification runs, nightly summarisation and backfills, goes through the batch endpoint at a lower rate. Most production workloads have more of this than people assume, because everything gets built synchronously out of habit.

3. Choose the model per step. Classification, extraction, routing and formatting rarely need the largest model. Reserve it for the steps that genuinely reason. A pipeline that runs a small model twelve times and a large one twice costs a fraction of one that runs the large model fourteen times, and the output quality is usually indistinguishable where it matters.

4. Stop resending history. Long conversations replayed in full grow quadratically in cost. Summarise older turns and send the summary. See context engineering for how to do this without losing the thread.

5. Constrain the output. Ask for JSON with named fields rather than prose. Set a maximum length. Output is the expensive direction, and "explain your reasoning" is a line item.

6. Log tokens per call. You cannot cut what you cannot see. Record input and output tokens with the workflow name and sort by cost monthly. The finding is almost always the same: a small number of calls with enormous inputs account for most of the bill.

Working out what a workflow will cost#

Do the arithmetic before you build, on the back of an envelope.

1. Estimate input tokens per call: words in your prompt, documents and history, divided by 0.75.
2. Estimate output tokens the same way.
3. Multiply each by the rate for the model you plan to use.
4. Multiply by calls per month.
5. Double it, because the first version always sends more context than planned.

If the result is uncomfortable, the fix is nearly always step 1. Teams reach for a cheaper model when the actual problem is that they are attaching a whole knowledge base to every request. RAG vs fine tuning covers the alternative: retrieve the three relevant paragraphs instead of sending the book.

Subscription or API?#

Different products, different questions.

Claude subscriptions cover a person using Claude through the app or Claude Code. Flat monthly, usage limits, no per-token accounting.

The API covers software you build that calls Claude. Metered, no ceiling, scales with whatever your product does.

Teams sometimes try to run production workloads through a consumer subscription. Beyond being against the terms, it gives you no logging, no rate control and no way to attribute cost to a feature. If you are building something, use the API.

Where the money actually goes in practice#

Four patterns account for most of the surprise bills I have seen.

The whole document, every time. A 40-page policy attached to every call because retrieval felt like extra work. It is not; it is the cheapest engineering you will do.

Chat history with no ceiling. By turn thirty you are paying for twenty-nine turns nobody will reference again.

The largest model as the default. Set once during a prototype and never revisited.

Retries with no backoff. A failing call retried aggressively bills every attempt.

None of these are exotic. All of them are found in an afternoon by looking at token counts per call.

The short version#

Output costs more than input. Cache anything you resend. Batch anything that can wait. Pick the smallest model that passes your evaluation for each step. Log tokens per call and read the log once a month.

If you want the pipeline designed this way from the start, how to use Claude Code covers the workflow, and my Claude Code course covers building production systems on top of it.