LLM API Pricing Explained: How AI Model Token Costs Work

You pick a model because its price card says "$0.15 per 1M tokens," you multiply by your request count, and your projected bill looks reassuringly small. Then the first real invoice lands and it does not match your mental math at all. The gap is rarely a billing error. It is usually because llm api pricing is not a single per-token number — it is a two-rate structure (input and output billed separately, at different prices) layered with caching, batch, retry, and reasoning-token variables that a headline unit price never shows you.

This guide explains how token-based billing actually works, why input and output tokens are priced differently, and how to calculate the real cost of a single API request — then scale that estimate to a daily and monthly budget. It deliberately does not rank which model is cheapest, because the cheapest unit price is rarely the cheapest way to finish a task.

Key Takeaways

• LLM APIs bill by token, and input and output tokens are metered and priced separately — output is almost always more expensive.
• The cost of one request equals (Input Tokens × Input Price) + (Output Tokens × Output Price), normalized to the per-1M-token unit on the price page.
• Prompt caching, batch discounts, retries, and hidden reasoning tokens can shift your real bill far from what a simple "requests × unit price" estimate predicts.
• A model's official list price is not necessarily the price your API platform charges; compare the real cost to finish a task, not isolated unit prices.

What LLM API Pricing Actually Means

sequenceDiagram
    participant A as llm api pricing
    participant B as The most common mistake is treating the…
    participant C as You do not need a dedicated cost calcul…
    A->>B: Request llm api pricing
    B->>C: Execute What LLM API Pricing Actually Means
    C-->>B: Return llm api pricing status
    B-->>A: Confirm llm api pricing result

When a provider says a model costs "$1 per million input tokens and $5 per million output tokens," that single line is the entire pricing contract for that model. Everything you are billed for flows through that input/output split. Understanding llm api pricing therefore means understanding four things: what a token is, how input and output are metered separately, how the per-1M-token unit converts to real dollars per request, and which hidden variables (caching, batch, retries, reasoning) bend the final number.

The "cheap unit price" trap developers keep hitting

The most common mistake is treating the input price — or a single blended rate — as "the cost." A developer who sees a low input rate and estimates a budget by multiplying it against total tokens will understate the bill whenever the workload is output-heavy, because output tokens carry a higher rate. The same trap appears when a long, repetitive system prompt is sent with every request at full input price, even when prompt caching could have billed most of those repeated tokens at a fraction of the rate. Unit-price intuition fails precisely because it ignores the asymmetric input/output structure and the repeated-prefix cost.

What this guide covers: a repeatable per-request → daily → monthly method

You do not need a dedicated cost calculator to get a defensible estimate. You need three inputs — your average input token count, your average output token count, and your request volume — plus the model's two published rates. From those, you can compute a single-request cost, multiply by requests per day, and project a monthly figure. Everything downstream (caching eligibility, batch discounts, retry behavior) is a correction you apply once you understand the baseline formula.

Key takeaways preview

Keep these three facts in mind as you read: token billing splits input and output at different rates; one request's cost is a two-term calculation, not a per-token guess; and multiple pricing features (cached input, batch, retries, reasoning tokens) are what make a real invoice diverge from a naive estimate.

Why LLM APIs Bill by Tokens — and Input and Output Cost Differently

LLM APIs charge per token because a token is the atomic unit of computation for a language model. You pay for every token the model reads and every token it writes, and the two sides of that transaction are priced differently for a concrete engineering reason.

What a token is and how to estimate it

A token is a chunk of text the model's tokenizer splits input into — a whole word, part of a word, a single character, or punctuation. A token count is not the same as a word count [1]. As a rule of thumb for English text, one token is roughly 4 characters or about 0.75 words, so 1,000 tokens is roughly 750 words [1]. The exact count depends on the model's tokenizer, and the heuristic holds far better for ordinary prose than for dense code, JSON, or non-Latin scripts, which tokenize less efficiently [1].

Input tokens vs output tokens: what each side of your request actually measures

Input tokens are everything you send the model: the system prompt, the user query, any retrieved context or documents, and the conversation history that precedes the current turn. Output tokens are everything the model generates in response — the visible answer and, on reasoning models, the hidden thinking that precedes it. Both are metered, but they are counted and billed as separate line items on your usage record.

Why output tokens cost 2–8× more than input

The gap is not arbitrary markup; it follows from how inference runs on a GPU. Input tokens are processed in the prefill phase, where the model can process many tokens in a single, highly parallel forward pass [2]. Output tokens are produced in the decode phase, which is autoregressive: to generate token N+1 the model needs token N to already exist, so each output token requires its own sequential forward pass [2]. Because decoding is far more compute-intensive per token than parallel prefill, output rates are consistently higher — commonly 2–6× the input rate across major model APIs, and sometimes more [2]. In short, a "chatty" model that writes long answers will cost more than its input rate alone suggests.

How to read "$ per 1M tokens" on a pricing page

A line like "$1 / 1M input, $5 / 1M output" means $1 for every one million input tokens and $5 for every one million output tokens. To convert to per-request dollars, divide your token counts by one million and multiply by the corresponding rate. A request with 2,000 input tokens and 800 output tokens on this model costs (2000 ÷ 1,000,000 × $1) + (800 ÷ 1,000,000 × $5) = $0.002 + $0.004 = $0.006. The per-1M unit is simply a readable denominator; the math is identical to a per-token price scaled up.

How to Calculate the Real Cost of a Single API Request

Once you accept that input and output are two separate priced streams, the per-request cost becomes a deterministic two-term calculation.

The core formula

Request Cost = (Input Tokens × Input Token Price) + (Output Tokens × Output Token Price)

Normalize both prices to the same denominator the provider publishes — per 1M tokens — so a request with I input tokens and O output tokens costs (I ÷ 1,000,000 × inputpriceper1M) + (O ÷ 1,000,000 × outputpriceper1M).

Worked example with a real model

Let us use Anthropic's Claude Haiku 4.5 as an illustration. On the Claude Platform, Haiku 4.5 starts at $1 per million input tokens and $5 per million output tokens, with up to 90% cost savings from prompt caching and 50% savings from batch processing [3]. (Pricing checked: 2026-09-08; always re-verify against the official pricing page before budgeting, because rates change.)

Consider a single request with 2,000 input tokens and 800 output tokens:

• Input: 2000 ÷ 1,000,000 × $1 = $0.002
• Output: 800 ÷ 1,000,000 × $5 = $0.004
• Total per request = $0.006

Now scale that single request to real volume. If your service runs 100,000 such requests per day for 30 days, the baseline (no caching, no batch, no retries) works out to 100,000 × $0.006 × 30 = $18,000 per month. That is the number a naive estimate produces — and it is the number caching, batch pricing, and retry discipline can move meaningfully.

The four variables that drive per-request cost

Four factors determine a request's cost: the number of requests, the input length, the output length, and the unit price. Double any one of them and per-request or total cost scales linearly. This is why output length control matters so much: because the output rate is higher, an unconstrained max_tokens that lets a model ramble inflates cost faster than an equivalent expansion of input.

Why a long prompt and a long output scale cost linearly

There is no per-request fixed fee in most token-based models — the cost is strictly proportional to the tokens consumed. A prompt that grows from 2,000 to 20,000 input tokens multiplies the input line by ten; an answer that grows from 500 to 5,000 output tokens multiplies the output line by ten. Because there is no step function, the cheapest lever is often simply sending fewer tokens per request.

The Four Variables That Distort Your "Unit Price" Intuition

The formula above is the baseline. Real invoices diverge from it through four pricing features that a headline unit price hides.

Cached input / prompt caching: stable prefixes billed at a discount

Prompt caching lets a provider reuse the computation for a long, stable prefix — your system prompt, a large reference document, tool definitions, or the head of a conversation — across repeated requests instead of reprocessing it every time. Cached tokens are billed at a steep discount: Anthropic, for example, prices cached input reads at roughly a 90% discount off the standard input rate on cache hits [4]. OpenAI's automatic caching locks onto the longest stable prefix it can find from the start of the request, so you benefit without adding markers [5]. The practical implication: a workload that resends a 5,000-token system prompt with every call can shift most of that repeated prefix onto the cached-input rate, changing the input-cost picture entirely.

Batch pricing: async jobs at roughly 50% off

Batch APIs let you submit asynchronous jobs that the provider processes on its own schedule — typically within a 24-hour window — in exchange for roughly a 50% discount off standard token rates on both input and output [6]. If your workload tolerates delayed results (bulk summarization, offline classification, nightly data enrichment), routing it through a batch endpoint can halve the token spend without changing the model [6].

Retries and repeated requests: full-price billing that can triple effective cost

Every failed or retried request is billed at full rate, so the effective cost per successful request can climb well above the per-request baseline. Retrying a processed request duplicates token spend [7], and blindly retrying a request that will fail again — a 400 error, a content-policy refusal — bills the failure a second time without producing a success. Retrying only idempotent, retry-safe statuses (timeouts and 5xx) and applying backoff keeps avoidable spend down.

Reasoning / thinking tokens: the hidden output-rate cost

Reasoning models generate a hidden "thinking" trace before producing a visible answer, and those thinking tokens are billed at the output rate — exactly like the visible reply, even though you often do not see them [8]. On complex requests, the hidden reasoning can push total cost well beyond a plain query; it is frequently the largest line on the invoice for reasoning-heavy workloads [8]. If you use a reasoning model, budget for thinking tokens as part of your output spend, not as a surprise on top of it.

Why the Lowest Token Price Is Not the Lowest Real Cost

Comparing models by their lowest input price is a shortcut that frequently points in the wrong direction. Two pricing realities explain why.

Model provider list price vs your API platform's actual price

A model's official list price — the number on OpenAI's, Anthropic's, or Google's own pricing page — is not necessarily the price your API platform charges you. Providers expose their models through their own APIs; aggregator and access platforms connect you to the same models through one interface and may bill you differently. OpenAI's own documentation states that its various API endpoints are not priced separately — tokens are billed at the chosen model's input and output rates [9]. On the platform side, gomodelhub follows a pass-through model: model pricing is passed through at cost, and the platform fee is listed separately, so the price you see should not be assumed identical to the model vendor's list price — verify it on the platform's own pricing or billing page. When you compare costs, compare what your actual provider charges, not two vendors' marketing pages.

Why different models carry different token rates

Token rates differ across models for a mix of reasons: capability and scale, the real cost of running inference, and market positioning. A larger, frontier model that produces higher-quality output tends to carry a higher token rate than a small, fast model built for high-volume, cost-sensitive tasks. These differences are the reason "cheapest per token" and "cheapest to run my workload" are different questions.

What to compare instead: real cost to finish a task

The metric that matters is the cost to finish one unit of work, not the isolated per-token sticker. Comparing models on sticker price per token is close to useless for budgeting, because what you actually pay is the price of every token a model burns to complete a task — including reasoning tokens, retries, and tool-call round trips [7]. A model with a higher unit price that finishes a task in one attempt — with no retry, no extra cleanup, and no human review — is routinely cheaper than a lower-priced model that needs multiple attempts, output trimming, or manual correction. When comparing, measure cost per successful task and account for input/output mix, caching hit rate, retry rate, failure rate, and any review time the output requires.

Scenarios where price should lead vs scenarios where cost alone is the wrong filter

Price should lead for high-volume, fault-tolerant, output-quality-insensitive workloads — classification, extraction, embeddings, bulk first-draft generation — where a cheaper model's occasional imperfection is acceptable and the volume makes unit cost dominant. Cost alone is the wrong filter when the output is business-critical, code-correctness-sensitive, or requires a high first-attempt success rate; there, retries and human review can eat the price difference, and a more capable model that succeeds the first time is the lower real cost. The decision rule is to estimate real per-task cost as task success rate × unit price, then decide.

LLM API Pricing Checklist: Estimate and Audit Your Spend

sequenceDiagram
    participant A as Confirm the unit is per 1M tokens, with…
    participant B as If using a reasoning model, include rea…
    participant C as Use this checklist to turn the concepts…
    A->>B: Request llm api pricing
    B->>C: Execute LLM API Pricing Checklist: Estimate and…
    C-->>B: Return llm api pricing status
    B-->>A: Confirm Confirm the unit is per 1M tokens and t…

Use this checklist to turn the concepts above into an actionable budget and audit process.

Read the price correctly: per-1M-token units, input and output listed separately

Confirm the unit is per 1M tokens and that input and output are listed as separate rates. Never blend them into a single "average" for budgeting — the asymmetry is the whole point.

Map your request profile

Record your average input tokens per request, average output tokens per request, requests per day, and run days per month. These four numbers, combined with the model's two rates, are the entire input to your estimate.

Walk the 10-point pricing checklist

1. Confirm the unit is per 1M tokens, with input and output priced separately.
2. Map your request profile: average input tokens, average output tokens, requests/day, run days.
3. Compute per-request cost with the two-term formula, then scale to daily and monthly totals.
4. Check whether the model supports prompt caching and at what cached-read rate; confirm whether caching is automatic.
5. Check for a batch discount (roughly 50% off) if your workload tolerates async, delayed results.
6. Verify whether the price you pay matches the model vendor's list price or your platform's price — do not assume they are equal.
7. Constrain output length with max_tokens or answer-length controls, since output carries the higher rate.
8. Audit retry logic: retry only timeout/5xx statuses with backoff; do not blindly retry 400s or refusals.
9. If using a reasoning model, include reasoning/thinking tokens in your output budget.
10. Record a pricing checked date, because token rates change and your budget should be re-verified.

Scaling from one request to a daily and monthly budget estimate

Once you have a per-request cost, the projection is straightforward: multiply by requests per day for a daily figure, then by run days for a monthly figure. Then apply corrections for the share of requests that hit cached input, the share you can route through batch, and the effective retry multiplier. A simple monthly estimate is:

Monthly cost ≈ requests/day × run days × [(avg input tokens × input price) + (avg output tokens × output price)] — adjusted for caching, batch, and retry rates.

Core Takeaways and Your Next Step

Recap: token billing, input/output asymmetry, and the variables that break unit-price intuition

llm api pricing is token-based and asymmetric: input and output are metered and priced separately, with output carrying a higher rate because decoding is compute-expensive. One request's cost is a two-term calculation you can compute exactly. Cached input, batch discounts, retries, and hidden reasoning tokens are what make a real bill diverge from a naive "requests × unit price" estimate.

Practical next steps

Pick models on real per-task cost rather than sticker unit price; check whether your workload's stable prefix is eligible for prompt caching and whether async work can move to a batch endpoint; and always verify the price your actual API platform charges instead of assuming it equals the model vendor's list price.

Start comparing real costs on your own workload

The fastest way to make these concepts concrete is to track token usage per model on a real workload, then apply the checklist above. On gomodelhub you can connect multiple models through one OpenAI-compatible API and view usage by model, input tokens, and output tokens in one place — explore the model catalog to check current pricing, or read the docs to see how usage and billing are calculated. For related reading, see our guides on cost-based LLM routing strategies, how AI gateways compare, and how an LLM router works.