LLM Token Prices 🔥 Costs Drop Up to 80%—Now
LLM token prices dropped up to 80%—learn what drives LLM inference costs, how prompt caching works, and AI pricing strategy for open-weight models.
Why LLM Prices Are Falling - and What a Token Really Costs
If you've priced an AI coding agent or a production API recently, the numbers may look unfamiliar. In just a few months, OpenAI and Anthropic cut prices on several models by as much as 80%. In some cases, newer models cost less while matching (or beating) older ones. That's not how most businesses expected a market still spending heavily on R&D and compute to behave.
But the headline rate isn't what you pay in practice. Input tokens, generated tokens, and cached context can all have different prices. If an agent reuses long conversations on every turn, cached reads can dominate the bill. And when tokens get cheaper, teams often run more jobs - so spending can rise even while unit prices fall.
This article breaks down the recent price changes, the underlying economics, and a practical way to estimate costs for real workloads. The key question isn't whether a token has one fixed "true cost." It's how competition, serving efficiency, and customer behavior determine what your bill ends up being.
Why have LLM prices fallen so quickly?
The simplest explanation is competition. Over a short stretch, OpenAI and Anthropic shipped new models, discounted existing ones, and reduced rates for cached input. It doesn't read like one coordinated "price reset." More like a market adjusting to multiple pressures at once.
A rapid sequence of cuts
In June, OpenAI introduced GPT-5.6 Sol at $5 per million input tokens and $30 per million output tokens, plus the smaller Luna model at $1 and $6. Anthropic launched Claude Sonnet 5 at $2 per million input tokens and $10 per million output tokens, then kept that launch price. Its later Opus 5 landed at $5 and $25.
By late July, OpenAI cut Luna by 80% - to $0.20 per million input tokens and $1.20 per million output tokens. After that came more changes, including a temporary reduction for Sol, cheaper cached reads on Anthropic models, and the September releases of GPT-6 Sol and Luna with lower input/output rates than their predecessors. GPT-6.1 Sol then reduced the cached-read rate again.
The exact model names and rates matter, of course. But what's really consistent is the pace: these changes arrived quickly, and providers had limited time to ignore each other. Also, if a model is easy to test via an API or coding harness, it's usually easy to swap out. Teams can compare options using their own repositories instead of committing based only on a benchmark chart or a launch announcement.
Models are becoming easier to compare and switch
For many everyday tasks, a model doesn't need to be the single best option across every metric. It just needs to be good enough for the job at the price and latency your team can live with. If a cheaper model can handle routine code edits, classification, or summarization, developers can route those tasks away from a premium model.
Open-weight models add another layer of pressure. Providers can host the same released weights, which gives buyers more choices of endpoints and pricing. DeepSeek Flash, for instance, took off in part because of its low advertised rates. Later versions improved benchmark performance while staying inexpensive, and multiple inference providers started offering them.
That doesn't mean every model is interchangeable. A stronger model can still be worth it if it reduces failures, review time, or the number of agent turns. But when switching is straightforward and alternatives are credible, providers have less room to keep charging more just because customers are already using their API.
What does a token really cost?
There isn't one token price that applies to every provider or every workload. A token is a unit of text processing - the real economics depend on the model, hardware, request pattern, provider infrastructure, and how much capacity is actually being used. For a buyer, the number that matters is usually not the provider's headline rate. It's the effective cost of finishing a task.
Separate input, output and cached input
Pricing is typically presented as three rates per million tokens: input, output, and cached input. Input tokens are the prompt and context you send to the model. Output tokens are what the model generates. Cached input covers previously processed context the provider can reuse instead of fully processing again.
Those categories aren't interchangeable. Output can cost several times more than normal input. Cached reads can be a small fraction of the input rate. A short question-and-answer exchange may be mostly output tokens. A coding agent that repeatedly sends the same large repository context may be dominated by cached reads.
Here's the pattern that surprises people: imagine an agent that reads a large codebase, makes a change, and then resends much of the earlier conversation on every turn. The agent's total token count might look huge. But if most of that "extra" text is reused context served from cache, the bill may drop dramatically when cached pricing drops - far more than the ordinary input rate change would suggest.
Calculate effective cost per task
A practical estimate starts with your usage pattern, not the model's listed price. For each task type, measure:
- Ordinary input tokens and their rate.
- Cached input tokens and their rate.
- Output tokens and their rate.
- Number of model calls, retries, and agent turns.
- The percentage of repeated context that actually gets a cache hit.
Then compute costs across a representative set of tasks. Don't ignore failed runs. A model that's cheaper per token can still cost more if it needs more retries to produce an acceptable result. And include human review when model quality changes how much checking you need.
That's why "true token cost" arguments often miss the point. A provider may have a certain internal serving cost - but that doesn't automatically become a universal market price. For a business, the relevant metric is the cost of a completed, accepted outcome, including the work required to reach it.
How do caching and inference providers change the bill?
Caching can turn a minor line item in a pricing table into the biggest driver of unit economics. In agentic coding, a conversation carries forward prior instructions, tool results, and code context. If the system reuses that context on later turns, most of the token volume can shift from fresh input to cached reads.
Why cache rates matter more for agents
Some source data describes cache reads as roughly 96% to 99% of token expenditure in certain coding-agent workloads, with cache hit rates often around 90% to 100%, depending on the inference provider. Those numbers won't be identical for every agent, but they explain why headline input/output rates can be misleading.
For example, Anthropic's Fable 5.1 cut cache-read pricing by 75% versus Fable 5, while keeping the same listed input and output rates. If your workload has a high cache-hit rate, that change can translate into a much larger reduction in actual spend than you'd expect from the headline rate alone. Similar cached-read reductions show up in later model announcements from major labs.
The practical takeaway is simple: measure cache behavior on your own requests. A provider with "better" cache pricing might not end up cheaper if it has a lower cache-hit rate for your patterns, doesn't support the same context approach, or leads to more retries. Compare effective cost at the endpoint level - not just the model name.
Open weights create more hosting options
Open-weight models can be hosted by multiple inference providers. A routing platform may offer several endpoints for the same model, with differences in price, cache rates, availability, and performance. That creates competition not only between model developers, but also between companies selling access to the same underlying weights.
The outcome is often a spread of advertised prices for one model, and a narrower spread in effective costs once you account for cache behavior. It also means the cheapest listed endpoint isn't automatically the best choice. You still have to check reliability, latency, data handling, and service terms.
For procurement, that changes the game. Model selection and hosting selection can be separate decisions. You might pick a model for quality, then pick a provider based on your workload's cost and operational needs. And wherever possible, keep the model and endpoint configuration replaceable - otherwise a low initial price can become an expensive migration later.
Are the price cuts temporary or a durable trend?
The evidence points to sustained downward pressure, not a promise that every model will keep getting cheaper forever. Several forces push in the same direction: competition among major labs, open-weight alternatives, more inference providers, and improvements in serving efficiency. Those factors apply general pressure to prices, even if they don't guarantee a specific rate for every company.
Competition constrains the price of a substitute
If a provider can serve a model profitably at a lower rate, competitors have a reason to respond. With open-weight models, a marketplace with many hosts makes that pressure visible. Providers also have little reason to keep running an endpoint that's consistently unprofitable when they can allocate capacity to other work.
This is different from markets where one or two companies control access and customers face high switching costs. LLM providers still benefit from proprietary models, infrastructure, and product integration. But customers can often test alternatives with relatively low friction. A strong open model can be a credible substitute even if it doesn't win on every task against the top proprietary option.
Price isn't the only battleground either. Providers compete on quality, latency, uptime, context handling, and enterprise support. Premium models can keep value if they save enough engineering or review time to justify the higher cost. In other words, a model's price floor depends on serving economics and how much customers value results.
Better efficiency can lower prices without "cutting corners"
Lower prices don't automatically mean a provider is selling below cost or quietly degrading model quality. Anthropic, for example, attributed a later Opus model's lower price to needing less compute to serve than its predecessor. Improvements in inference infrastructure, model design, or operational efficiency can reduce the resources needed per request.
A lower price can also be strategic. A company may want more developers to adopt a model, use more of its products, or build workflows around its platform. That possibility is worth watching - especially when companies are still investing heavily in R&D and compute while preparing for public scrutiny. But "deliberate loss-leading" alone doesn't explain every cut. Real alternatives and provider economics still matter.
There's also demand. When each task is cheaper, customers often run more tasks, use stronger models, or add agents to workflows that were previously too expensive. Aggregate spend can rise even while average token prices fall. For a business, lower unit costs are an opportunity - not a guarantee that your monthly bill will drop.
What should businesses do about lower LLM prices?
A falling price helps only if you understand what your workload consumes - and you can change providers without adding operational risk. The answer isn't "move everything to the cheapest endpoint." It's to set a cost-and-quality baseline, then route work based on what happens when things fail.
Use a workload-based evaluation
Start by grouping requests by purpose: routine extraction, code generation, complex reasoning, customer-facing answers, or other tasks tied to your product. For each group, record:
- The current model and endpoint
- Cost per successful task
- Latency
- Failure rate
- Human review effort
Then test alternatives using a fixed set of representative inputs. Include normal cases and difficult edge cases. Benchmarks can help narrow the options, but they won't tell you whether a model handles your repository conventions, your customer language, or your tool workflow. Run the evaluation in a harness that captures token categories and retries, so you can see why costs change.
Use decision rules like these:
- Keep the stronger model when it materially reduces failures, rework, or review time.
- Use a cheaper model for bounded tasks where mistakes are easy to detect and recover from.
- Escalate uncertain or high-impact cases instead of paying premium rates for every request.
- Re-test when the model, provider, prompt, or agent workflow changes.
Manage total spend, not just the unit rate
Set budgets around completed work and user value. Track monthly cost alongside task volume, success rate, and downstream support or engineering time. If a 75% unit-cost reduction leads to a fivefold increase in usage, your overall spend might rise. That can still be worthwhile if the extra usage creates enough value - but it should be an intentional choice.
For subscriptions and coding-agent plans, compare your allowance with your actual usage. A lower effective price per task might mean you can downgrade a plan tier without reducing output. On the other hand, a provider might adjust usage limits as models become more efficient. Treat subscription value as a separate decision from API token pricing - one doesn't reliably predict the other's margin or economics.
Finally, keep a fallback path. You don't need complex multi-provider routing for every application, but high-volume or business-critical workflows should have a tested alternative. Document data handling requirements, acceptable latency, and the minimum quality bar - so a price change doesn't turn into an urgent migration.
Conclusion
LLM prices are falling because the market is getting more competitive - and in some cases, cheaper to serve. Open-weight models and multiple inference providers make it harder for any single lab to set prices without accounting for alternatives. Better cache economics add another layer, especially for agents that repeatedly process large contexts.
But there's no meaningful business decision in a token price alone. Measure the cost of a successful task, test quality on your actual workload, and account for cache hits, retries, and increased usage. If you can do that and keep your options open, falling prices become a lever - not just a headline.