For a few years the cost of a unit of AI output fell reliably enough that people stopped modelling it. You built something that was marginally too expensive, waited two quarters, and it became affordable. That was a real dynamic and it shaped how a lot of products were designed.
It is worth asking what happens to those decisions if the trend flattens, because several things are pushing in that direction at once.
Why the cheap curve is under pressure
The falling price per unit came from two places: models getting more efficient, and providers competing hard for adoption. Both have limits.
Efficiency gains are real but they are being spent, not banked. The frontier has moved toward models that think for longer before answering, and toward agents that make many calls where a product used to make one. A cheaper unit multiplied by far more units is not a saving. It is entirely possible for a bill to go up in a month when the per-unit price went down, and that is the case worth modelling.
The competitive subsidy is the other half. Land-grab pricing is a phase, not a physics constant. It ends when the land is grabbed. Provider pricing is public, so this is something you can check rather than assume: Anthropic and OpenAI both publish their model pricing, and the pattern is worth watching rather than assuming.
The exposure is usually in the architecture, not the invoice
The businesses that get hurt by this are rarely the ones spending the most. They are the ones whose product only works at a particular price point, where the design assumed the call was nearly free.
The pattern looks like this: a feature that makes a model call on every page load, or on every row of a spreadsheet, or every time a user types. At a tenth of a penny nobody thinks about it. At a penny it is the largest line in the cost of delivery, and by then it is woven through the product.
What is actually worth doing about it
None of this is a reason to avoid building. It is a reason to build so that the price is a variable rather than an assumption.
- Know what you spend per unit of the thing your customer values, not per month. Per client, per document, per booking. A monthly total tells you nothing about whether it scales.
- Do not send the biggest model at every job. Much of the routine work in a production system is classification and extraction, which a much smaller model handles for a fraction of the cost.
- Cache at both levels, and keep them straight. Prompt caching discounts the repeated prefix you send every call, a long system prompt or a document, and it does not stop the model generating a fresh answer. Caching the answers themselves is your own job, and it is where the larger saving usually is. Key on the actual inputs, scope the cache per client so one tenant never sees another's result, and invalidate when the underlying record changes.
- Keep the provider swappable. If changing model means rewriting the product, the price is not really a variable.
- Know which features would have to go if the price doubled. Deciding that now is much easier than deciding it during a pricing announcement.
Dependency, separately from cost
Cost is the visible half. The other half is dependency. A business whose core workflow only functions while a specific external service is cheap and available has taken on a risk it may not have written down anywhere.
That is not an argument for running your own models, which for most small businesses is a worse trade. It is an argument for knowing what happens on the day the terms change, and for that answer being something other than finding out.
The cheaper token was a real and useful trend. The mistake is treating its continuation as a plan.
Related reading: why UK small businesses are behind on AI, and whether SEO still matters now assistants answer first. See also automation and AI workflows and what we have built.