As checked 2026-10-25: A model name does not determine a bill by itself. This is a dated economics guide, not a permanent price guarantee or a personal hands-on benchmark.
Scope: global English reference; USD list prices where shown; local eligibility, currency, taxes, negotiated terms and model release dates require separate confirmation. Dynamic source-page prices have a check date, not a verified initial effective date.
The bill starts with four quantities
A model name does not determine a bill by itself. Record uncached input tokens, cache-hit input tokens, output tokens, and any separately billed operations for the same request. For a rate quoted in dollars per million tokens, multiply the token count by the relevant rate and divide by one million. Keep reasoning tokens within the vendor’s documented output definition where applicable. This approach matters because a chatbot-style question with a short reply has a very different input-to-output mix from a long report or a retrieval task that repeatedly sends thousands of source tokens.
A numerical workload, not a price prediction
Suppose an application processes 800,000 uncached input tokens and produces 250,000 output tokens in one billing period. Using a hypothetical $2 per million input tokens and $8 per million output tokens, the two components would be $1.60 and $2.00, giving $3.60 before tools, taxes and retries. These hypothetical rates are for explaining arithmetic; they are not asserted to be any vendor’s price. In production the calculator resolves both rates by price_id and snapshot date, so rerunning the worksheet after a tariff change does not rewrite history.
The denominator trap
Many vendor tables quote rates per one million tokens, but speech can be charged per minute or character, images per output asset or image token, and video per second or tokenized frames. A 100,000-token month costs one tenth of a published per-million rate, not the full displayed rate. Conversely, a million cached input tokens and a million fresh input tokens are not interchangeable line items. Model output sometimes includes hidden reasoning tokens, so estimating output from visible words alone can understate the bill.
Build a cost ledger that can be audited
Store one row per priced operation, its unit, currency, region, processing tier, exact model identifier, source URL, checked timestamp and effective timestamp if the vendor publishes one. Join measured events to rates by unit and applicable scope. Keep failed or retried requests in a separate event ledger rather than assuming all attempts are free. Reconcile application estimates against provider billing exports, and treat unexplained variance as an investigation, not as a rounding error.
Limits and alternatives
This method cannot predict tokenization perfectly from characters or words; measure token usage from responses or a documented tokenizer. For costs dominated by image, speech or video generation, start with the respective media ledger instead. For enterprise deployments, include minimum commitments, support, regional processing and negotiation rather than using public list rates as contractual invoices. See the batch, prompt caching and regional billing explainers for the cases most likely to change the total.
An invoice reconciliation procedure
Run a daily export with request identifier, model ID, processing tier, currency and the four token counters. Select three unusually expensive requests and reprice them independently using the archived tariff. Compare the result with the vendor’s billing console and list every difference: retries, extra reasoning tokens, tool fees, minimum billing increments or a different model alias. Keep the investigation notes beside the rate ID. This creates an evidence trail when a reader asks why an initial estimate diverged from the amount actually charged. It is more reliable than using character count to reverse-engineer tokenization after the fact.
A useful sensitivity analysis
Recalculate the same workload with output tokens 25 percent above and below the current estimate, then repeat with half the expected cache-hit share. Output-heavy writing and code tasks can be disproportionately sensitive to output rates, while document ingestion often depends more on input and cache usage. Preserve the scenarios as assumptions, never as benchmark findings. If the totals cross a procurement ceiling in the pessimistic scenario, consider a smaller model for preprocessing, hard output limits or more selective source retrieval before committing to production traffic.
Decision checklist
- Identify the specific plan or API endpoint, model version, region and currency before pricing a job.
- Measure input, output, caching, generated media and failed-job units separately.
- Check the official pricing page again before procurement, especially if the SKU has no effective-date notice.
- Keep source evidence and a timestamped price ID; do not treat unknowns as zero.
Pricing evidence boundary
This cost discussion concerns Multi-vendor. Reproduce a quote only with its exact model or plan identifier, chargeable unit, billing region, processing mode and timestamp; a changing vendor rate card is not a permanent price guarantee. If any one of these dimensions is missing, keep the associated rate and worked scenario under editorial review instead of filling the gap with an estimate.
Sources & Further Reading
- API token rates depend on exact tier, modality, model, tool and region — official first-party source, accessed 2026-10-25; original effective date not specified in source.
- Official list-price PDF with effective date 2026-05-27 and scoped Claude API rate rows — official first-party source, accessed 2026-10-25; official price-effective date 2026-05-27.
- Gemini Developer API shows tier/model/context/modality-specific rates and cache storage — official first-party source, accessed 2026-10-25; original effective date not specified in source.