Sonnet 5 stays at $2/$10: the +50% that never came, and how to correct your cost models

On August 8 the guidance was clear: the introductory price of Claude Sonnet 5, $2 per million input tokens and $10 per million output, would end on August 31 at 23:59 UTC, and from September 1 the standard rate of $3 / $15 would apply, a 50% increase on both axes with no extension announced. On August 10 Anthropic reversed it. The intro rate became the permanent rate, the increase was cancelled, and subscription prices stayed where they were. On September 1 the price held at $2/$10 exactly as promised. That is good news with a cost: every cost model built in the intervening weeks is now wrong in the safe direction, and wrong is wrong.

What the two announcements said

The August 8 picture mattered because Sonnet 5 has been the default seat model since July 1. Every agent loop, Claude Code pipeline and product inference path that never picked a model explicitly was about to get a 50% unit-price jump. The advice at the time was sound and still is: measure Sonnet 5 spend with input and output separated through the Analytics API or the admin console, turn on prompt caching and the Batch API where the workload allows, and route routine steps to Haiku so Sonnet only sees the hard ones.

The August 10 reversal removed the deadline but not the reasons to do the audit. The September 2 update confirmed the hold and added a hard budget cap for Managed Agents, with a budget_reached stop reason, plus Opus 5 as the Enterprise default. If you want the full price sheet with the other vendors next to it, /prices is live from OpenRouter.

The correction math

The error in a model that assumed the increase is not subtle. A workload projected at $15,000 per month under $3/$15 costs $10,000 at $2/$10. The planned number overstates by 50%; equivalently, actual spend comes in one third below it. Because the increase applied to both axes, the ratio does not depend on your input-to-output mix, which makes the correction a single multiplier across every line in the forecast.

Where it does change shape is break-even. Two decisions that were marginal at the September rate move:

• Batch workloads. If a nightly job only cleared the ROI bar with the Batch API discount applied to the higher rate, at $2/$10 it clears it with headroom.
• Long agent loops. Output tokens are the expensive axis, and agent loops are output-heavy. A third off the baseline is the difference between "cap the loop at N steps" and "let the verifier decide when to stop".

A price you planned for and did not pay is still a number in someone's spreadsheet, and the spreadsheet does not correct itself.

Sending the correction

If you told clients in August to expect a 50% increase, tell them now that it did not happen. I sent a one-paragraph note to every client whose Q4 forecast I had touched: what I said on August 8, what changed on August 10, what the new number is, and that the caching and routing work we did anyway is now pure savings rather than damage control. Several replied that it was the first vendor-price correction they had ever received.

The checklist I used:

• Find every forecast, quote or budget line built on $3/$15 and multiply by two thirds.
• Re-run the break-even on any workload that was deferred or capped because of the September rate.
• Keep prompt caching on. The caching economics never depended on the base price going up.
• Keep the Haiku routing for routine steps.
• Note the change in the cost model with a date, so the next person knows why the number moved.

For the seat-pricing side, where Sonnet 5 shows up inside Copilot, see Sonnet 5 Copilot pricing; the API hold does not touch subscription prices, which were never scheduled to move.

The honest gap

"Permanent" is a vendor word. Anthropic said the intro rate is the standard rate now, and the September 1 check confirmed it, but nothing prevents a future price change with different framing. The audit work is the durable part. The price is a fact about today, and I would keep the Analytics API export running so the next change, in either direction, shows up in your data before it shows up in a newsletter.