Loading...
How large language models are billed: per million tokens, in and out, at rates set by model tier.
Quick Definition
LLM pricing is the billing model for large language models, typically charged per million input and output tokens, with rates that vary by model tier, capability, and features like long context or caching. Understanding it is essential for forecasting and controlling AI spend.
LLM pricing, or model pricing, is the billing structure for large language models. The dominant pattern is pay per token: a rate per million input tokens (everything you send the model) and a higher rate per million output tokens (everything it generates), with rates set by model tier and capability.
Three things make the bill move. Model tier is the biggest: flagship models can cost ten or more times the lightweight tiers of the same family, whether that is Claude, Gemini, or another provider. Prompt length is second: system prompts, conversation history, and attached documents all count as input tokens on every single call. Output length is third, and output rates are usually several times input rates.
Example. A team pastes a 30-page policy document into every request as context. Each call burns roughly 20,000 input tokens before the user even asks anything. Retrieving only the relevant two paragraphs per query cuts input tokens by 95 percent, and the monthly model bill drops accordingly.
Managing LLM pricing well means treating tokens as a metered resource: pick the cheapest tier that meets quality, engineer prompts for brevity, use context caching where offered, and set per-feature budgets and alerts. The token budgeting guide covers the control side, and the Gemini pricing and Bedrock pricing breakdowns show real rate structures.
Generation is more computationally expensive than reading. Providers price output tokens at a multiple, often three to five times, of the input rate.
Defaulting every task to the flagship model. Most workloads run acceptably on tiers that cost a tenth as much, so route by task difficulty.
From unit assumptions: expected requests times average tokens per request times the rate, tracked per feature so growth in one product does not hide in the total.