How API Token Billing Works: Input, Output, Cache Reads/Writes and Batch Discounts

Pricing · Published 2026-11-11 · Updated 2026-11-12 · YYSI Editorial · 中文版

The short answer

An API bill is built from four price lines: input tokens, output tokens, cache reads and (on some vendors) cache writes, plus optional batch processing at a discount. The trap is not the arithmetic — it is assuming every vendor implements the modifiers the same way. They do not: some charge a premium to write a cache (Anthropic — and OpenAI's GPT-5.6+ models via the Responses API), some only discount reads (older OpenAI models, DeepSeek), some halve everything for overnight batch jobs (OpenAI, Anthropic) while another halves by time of day instead (DeepSeek off-peak). This guide gives you one formula, three worked examples with known answers, and the per-vendor rules that change the result — rates verified on official pages on 2026-11-11 and re-verified, with two recorded corrections, on 2026-11-12.

The formula, and the units

request cost = (fresh_in x Pin) + (cached_in x Pread) + (written_in x Pwrite) + (out x Pout)
             divided by 1,000,000   [prices are per 1M tokens]

fresh_in  = input tokens NOT served from cache and NOT newly written
cached_in = input tokens that hit an existing cache (billed at Pread INSTEAD of Pin)
written_in= input tokens stored into the cache this request (billed at Pwrite
            INSTEAD of Pin — not in addition)

Three unit rules prevent most billing confusion. Prices are per 1M tokens on the major vendors — a quote "per 1K tokens" must be multiplied by 1,000 before comparing. A token is not a character (Chinese text runs roughly 1–2 tokens per character depending on the model's tokenizer, and the exact split is the vendor's). Cache reads replace input charges — if your 8,000 prefix tokens hit the cache, you pay the read price on those tokens and nothing on them as fresh input.

Worked examples with a teaching rate card (hypothetical)

To keep the arithmetic readable we first use a made-up vendor, ExampleU: input $3/1M, output $15/1M, cache write 1.25x = $3.75/1M with a 5-minute TTL, cache read 0.05x = $0.15/1M, Batch 50% for next-day results. These rates are invented for teaching; the real verified examples follow right after.

Example 1 — no cache

One request: 10,000 input tokens, 2,000 output tokens, nothing cached.

10,000 x $3    = $0.0300   (input)
 2,000 x $15   = $0.0300   (output)
               ------------
                 $0.0600

Known answer: $0.06. If you send the identical request all month, every request costs $0.06 — caching changes nothing until a prefix is actually reused.

Example 2 — cache write once, then cache reads

Same request shape, but 8,000 of the 10,000 input tokens are a stable instruction prefix. The first request writes them to the cache; later requests read them.

write request: 2k fresh x $3 + 8k x $3.75 (write) + 2k out x $15
             = $0.006 + $0.030 + $0.030 = $0.0660   (+$0.006 vs no cache)
read request:  8k x $0.15 (read) + 2k fresh x $3 + 2k out x $15
             = $0.0012 + $0.006 + $0.030 = $0.0372   (−$0.0228 vs no cache)

Known answers: the write request costs $0.0660 — the written tokens are billed at the write price *instead of* the input price, so the write costs only the 25% premium ($0.006) — and each read request costs $0.0372. The premium is smaller than one read's saving, so caching pays for itself on the first re-use. Two rules to keep straight: the write is charged once (never per request), and reads keep saving only while the cache is alive — after the 5-minute TTL expires the next request pays a fresh write. A 1-hour TTL (here 2x input price) buys a longer window at a higher premium.

Example 3 — batch discount, and what cannot be combined

1,000 summaries that nobody needs in real time: 4,000 input + 1,000 output each.

per request: 4k x $3 + 1k x $15 = $0.027
1,000 requests: standard $27.00 -> Batch (50%) $13.50

Known answer: $27.00 standard, $13.50 with Batch. What you cannot do with discounts: interactive requests cannot use Batch (results arrive next-day by design); DeepSeek's off-peak discount is a time-of-day price, not a batch API — you cannot stack it on another vendor's batch rate, and comparing "OpenAI batch vs DeepSeek off-peak" is a fair comparison only because both apply to a deferred workload, not because the mechanisms match; and a cache write must not be re-charged on every request — a modeling mistake that inflates cached workloads by ~25% per request. Stacks that ARE documented: OpenAI's Batch prices each token class at 50%, cached input included, so cached input inside Batch is $0.05/1M; and Anthropic's own pricing FAQ states Batch and prompt-caching discounts can be combined — see the verified table below. (A first version of this guide wrongly called the Anthropic combination undocumented; corrected 2026-11-12.)

The same examples with rates verified today

All rates below were read from the vendors' official pricing pages on 2026-11-11 and re-checked on 2026-11-12; each request shape is the same 10,000 input + 2,000 output as above, so the rows compare directly. For the current snapshot check the prices-data page or model-prices JSON — do not trust this table after providers change prices.

Read the table row by row, not top to bottom: DeepSeek is the cheapest per request here but has no batch API and prices in USD per its own page (the YYSI hub carries the CNY price card); OpenAI and Anthropic land on identical totals in this particular example with different mechanisms — OpenAI via a cheap cache read (0.05x on this model) and a halving Batch, but its GPT-5.6+ models also charge a cache write premium that only pays off once reads follow; Anthropic uses a write/read model whose read rate for this model is a reduced 0.05x rather than the generic 0.1x. Same workload, different mechanics — exactly why per-request totals must be recomputed per vendor.

Vendor rules that change the bill (verified 2026-11-11, cache rules re-checked 2026-11-12)

• Cache model: DeepSeek discounts reads only, charges no write fee, and manages caching automatically. OpenAI splits by model generation: GPT-5.6 and later (via the Responses API) charge a cache write price — 1.25x input for the default 30-minute TTL, 2.5x for 12 hours, replacing the input charge on the written tokens — with reads at 0.1x input on most of these models and 0.05x on gpt-6.1-sol ($0.10), and a minimum cacheable prefix of 1,024 visible input tokens; older OpenAI models have no write charge. Anthropic charges an explicit write premium (1.25x for 5-minute TTL, 2x for 1-hour) and a reduced read rate — with Sonnet 5.5 currently at 0.05x rather than the generic 0.1x. Reads within the TTL extend its life; after expiry the next request pays a new write.
• Batch: OpenAI and Anthropic both document 50% off, for workloads that can wait for results — and both document that Batch and caching discounts stack (OpenAI prices cached input inside Batch at 50%; Anthropic's FAQ says the discounts can be combined). DeepSeek instead halves its regular prices off-peak (nights, weekends, Chinese holidays) — a scheduling discount, not a separate API.
• Long context: OpenAI's page doubles the per-token prices beyond the short-context threshold (gpt-6.1-sol: $4/$15), and a "Fast" tier doubles them again. Check where your workload sits.
• Reasoning tokens: OpenAI's docs state reasoning tokens "are billed as output tokens" — invisible in the response text but visible on the bill, which is why a "short" reasoning-model answer can cost more than it looks. Budget with the output counter, not the visible answer length.
• Tool calls: most vendors charge only the tokens a tool round-trip consumes, but DeepSeek's Search and Fetch APIs bill per successful request ($0.75 per 1,000) on top of tokens. Per-request fees are a different unit — never mix them into a per-token rate.
• Currency and price-card quoting: DeepSeek's own page quotes USD (the YYSI hub carries the CNY card); quotes per 1K vs per 1M differ by 1,000x — normalize before comparing vendors.

What our calculator models — and what it does not

The AI API cost calculator computes the base formula with one input price, one output price, one cache-hit price and a cache-share slider — enough for every no-cache and cache-read example above. It does not model: cache write premiums, TTL renewals, a Batch toggle, reasoning-token output padding, per-request tool fees, or per-1K quoted rates. For those, do the arithmetic manually from the formula block above — for example, an Anthropic-style first request is calculator output with the input price field temporarily set to the write price, and the read requests with the read price in the cache field. We chose to document these limits rather than add features, because the calculator is deliberately a generic rate-card tool; a vendor-specific billing simulator would need its own tests and would go stale with every price change. If you need a modeled feature repeatedly, tell us via the tool's feedback box.

Checklist before you trust any bill

1. Are input and output priced separately? (They always are.)
2. Does the vendor charge cache writes, reads only, or both — and what TTL renews a write?
3. Is the discount Batch (deferred results), off-peak (time window), or something else? Stack only combinations the vendor documents — OpenAI and Anthropic document Batch×caching; DeepSeek's off-peak is a schedule, not a stackable batch.
4. Are reasoning/thinking tokens billed as output for your model? Count them.
5. Are the prices per 1M or per 1K, USD or CNY? Normalize first.
6. Recompute with current rates from the prices-data page before signing up for anything recurring.

Teaching rates in Part A are hypothetical; real rates were verified on official pages on 2026-11-11 and re-verified on 2026-11-12 (two corrections recorded above and in the verification note), each linking to its source. The per-request formula matches our calculator, whose supported inputs and known limits are listed above.