What a Real Feature Costs: LLM API Pricing in Practice

The spreadsheet said eleven dollars a month. The invoice said two hundred and forty. Nothing was broken, no key had leaked, and the traffic was roughly what had been forecast. The estimate was simply built from the wrong number: a price per million tokens, multiplied by a guess at how many tokens a request uses, with no allowance for the four things that actually fill a context window.

This is the common failure, and it is not a maths error. It is a modelling error. LLM API pricing is published per token, but you do not buy tokens, you buy completed tasks, and the ratio between the two is set by your architecture rather than by the vendor. Below is the price table, dated, and then the part nobody publishes: one feature worked through from prompt to answer, with the retries counted.

What do the providers charge right now?

All figures per million tokens, read from the vendor's own page on 29 July 2026, standard tier, no batch discount, and they move: the day after this table was built OpenAI cut its cheapest tier by 80 percent, which we priced out in what the July 2026 API price cut changes for a small shop.

Sources, each an exact page: Anthropic's pricing documentation, Google's Gemini API pricing, DeepSeek's pricing docs, Fireworks serverless pricing, the Z.ai overview and the OpenRouter listing for GPT-5.6 Sol, used because OpenAI's own pricing page returned an error on both attempts that day.

Why does the same model appear twice at different prices?

Because open weights models are sold by whoever runs the hardware, and hosts do not agree.

Look at the two DeepSeek V4 Pro rows. DeepSeek's own API lists $0.435 per million input tokens on a cache miss and $0.87 output. Fireworks lists the same model at $1.74 and $3.48. That is four times the price for identical weights, and both numbers are correct on the same day. Cached input diverges even further: $0.003625 first party against $0.145 on Fireworks, a factor of forty.

Nobody is overcharging. The hosts differ on latency guarantees, rate limits, region, data handling and how much idle capacity they hold. But a comparison that lists one model and one price is answering a question you did not ask. The right column heading is not "model", it is "model on host", and the same caution applies when weighing Claude against ChatGPT on published prices, since one of them charges a second rate once a request runs long. The arbitrage between hosts is often larger than the gap between two different models.

This is one of the practical arguments for weights you can move. If a host doubles its price you can leave, which is not true of a closed model. We went through the trade offs in more depth when weighing what open weight releases give up against frontier models.

What does one real feature actually consume?

Take a feature that plenty of teams have shipped: an assistant that reads an incoming support email, looks up the customer's last three orders through a tool call, and drafts a reply for a human to approve.

Anthropic's own documentation offers a nearby estimate: processing 10,000 support tickets at an average of about 3,700 tokens per conversation on Claude Haiku 4.5 comes to roughly $37.00. That number is honest, and it is a floor rather than a forecast, because a working feature carries several things the average does not include.

Here is the same feature counted category by category, using Haiku 4.5 at $1 input and $5 output.

Three things jump out of that table, and none of them appear in a per token price list.

The first is the second turn. A tool call is not one request, it is at least two: the model asks for the tool, you run it, and you send the whole conversation back with the result appended. That resend is the largest single input line in the table, and it exists purely because the feature uses a tool at all. The token accounting for that pattern is the same whether you hand roll the plumbing or standardise it, which is one reason we prefer a protocol layer and documented it in a walkthrough of standing up a tool server.

The second is that output is 400 tokens against roughly 7,000 input tokens, and still costs $20 against an input bill that caching drives under $20. Output is 5% of the volume and the largest single line. That ratio holds across almost every vendor, because output is priced at four to six times input everywhere.

The third is that caching changes the answer completely. Uncached, this feature runs about $90 per 10,000 tickets. Cached, with the system prompt and tool definitions held warm, it lands nearer $38, which is where Anthropic's published estimate sits. The vendor number is not wrong. It assumes you built the thing properly.

Where do the retries go?

Into the bill, at full price, invisibly.

Every production feature has a failure rate. The model returns malformed JSON, calls a tool with a bad argument, writes a reply that trips a guardrail, or the request times out. Whatever your handler does next, it sends the conversation again, and every token in that retried request is billed exactly as if it were the first attempt. There is no discount for a repeat.

Assume a modest 8% of tickets need one retry. That is not a pessimistic figure for a feature involving tool calls and structured output. Applied to the cached scenario above, the bill moves from about $38 to about $41 per 10,000. Assume 8% need one retry and 2% need two, which is closer to what a first month in production looks like before the prompt settles, and you are near $42.

Ten percent is small. The reason it matters is that nobody puts it in the spreadsheet at all, so the estimate is systematically low rather than noisy. Add a retry rate to your model before you add a safety margin, because a safety margin applied to a structurally incomplete number is still incomplete.

The line items a token price leaves out

A per token rate covers inference. A production feature buys several other things from the same vendor, each metered separately, and none of them appear on the comparison table at the top of this page.

Server side tools are the clearest example. Anthropic's page prices web search at $10 per 1,000 searches on top of the tokens the results consume. Web fetch adds no charge beyond the tokens, but those tokens are not small: the same page estimates a 10 kB web page at about 2,500 tokens, a 100 kB documentation page at about 25,000, and a 500 kB research paper at about 125,000. A feature that fetches three documentation pages per request has added 75,000 input tokens before the model writes a word.

Code execution is metered in time rather than tokens: free when paired with web search or web fetch, otherwise 1,550 free container hours per organisation per month and $0.05 per hour per container after that, with a five minute minimum per execution. Managed agent sessions add $0.08 per session hour on top of all token charges, metered only while a session is actually running rather than idle.

None of these are large individually. Together they are the difference between a feature that costs what you predicted and one that costs half again as much, and they are trivially easy to leave out because they are not denominated in tokens.

Batch and speed pull in opposite directions

Two modifiers sit either side of the standard rate, and choosing between them is mostly a question about latency tolerance.

The Batch API takes 50% off both input and output for asynchronous work, and the same 50% appears on Fireworks batch inference and on Google's batch tier. For anything that does not need an answer within seconds, nightly enrichment, bulk classification, backfills, that is the single largest discount available anywhere in this market, and it stacks with prompt caching.

Fast mode runs the other way. Anthropic prices it at $10 input and $50 output on Claude Opus 5, exactly double the standard rate, in exchange for faster output. It is first party only, it is not available with the Batch API, and its pricing applies across the full context window. A team that reaches for it to fix a perceived latency problem doubles its inference bill in one configuration change.

There is a third modifier that is easy to trip over. Requesting US only inference through the data residency parameter applies a 1.1x multiplier to every token category on Claude 4.6 and later, including cache reads. That is a 10% surcharge that a compliance requirement can impose on your entire bill without anyone in engineering noticing.

One more structural detail worth knowing if you run open weights on a shared host: Fireworks prices models it does not list individually by parameter count, at $0.10 per million under 4B, $0.20 between 4B and 16B, and $0.90 above 16B, with mixture of experts models between $0.50 and $1.20. That means the cost of a fine tuned model you deploy yourself is predictable from its size before you deploy it.

Is the cheapest model per token the cheapest per task?

Often not, and there are three separate reasons, each of which can dominate.

The first is attempts. A cheaper model that needs two attempts to produce valid output is more expensive than a model at twice the price that succeeds first time, and it is also slower and harder to debug. The break even is easy to calculate once you measure your own success rate, and almost nobody measures it.

The second is verbosity. Output is the expensive column, and models differ in how much of it they produce for the same instruction. A model that answers a classification task with a paragraph of reasoning before the label costs several times what a model that returns the label costs, at identical per token rates. This is measurable on your own traffic in an afternoon.

The third is the price cliff. Google prices Gemini 3.1 Pro Preview at $2 and $12 up to 200k tokens, then $4 and $18 above it. GPT-5.6 Sol steps up once input passes roughly 272k. Anthropic's page states that Claude 4.6 and later bill the full 1M window at standard rates, so a 900k token request costs the same per token as a 9k one. If your feature accumulates context across a session, the flat rate can beat a headline rate that is 60% lower.

How should you build the estimate?

Five steps, in this order, and the first one is the one people skip.

Measure a real request rather than estimating it. Send one genuine example through the API and read the usage block. You now have true counts for input, cached input and output on the exact prompt you intend to ship, which beats any assumption about words per token.

Then multiply by turns, not by requests. A tool using feature costs at least two model calls per user action, and an agent loop costs as many as it takes. Count the loop, not the intent.

Then apply the cache split. Decide which parts of your prompt are stable enough to cache and price those at the cache read rate, which is 10% of input on Anthropic and under 1% on DeepSeek's first party API. Price the rest at full input.

Then add your retry rate. If you do not have one yet, use 10% and revise it after two weeks of real traffic.

Then check the cliff. Find your 95th percentile context length and confirm which side of each vendor's threshold it falls on. If you are near a boundary, price both sides.

That produces a number you can defend, and it is usually two to four times the naive estimate. Being told the real figure early is not bad news, it is the only version of the news that survives contact with the invoice. It is also the discipline behind how we present what a build consumes in credits on MaShop, and why the model catalogue and the router sit behind the tools we expose over MCP rather than behind a flat monthly promise.

What should you re check, and when?

Prices in this market move on a monthly cadence, but not uniformly. The two things worth a calendar reminder are introductory rates and host pricing.

Claude Sonnet 5's introductory $2 and $10 runs through 31 August 2026, after which the page says it becomes $3 and $15. That is a 50% increase on a row that a lot of features are currently sized against. Host pricing for open weights models changes more quietly and with no announcement, so if you run a model through a third party host, re read that page quarterly and compare it against the first party rate.

Everything else is stable enough to leave alone. The structure of the bill, input against output, cached against uncached, turns against requests, does not change when prices do. What can change it is a vendor swapping the model underneath you, which is what Microsoft moving Copilot onto its own MAI models amounts to. Build the estimate once with the right shape and updating it later is arithmetic rather than archaeology. If your workload is coding rather than a discrete feature, the same shape applies with different weights, which we worked through separately in a comparison of coding models on price and context behaviour.