Model Prices Keep Falling. What Should You Re-Evaluate?

Model Prices Keep Falling. What Should You Re-Evaluate?

As of September 2026, the automations you priced out and rejected a year ago may now be cheap enough to build. Anthropic's published pricing shows Claude Opus 5.5 at $4 per million input tokens and $20 per million output tokens, against $5 and $25 for Claude Opus 5. The retired Claude Opus 4.1 was $15 and $75.

We build websites and the automations around them, so we watch these numbers because they decide what is worth automating. A drop of this size does not change what a model can do. It changes which jobs are worth pointing one at.

This is our short list of decisions worth reopening, and the two places where a lower price per token does not mean a lower bill.

How Much Have Prices Actually Moved?

Enough to change arithmetic, not enough to make cost irrelevant. Anthropic's pricing documentation lists Claude Opus 5.5 at $4 and $20 per million tokens, Claude Sonnet 5 at $2 and $10, and Claude Haiku 4.5 at $1 and $5. Anthropic's launch note for Opus 5.5 says it costs 40% less than Opus 5 on typical workloads at default settings.

The cheaper tiers have moved too. Anthropic's pricing page states that the $2 and $10 pricing for Claude Sonnet 5, originally announced as introductory pricing through 31 August 2026, is now the standard price, and that the scheduled increase to $3 and $15 will not happen.

Put the current top tier next to a retired one and the shape is clear. Claude Opus 4.1 was $15 and $75 per million tokens. That is the trend line that should make you reopen old decisions.

Where Does a Lower Price Not Mean a Lower Bill?

Two places, and both catch people out. The first is tokenization. Anthropic's pricing documentation states that Claude 4.7 and later models use a newer tokenizer that produces approximately 30% more tokens for the same text, with the exact increase depending on content and workload.

So a headline price cut of 40% is not a 40% cut on your invoice if your text now counts as more tokens. It is still a cut. It is just smaller than the sticker suggests, and you should model it with your own content rather than assume.

The second is scope creep. Cheaper inference makes it tempting to send more context, run more steps and retry more often. That is usually the right call, and it is also how a bill grows while the unit price falls.

This is the reason we still think teams need the habits in controlling AI costs on a web team even in a falling market. The discipline is about attribution, not austerity.

What Should You Reopen First?

The jobs you rejected on cost alone. Not the ones you rejected because the output was not good enough, and not the ones you rejected because nobody would maintain them. Just the ones where somebody did the maths and the maths said no.

In our experience that list is usually short and specific. Classifying every inbound form submission. Summarising every support ticket. Rewriting every product description. Checking every page of a site instead of a sample.

The common thread is volume. These are the jobs where cost per item was the binding constraint, so they are the jobs a price cut unblocks first.

Should You Move Work Back to a Bigger Model?

Sometimes, and this is the most interesting consequence. Teams that pushed work down to a smaller model purely to save money now have a real question to answer, because the gap between tiers has narrowed in absolute terms.

The honest test is not which model is better. It is whether the smaller model is costing you somewhere other than the invoice. Extra retries, longer prompts to compensate, more human review, more edge cases that need a rule. Those costs are real and they rarely show up in a usage dashboard.

If a smaller model is doing the job well, leave it alone. A price cut is not a reason to change something that works. The question in choosing between a small model and a frontier model is still mostly about the task, not the rate card.

What About Caching and Batching?

These often matter more than the headline price, and most teams underuse both. Anthropic's documentation puts a cache read at 0.1x the base input price for most models, and 0.05x on Claude Opus 5.5. A five minute cache write costs 1.25x base input, and a one hour write costs 2x.

The documentation spells out the break-even. Caching pays off after one cache read for the five minute duration, and after two reads for the one hour duration. If your automation sends the same long system prompt or the same document repeatedly, that is the single biggest lever available to you.

Batching is the other one. Anthropic's Batch API is documented as a 50% discount on both input and output tokens, and the documentation says batch and caching discounts can be combined.

The catch is that batching only works for jobs nobody is waiting on. That is the trade we wrote about in running automations in batches or in real time, and falling prices do not change it.

Does Cheaper Inference Change the Build or Buy Call?

It shifts it, slowly, towards building. When inference was the dominant cost, paying a vendor who had negotiated volume pricing made obvious sense. As the raw cost falls, more of what you pay a vendor is for the product around the model rather than the model itself.

That is not automatically an argument for building. The product around the model is usually the hard part, and it is what you would be taking on.

What we would actually do is re-run the comparison with current numbers rather than the numbers from when you signed. A vendor priced against last year's inference cost may now look expensive for the same reason your own build looks cheap.

What Should You Not Do?

Do not rebuild a working automation to chase a rate. The cost of a migration, the regression risk, and the attention it takes are all real, and a few dollars a month of savings will not cover them.

Do not assume the price will keep falling forever and plan a business model around a number that has to keep dropping. It may. It may not. Anthropic's own pricing page shows one scheduled increase being cancelled, which is a reminder that these numbers are set by a company, not by physics.

And do not let a price cut become a reason to skip evaluation. A cheaper wrong answer is still a wrong answer, and the work in evaluating an AI automation before you trust it does not get any less necessary.

How Should You Actually Redo the Maths?

Take one real job, count the tokens it actually uses, and multiply. Anthropic's documentation gives a worked example in this shape: processing 10,000 support tickets averaging about 3,700 tokens per conversation with Claude Haiku 4.5 comes to roughly $37.

That is the format to copy. Volume times tokens per item times the published rate. Then add the things people forget, which are your retries, your system prompt on every call, and any server side tools you use. Anthropic prices web search at $10 per 1,000 searches, for instance, on top of token costs.

Do it in a spreadsheet, once, with your own numbers. It takes twenty minutes and it settles arguments that otherwise run for weeks.

What Does This Mean for Small B2B Teams?

It means the ceiling on what a small team can automate has moved, and the bottleneck has moved with it. When inference was expensive, cost decided what you built. Now, more often, the decider is whether anyone will own the automation when it breaks.

We see that shift clearly in our own work. The conversations that used to be about API spend are now about who reviews the output, what happens on a bad day, and whether the thing is documented well enough for the next person.

That is a better problem to have. It is also a harder one, because you cannot solve it by waiting for another price cut.

What Should You Do This Quarter?

Pick the three jobs you turned down on cost, price them with today's published rates and your own token counts, and build the one with the clearest owner. Leave everything that already works exactly as it is.

That is a modest plan, and modest is the right posture when the underlying prices are still moving. The teams that get burned here are the ones who rebuild everything each time a number changes.

If you want a second opinion on which of your automations is worth revisiting, or help building the one that is, we are happy to talk it through. You can find us at phoenix.studio.