What an AI Feature Actually Costs Per Call

/ The unit

What does a single AI API call actually cost?

Multiply your input tokens by the model's input rate, your output tokens by its output rate, and add them. That is the whole formula — every provider on this page bills per million tokens in exactly that shape:

cost = (input_tokens × input_rate + output_tokens × output_rate) / 1,000,000

Worked through on Gemini 3.6 Flash, which lists at $1.50 per million input and $7.50 per million output, for a call of 4,700 input and 390 output tokens:

• input — 4,700 × $1.50 ÷ 1,000,000 = $0.00705
• output — 390 × $7.50 ÷ 1,000,000 = $0.00293
• total — $0.00998, the $0.0100 you will see in the table below

Ten thousand of those calls is $99.80. A million is $9,980. That is the entire economics of an AI feature, and it is worth doing this arithmetic once by hand before trusting any dashboard. If you would rather drag a slider than reach for a calculator, every figure on this page is live in the LLM API cost calculator.

What makes the number hard to predict is not the arithmetic, it is knowing your real token size. Measured request sizes are almost always different from the ones people assume when they estimate. Every figure on this page uses one fixed reference call — 4,700 input tokens and 390 output tokens — which is typical of a planning or tool-calling request: a substantial system prompt plus tool schemas going in, a short structured decision coming back. Scale the results linearly for your own workload, and expect real traffic to run 1.5–2× larger than a thin test sample.

That asymmetry — a fat prompt and a thin response — matters, because it is the opposite of a chat workload. If your calls generate long prose answers instead, the output-rate column below dominates and the ranking changes.

/ The majors

How much do the major providers charge per million tokens?

Here are the current published rates for the standard (non-batch, non-cached) tiers at each of the three largest Western providers, with the per-call cost worked out at the reference size above. Premium and pro tiers are a separate table further down. All rates verified against provider documentation on 29 July 2026.^¹

Three things stand out. First, the budget tier is genuinely cheap: gpt-5-nano at $0.0004 per call is 25× cheaper than Gemini 3.6 Flash and 83× cheaper than Opus 5, for a task that may not need frontier reasoning at all. Second, the "flash" and "mini" labels are not a reliable guide to price. Gemini 3.6 Flash costs $0.0100 per call — more than Claude Haiku 4.5 at $0.0067, and 5× more than gpt-5-mini, despite all three sitting in the same nominal tier.

Third, and least intuitive: a higher generation number does not mean a higher price. gpt-5.6-luna costs $0.0070 per call, comfortably less than the older gpt-5.2 at $0.0137 — while gpt-5.4-mini at $0.0053 costs 2.7× its gpt-5-mini predecessor. Within a single vendor's line-up the suffix is a product-positioning label, not a rung on a price ladder. The only reliable ordering is the one you compute yourself.

Note the moving target in that table: Anthropic's published pricing puts Claude Sonnet 5 on introductory pricing of $2 / $10 through 31 August 2026, after which it becomes $3 / $15. If you budget against the intro rate, your per-call cost rises 50% on 1 September without any change on your side.

/ Premium tiers

What about the premium and pro models?

They exist, and they are priced in a different league. The table above deliberately covers the standard tiers — the models you would realistically put behind a per-request product feature. Each provider also publishes a premium line above them:

Read those per-call figures against the standard table and the gap is stark: $0.2112 ÷ $0.0004 means gpt-5.5-pro costs 528× what gpt-5-nano costs for the same request, and $0.2112 ÷ $0.0100 puts it at 21× Gemini 3.6 Flash. Ten thousand calls: $4 on nano, $100 on Flash, $2,112 on pro. Anthropic's premium pair sits lower, at $0.0665 — double Opus 5 and about twice the top of the standard table.

Nothing here says these models are overpriced; a task that genuinely needs them is a task the cheap tiers will fail at, and one correct answer beats twenty wrong ones. But they are a poor fit for a metered, per-request feature — at $0.21 a call, a thousand requests is $211, which reprices your product rather than your infrastructure. Reserve them for low-volume, high-stakes steps and route the routine work elsewhere.

/ Chinese models

Are Chinese models the cheap option — and where does Kimi K3 land?

Some are dramatically cheaper. Kimi K3 is not one of them. The assumption that a Chinese lab automatically means budget pricing breaks down as soon as you read the published rate cards side by side:

Moonshot prices Kimi K3 at $3.00 per million input tokens on a cache miss, $0.30 on a cache hit, and $15.00 per million output tokens, across a 1,048,576-token context window. At the reference call size that is (4,700 × $3 + 390 × $15) ÷ 1,000,000 = $0.01995 — identical to Claude Sonnet 5 at its post-September standard rate, and double Gemini 3.6 Flash. Against DeepSeek V4 Flash's $0.00077, that is 26× the cost of the same call: 10,000 requests is $200 on K3 and $7.67 on DeepSeek. K3 is positioned as a frontier model and priced like one.

Kimi K3 and Claude Sonnet 5 cost exactly the same per call. DeepSeek V4 Flash costs 26× less than either. "Chinese model" is not a pricing tier. — per-call arithmetic at 4,700 in / 390 out

At the other end, DeepSeek publishes deepseek-v4-flash at $0.14 input / $0.28 output, which works out to $0.0008 per call — and its cache-hit input rate of $0.0028 per million is the most aggressive discount on this page, 50× below its own cache-miss rate. Z.ai's GLM line spans nearly the same range on its own, from GLM-4.7-FlashX at $0.07 / $0.40 up to GLM-5.2 at $1.40 / $4.40, with GLM-4.7-Flash listed at no cost at all.

The practical lesson is that provider nationality tells you nothing about price. Read the rate card, compute your own per-call number, and rank by that.

/ Output weight

Why does output pricing dominate the bill?

Because every provider charges several times more for tokens the model writes than for tokens you send. The ratio is remarkably consistent:

• 6–8× — OpenAI: 8× across gpt-5, gpt-5.1 and gpt-5.2, and 6× on the newer gpt-5.4 and gpt-5.6 models.
• 5× — Anthropic across Haiku, Sonnet and Opus, Google's Gemini 3.6 Flash, and Moonshot's Kimi K3.
• 2× — DeepSeek V4, the flattest ratio of the group.
• 3.1× — Z.ai's GLM-5.2.

Run the reference call through that lens. Output is 390 of 5,090 total tokens — 7.7% of the volume. But on Gemini 3.6 Flash it is $0.00293 of a $0.00998 bill, or 29% of the money. Those 390 tokens cost nearly four times what their share of the token count suggests. Double the response to 780 tokens and the call goes to $0.01291, up 29%; double the prompt to 9,400 tokens instead and it goes to $0.01703, up 71% — but you had to add 4,700 tokens to do it, twelve times as many as the output change. Trimming a verbose system prompt feels productive; capping max_output_tokens and asking for terse structured output usually saves more.

Reasoning models complicate this further, because reasoning tokens are billed as output. A model that always thinks before answering can spend more on the invisible trace than on the visible reply — the same behaviour that makes reasoning models good at planning tasks is what makes their bills volatile. If you route a planning step to a reasoning model, measure the output-token distribution, not just the mean.

/ Caching

How much does prompt caching change the math?

Substantially, if your prompt has a large stable prefix. Cached input is billed at a fraction of the normal input rate, so a long system prompt and tool schema block — exactly the shape of an agent request — can be reused across calls almost for free.

Anthropic also charges a write premium — 1.25× base input for a five-minute cache, 2× for a one-hour cache — which means caching pays for itself after a single read on the short TTL, or two reads on the long one. Work it through on Sonnet 5 at introductory pricing ($2 in / $10 out, cache hits at $0.20), assuming 4,000 of the 4,700 input tokens are a cacheable prefix:

• cached input — 4,000 × $0.20 ÷ 1,000,000 = $0.0008
• fresh input — 700 × $2.00 ÷ 1,000,000 = $0.0014
• output — 390 × $10.00 ÷ 1,000,000 = $0.0039
• total — $0.0061, against $0.0133 uncached

That is a 54% cut with no quality trade-off — better than dropping from Sonnet 5 to Haiku 4.5 ($0.0067), and you keep the stronger model.

Batch APIs are the other lever: Anthropic and OpenAI both discount asynchronous batch processing by 50%, and Google does the same. If the work is not interactive — nightly enrichment, bulk classification, backfills — half your bill is available for the cost of queueing the job. That is a natural fit for any system that already runs work through a background job queue.

/ Reselling

What goes wrong when you resell AI calls as flat-price credits?

You lose money on exactly the requests that cost you the most. A flat "one request = N credits" price is a fixed charge over a variable cost, so it overcharges small calls and undercharges large ones — and large calls are precisely what heavy users make.

Work the numbers on a hypothetical plan: a $249/year tier with a 5,000-credit monthly pool, charging 7 credits per request. That pool buys 8,571 requests a year. At $0.010 per call the provider bill is $86; at a realistic build size of $0.015 it is $129. Comfortable. Now scale the same structure up to a $649/year tier with a 30,000-credit pool: 51,429 requests a year, costing $514 to $771. The margin has narrowed from 65% to somewhere between 21% and a loss, without anything changing except the size of the pool.

The leak is not the pool size, it is that the charge does not move with the request. A user whose prompts are three times larger than average pays exactly the same as one whose prompts are tiny.

/ Token-linked credits

How do you make credits track actual cost?

Compute the charge from the token counts the provider returns, using a weight that mirrors that model's own output-to-input price ratio. Two constants per tier are enough:

PHP — token-linked credit charge

// Weight output tokens by the model's own output/input price ratio.
// Gemini 3.6 Flash: $1.50 in / $7.50 out  ->  weight 5.
$weighted = $usage['input_tokens'] + 5 * $usage['output_tokens'];

// 1 credit = 1,000 weighted tokens, minimum 1 credit per call.
$credits = max( 1, (int) ceil( $weighted / 1000 ) );

// Reference call: 4700 + 5 * 390 = 6650 weighted -> 7 credits.

The weight is the whole trick. When output_weight equals the provider's output/input price ratio, one credit maps to a fixed dollar amount of provider cost for any input/output mix. On Gemini 3.6 Flash at weight 5 and 1,000 weighted tokens per credit, one credit is always about $0.0015 of API spend — whether the call was a fat prompt with a one-word answer or a short prompt with a long essay.

Two details make this safe in production. Charge after the provider call, not before: a failed request then costs the user nothing and there is no refund path to build. And gate on balance before the call rather than trying to predict the charge — check that the remaining pool is above zero, let the request through, then settle the real cost. The maximum you can overshoot is bounded by your own input and output caps, so a hard max_output_tokens is what keeps the tail finite.

A model with a different ratio just needs a different weight. Swapping to a provider whose output costs 8× input means weight 8; swapping to DeepSeek means weight 2. The cost calculator works the credit charge out for any model and token size, so you can see what one credit is actually backing before you publish a price. Because credits are charged from real usage, changing models changes what a credit costs you, not whether the pricing structure still holds.

/ In production

What should you actually measure?

Per-call token counts, from day one. Almost every cost surprise traces back to a team that estimated token size instead of logging it. Concretely:

1. Log input_tokens and output_tokens on every call, alongside the model name. Without the model name, a later price change makes the history unreadable.
2. Watch the distribution, not the mean. The 95th-percentile request is what determines your worst case; a mean hides the reasoning traces that ran ten times longer than usual.
3. Bound the tail explicitly. Cap input length and set max_output_tokens. Those two limits are the only hard ceiling on what one call can cost you.
4. Model the 100%-utilisation case. If every customer consumed every credit they paid for, would each tier still be profitable? Typical usage is far below that, but the ceiling is what a single heavy account can reach.
5. Re-check rate cards quarterly. Introductory pricing expires, new tiers land below old ones, and a model you chose on price six months ago may no longer be the cheap option.

None of this requires a sophisticated billing system. It requires that the number you charge and the number you are charged come from the same measurement. Once those are linked, model selection becomes a quality decision with a known cost consequence — which is the position you want to be in before you wire an AI step into an agent architecture that runs on live traffic.