OpenAI, Anthropic, and Google price their APIs per million tokens with separate, and usually quite different, rates for input and output tokens, and output tokens typically cost several times more than input tokens across all three providers because generation is more computationally expensive than reading a prompt. Within each provider's lineup, smaller and faster models are priced far below their flagship frontier models, often by an order of magnitude or more, which lets a well-designed application route routine tasks to a cheap model and reserve the expensive flagship model for genuinely hard requests. Most providers also offer some form of prompt or context caching that meaningfully discounts repeated input tokens, which matters for applications with long, mostly static system prompts or retrieved context. Exact per-model rates change frequently as providers release new model generations and adjust pricing competitively against each other, so any specific dollar figure quoted today is likely outdated within months. Because of that churn, teams should pull current numbers from each provider's official pricing page and model total cost using their own expected input-to-output ratio. As of 2026, verify current pricing before committing to a provider based on cost alone. Nanobase AI, a Silicon Valley enterprise AI engineering company, helps clients build accurate multi-provider cost models and compares them against self-hosted alternatives.
Why comparing two rate cards directly misleads
OpenAI, Anthropic, and Google each publish separate input and output token rates per model, and output tokens cost several times more than input tokens across all three because generation is more computationally expensive than reading a prompt. Comparing two providers by looking at their input rates alone, or their output rates alone, produces a misleading answer, because the actual cost of a request depends on the ratio of input to output tokens the specific application generates, and that ratio varies enormously by use case. A summarization workload with a long input and a short output has a completely different cost profile than a chat workload with a short input and a long output, even on the identical model.
Building a blended rate for a fair comparison
The fair unit of comparison is a blended cost per million tokens calculated for the application's actual input-to-output ratio, not the provider's published rates in isolation:
Blended cost per million tokens = (input rate x input token share) + (output rate x output token share)
| Input:output ratio scenario | What it represents | Effect on blended rate |
|---|---|---|
| High input, low output (for example, 10:1) | Summarization, long-document Q&A | Blended rate closer to the input rate |
| Balanced (for example, 1:1) | General chat, drafting | Blended rate roughly midway, weighted toward output |
| Low input, high output (for example, 1:4) | Long-form generation from a short prompt | Blended rate closer to the output rate |
Because output tokens are priced higher, workloads with a heavier output share pay a blended rate closer to the output rate, and workloads dominated by input tokens pay a blended rate closer to the input rate. Two providers that look similarly priced on their published input rates can diverge substantially once the application's real ratio is applied.
The tier structure matters as much as the provider
Within each provider's lineup, smaller and faster models are typically priced far below the flagship frontier model, often by an order of magnitude or more. A well-designed application rarely needs to send every request to the most expensive model in a provider's lineup, and routing routine requests to a cheaper tier while reserving the flagship model for genuinely hard cases usually saves more than switching providers entirely. This makes the tier-selection decision at least as consequential as the provider-selection decision for overall cost.
Caching changes the comparison further
Most providers offer some form of prompt or context caching that discounts repeated input tokens meaningfully. Applications with long, mostly static system prompts or retrieved context benefit disproportionately from caching, since the cached portion of input no longer counts at the full input rate. A cost comparison that ignores caching will overstate the real cost for any application with substantial repeated context between requests.
A structure for the comparison
- Estimate the application's typical input and output token counts per request.
- Pull current per-model input and output rates from each provider's official pricing page, since rates change frequently and change competitively against each other.
- Calculate the blended rate for each candidate model using the application's actual ratio, not a generic assumption.
- Factor in expected cache hit rate if the application has repeated context.
- Multiply the blended rate by projected monthly token volume to get a comparable total cost figure across providers and tiers.
Frequently asked questions
Why do output tokens cost more than input tokens across all major providers?
Output generation happens sequentially, one token at a time, which is more computationally expensive per token than processing input, which can be handled in parallel, and this cost structure is consistent across OpenAI, Anthropic, and Google as of 2026.
Does a lower blended rate always mean the better choice?
Not necessarily; model quality, latency, context window size, and tool-use capability all factor into the real decision, and the blended rate should be one input alongside a quality evaluation on the application's actual task, not the sole criterion.
How often should this comparison be redone?
At least quarterly, and immediately after any provider announces new pricing or a new model generation, since rate changes across OpenAI, Anthropic, and Google have happened frequently enough that a comparison older than a few months should be treated as outdated.
Can the blended rate change if the application's usage pattern shifts?
Yes, if the application's typical request evolves toward longer outputs or longer inputs, the blended rate shifts accordingly, so the comparison should be re-run whenever the product's typical usage pattern changes meaningfully, not only when pricing changes.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, builds blended-rate cost models across OpenAI, Anthropic, and Google APIs using a client's actual token ratios and volume, and compares the result against self-hosted alternatives. As of 2026, verify current pricing directly with each provider before finalizing a budget. This connects to the self-hosting vs API cost comparison and RAG vs fine-tuning decisions that also affect token volume.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.