Cache and peak pricing without double-counting tokens

Rules checked September 5, 2026 · Ollama hosted usage · Synthetic worked examples

A token estimate can be arithmetically correct and still describe the wrong bill. Two frequent causes are adding cached tokens on top of an input total that already includes them, and treating the percentage of peak clock hours as the percentage of peak usage. Both mistakes hide behind plausible-looking numbers.

The calculator uses total input per request, a cached share of that total, generated output, and a token-weighted peak share. It then prices fresh input, cached input and output separately. Try the workload calculator with the example below, or inspect the methodology for the full model. These rules are specific to the selected Ollama billing basis; they are not a universal importer for every provider's usage JSON.

Total input already contains the cached part

Ollama's usage documentation distinguishes prompt_eval_count, the total input count, from prompt_eval_cached_count, the portion served from cache. Generated output is reported in eval_count. For the input side, cached tokens are a subset, not an extra request added to the total. The official cached-usage implementation provides additional context for these semantics.

If total input is 10,000 tokens and cached input is 8,000, fresh input is 2,000. Pricing 10,000 tokens at the fresh rate and another 8,000 at the cached rate would charge for 18,000 logical input tokens. Instead, split the 10,000 into two non-overlapping parts. A 100% cache assumption leaves zero fresh input; a 0% assumption leaves all input fresh.

When the cached field is missing, the observed cache share is unknown. It is not evidence of zero cache use. You can choose a conservative zero-cache scenario for planning, but label that choice as an assumption. Keeping “not reported” separate from “reported as zero” is essential when you compare historical traces or investigate a discrepancy.

A complete synthetic GLM 5.3 calculation

Use the following synthetic workload: 10,000 total input tokens per request, 80% cached input, 1,000 output tokens, 100 requests per active day and thirty active days within one monthly billing period. The total is 3,000 requests. That creates 6 million fresh input tokens, 24 million cached input tokens and 3 million output tokens over that single billing period. The active-day field accepts one to thirty-one days; it is not a multi-month projection.

At the GLM 5.3 rates on the official pricing page, the three categories are $1.40, $0.26 and $4.40 per million tokens respectively. Fresh input therefore costs $8.40, cached input $6.24, and output $13.20. Adding the categories gives $27.84 of consumption. This example is a reproducible arithmetic fixture, not a benchmark or a report about typical GLM users.

The resulting $27.84 is not automatically the subscription bill. Under the modeled monthly plans, Pro's $20 fee covers that consumption within its allowance, while PAYG consumption expense is $27.84 before any starter benefit. The credits versus cash guide explains the second step. Keeping consumption calculation separate from plan calculation makes errors easier to isolate.

Peak share measures work, not time on a clock

The current pricing table publishes a peak schedule for the listed DeepSeek models: weekdays from 12:00 inclusive to 18:00 exclusive, in UTC. The calculator does not apply a blanket surcharge to every model. For a model without a separate published peak rate, changing the peak share has no effect on its modeled consumption.

A six-hour window does not mean that 25% of your usage occurs at peak. A batch job may run entirely outside that window. A workday schedule in another time zone may concentrate almost all requests inside it. Your local daylight-saving change can also shift how your local working hours align with the same UTC window. Inspect when work runs; do not infer usage from the fraction of clock hours alone.

The simplified form uses one peak percentage across token categories and assumes the same per-request workload and cache mix at peak and off peak. If your peak requests are much larger or have a different cache profile, model the two groups separately and combine their consumption. Do not pretend that a single slider captures a strongly uneven workload exactly.

Blend category rates before multiplying

For each category, the effective rate is the off-peak rate plus the peak share multiplied by the difference between peak and off-peak rates. With peak share p between zero and one, this is effective = base + p × (peak − base). Multiply fresh, cached and output token quantities by their respective effective rates, divide by one million, then add the resulting consumption values.

For a second synthetic example, take one million fresh input tokens on DeepSeek V4 Flash, with no cached input and no generated output. At the checked rates, all off-peak input costs $0.22 and all peak input costs $0.44. A 50% token-weighted peak share costs $0.33. Output is deliberately zero to isolate the peak-rate arithmetic, not to suggest a normal completed interaction has no generated tokens.

Do not round each tiny per-request category to cents before multiplying by the request count. A category that displays as $0.00 for one small request can become material across thousands of requests. Keep full numeric precision during the calculation and round only the displayed amounts. This also preserves genuine ties between plan costs.

Count requests, not sessions or context capacity

A coding session can make multiple model calls, and later calls may include a growing history. The input total for one call is not necessarily representative of every call in the session. Similarly, a model's advertised context capacity is a limit, not proof that every request processes that many tokens. The context-length documentation concerns capacity; the usage fields concern actual processing.

For a practical forecast, aggregate the request counts and token categories from a representative sample you are permitted to inspect. Then choose planning averages consciously. Include retries or background activity when relevant, but do not count a client-side draft that was never sent as a billed request. This site does not read your local files, infer your private usage or perform paid test calls.

Provider compatibility does not guarantee matching fields

An OpenAI-compatible endpoint describes an interface, not a universal bill. Other providers can define fresh input, cache writes and cache reads differently. In the native Claude caching documentation, those input categories must be considered together when reconstructing total input. Applying the Ollama subset rule blindly to an unrelated response can produce a different error.

This version therefore accepts explicit numeric assumptions instead of offering a universal pasted-JSON importer. It also does not tokenize arbitrary text. Model-specific tokenization, multimodal inputs and future generated output require additional treatment. An estimated text length is not an exact provider count, and an input count before a call cannot guarantee the final output length.

Check the uncertainty before the plan result

Before using the result, confirm the host, model variant, total-input meaning, cache assumption, peak distribution and period length. If one is uncertain, calculate a reasonable range. A source-checked rate table cannot rescue an invented workload. Likewise, observed usage from an old rate period should not be silently described as a current invoice.

Return to the official pricing page when the verification date is old or your selected model changes. The page's date tells you when its rules were checked, not that rates are streamed live. Use the Pro versus Max comparison only after the consumption basis is credible, and remember that its lowest-cash label does not evaluate latency, quality, concurrency needs or service eligibility.