Cheap Claude API: How Per-Million-Token Prices Really Compare

Key takeaways

• A per-million-token rate is a starting point, not a bill. Serious Claude endpoints price input, output, cache write and cache read as separate line items, and the mix between them decides what you pay — two endpoints quoting the same headline rate can differ several times over on the same workload.
• For agentic tools such as Claude Code the mix is dominated by cache reads. The tool re-sends a growing conversation on every turn, so whatever an endpoint does with prompt caching matters more than its rate card.
• The only comparison that holds up is running the same workload through both endpoints and reading the usage record. Rate cards are marketing; usage records are evidence.
• When you evaluate a cheaper endpoint, ask five questions: does it report cache read and cache write separately, does it honour cache hints, are failed requests billed, is the multiplier published per group, and can you see your own line items after a call.

Why the headline rate does not predict your bill

Every Claude endpoint on the market advertises a number per million tokens. Almost none of them serve your traffic at that single number.

The reason is that a Claude request is not one quantity. It is four:

Line item	What it is	Why it varies between endpoints
Input	Text you send that is not cached	Depends on how much of your prefix the endpoint can cache
Output	Text the model generates	The most expensive line item almost everywhere
Cache write	Storing a prefix so later turns can reuse it	Some endpoints do not support it at all
Cache read	Reusing that stored prefix	The single biggest lever for agentic workloads

An endpoint can quote an attractive input rate and still be expensive, because it does not cache, so every turn re-sends the whole conversation as fresh input. Another can quote a higher input rate and be cheaper, because most of your tokens arrive as cache reads.

The rate card tells you the price of a token. It does not tell you which kind of token you will mostly be buying.

Cache is where "cheap" is won or lost

This is the part worth understanding before you migrate anything.

A chat client sends one question and receives one answer: a handful of tokens in, a handful out. Claude Code is an agent. It reads files, calls tools, returns results, and does it again. One task becomes dozens of requests, and each request carries the conversation so far. If that prefix were billed as fresh input every single turn, agentic coding would be unaffordable at any published rate.

Prompt caching is what prevents that. The stable prefix is stored, and later turns pay a cache read rather than a full fresh input. Claude Code exposes exactly this: after a session produces its first response it reports prompt-cache statistics, and the usage view breaks the same session down by model into input, output, cache read and cache write.

Now put that against an endpoint that does not forward cache hints. The client still thinks it is caching. The endpoint silently converts every cache read into fresh input. The terminal looks completely healthy and the bill changes shape.

Two consequences follow:

1. Cache is kept per model. Change model mid-session and the next turn has to take in the whole conversation again from scratch. Decide the model from the shape of the work before you start, not halfway through.
2. Cache behaviour is not observable from your side. Your own logs will not tell you whether an endpoint honoured your cache hints. You have to read the endpoint's usage record, or test it.

The four questions that separate a cheap endpoint from a cheap-looking one

Question	Why it decides your bill
Does it report cache read and cache write separately?	If they are merged into "input", you cannot audit the largest line item
Does it forward cache hints to the model provider?	If not, every turn is billed as fresh input
Are failed or retried requests billed?	Long agent sessions retry; billing retries quietly inflates cost
Is the multiplier published per group?	"Official price × multiplier" is only meaningful if the multiplier is visible

An endpoint that answers all four in public, and shows you the line items afterwards, is doing something a rate card cannot do.

How to check what you are actually paying

Do not take any of the above on trust — from us or from anyone else. Run these three checks against whichever endpoint you are considering.

How to check #1 — read your own line items. Make one call through an agentic tool, then open the usage record for that key. You should see input, output, cache read and cache write as separate numbers, plus the amount deducted for that request. If cache columns are missing or always zero, the endpoint is not caching, and its effective price is not its advertised price.

How to check #2 — ask the model who it is. Send a one-line prompt asking the model to identify itself, and compare the reply with the model you selected. Endpoints that quietly route you to a different model will show it here, and model identity is the one thing a rate card cannot fake.

How to check #3 — reconcile the total. Add up the deductions in your usage record over a day and compare the sum with the change in your balance over the same period. The two should agree. A gap means something is being billed that is not in your line items.

None of these require special access. All three are things you can do in a terminal in a few minutes, and they are worth more than any comparison table — including ours.

Comparing endpoints without being misled

If you want a comparison that survives contact with reality, do it in this order:

1. Match the workload, not the rate. Run the same agent session — the same repository, the same prompt, the same model — through both endpoints.
2. Compare cache hit share first. Look at what fraction of input arrived as cache reads. A large gap here explains most cost differences before you look at any rate.
3. Compare the deducted amount per request, not the rate per million tokens.
4. Check what happens on failure. Force a failing request and see whether it appears in the bill.
5. Only then look at the rate card, as an explanation of what you observed rather than a prediction.

Two endpoints with identical rate cards can land in different places once agentic caching is involved. Two endpoints with different rate cards can swap places entirely.

Why our pricing is structured the way it is

We bill on official list price × a group multiplier, and we publish the multiplier for each group on a public page, alongside the per-model list prices and the input, output and cache components separately. Two design choices follow from that:

• Balance is an account asset. A price change does not consume balance you already hold.
• Failed requests are not billed. An agent session that retries does not pay twice for the same work.

Both are checkable rather than asserted: the multiplier page is public, the usage record shows every deduction, and the status page reports each group's current operating state without decoration. Multiplier changes are announced in the same public channel, and the reductions we have made as input costs fell each state their reason.

Where to look: current per-model prices and group multipliers are on the model plaza, and live group state is on the status page. Both are public and need no account.

FAQ

What is the cheapest way to use Claude?

Cheapest is not a rate, it is a shape. Keep one model for a whole session so the cache stays warm; let an agent reuse a stable prefix instead of re-sending files; pick a smaller model for mechanical edits and reserve the larger one for work that needs it; and choose an endpoint that reports cache reads separately, so you can see whether caching is actually happening. A rate that looks higher can be the cheaper bill once cache reads are counted.

How much does the Claude API cost?

Model providers publish list prices per million tokens, split into input, output and cache components. What you pay on any aggregator is that list price adjusted by a multiplier, which is why the multiplier is the number worth reading. The exact figures change as providers reprice, so check the current per-model list on a live pricing page rather than any article — including this one.

How can I buy Claude for a low price?

Buy the token type you will actually consume. If your workload is agentic, most of your tokens will be cache reads, so a provider that caches is worth more to you than one that quotes a lower input rate. Then verify: make one call, read the usage record, and reconcile the deductions against your balance change. If the numbers agree, the price you were quoted is the price you are paying.

Next step

Start with the public pages: per-model prices and group multipliers and live group status. The English docs cover endpoint and key setup, and the refund page states the process in writing. If your question is really about the operator rather than the price, Is a Cheap Claude API Reseller Safe? 5 Things to Check covers that level, and What Is an AI API Aggregator? 7 Things to Check Before You Pay starts one level up.

If the structure above matches how you want to be billed, create an account, make one call, and check it against your own usage record — the verification steps in this article work exactly the same on us.