Treat promotional pricing as a temporary discount, not a baseline. Model your costs at list price, tag every model dependency with its price-expiry date, alert on cost per request instead of monthly totals, and decide the downgrade path before the promo window closes.
Why Intro Pricing Needs a Different Baseline
When a provider launches a model with a temporary discount and publishes the later list price, both numbers matter. The discount is real, and using it is rational. The trap is architectural: teams size features, set budgets, and pitch business cases on the intro number, then treat the scheduled increase as a surprise.
A current example, and a reminder that the date matters more than the direction: Anthropic launched Claude Sonnet 5 on June 30, 2026 with introductory pricing of $2 per million input tokens and $10 per million output tokens through August 31, 2026, and published a standard price of $3 and $15 to follow on September 1 — a 50% increase on both sides for the same uncached token volume. Then, on August 10, 2026, Anthropic made the introductory price permanent and cancelled the increase. Sonnet 5 still bills at $2 and $10 (source: Anthropic announcement, current pricing page, verified Sep 9 2026).
That outcome does not weaken the practice — it is the argument for it. A team that had budgeted at the announced list price simply kept the surplus. A team that had budgeted at the intro price was, for six weeks, one announcement away from a 50% cost increase and had no way to know which way it would go. The published date is the dependency, not the direction it moves.
Suppose one request uses 20,000 input tokens and 4,000 output tokens. At Sonnet 5's price, it costs $0.08: $0.04 for input plus $0.04 for output. At the $3/$15 rate that was scheduled for September 1, the same request would have cost $0.12. At 100,000 requests, that is the difference between an $8,000 plan and a $12,000 bill — before traffic growth, retries, caching, batch discounts, or regional pricing. The increase was cancelled, so the exposure never materialised. It was still real while the date stood.
One published expiry date is enough to justify the practice: treat the onboarding price as a versioned dependency, not a timeless constant. Preview access can also change, promotional windows close, and usage-based billing can be restructured.
What the Trap Looks Like
The failure mode is rarely "we forgot prices change." It is a chain of small, reasonable decisions:
A team prototypes a feature on the intro price and the demo economics look great. The business case gets approved with a cost-per-user figure based on that price. The feature ships, adoption grows, and the monthly bill becomes a line item someone glances at. Then the promo window closes, the bill jumps by half, and the feature that was margin-positive is suddenly margin-negative — with no code change, no traffic change, and no one clearly responsible for noticing.
A scheduled price increase is the most predictable incident you will ever face. It has a published date, a published magnitude, and an official announcement. The only way to be surprised by it is to not write it down.
Four Guardrails
Build the cost-per-request and cost-per-user math on the post-promo price. If the feature only works at the intro price, you do not have a feature — you have a countdown. The intro window then becomes pure upside: a few months of lower bills you can report as savings, instead of a baseline you silently depend on.
Wherever you record which model a feature uses — a config file, a decision log, an internal wiki — add two fields: the price you are budgeting at, and the date that price changes or should be re-verified. Put the expiry date in the team calendar with an owner, exactly like a certificate renewal.
Monthly spend alerts confuse growth with price changes: a rising bill might be good news (more users) or bad news (worse unit economics). Track cost per request or per active user. That number should be boring and flat — when it moves without a deploy, either a price changed or usage patterns drifted, and both deserve a look the same week, not at the end of the quarter.
Before the price change lands, answer one question: at list price, does this workload stay on the same model, move to a cheaper one, or get its token usage cut? Run the comparison while there is no pressure — test the cheaper model against your evals now, so the decision on price-change day is executing a plan, not starting an investigation.
Copy-Paste Prompt: Price-Change Review
"List every place in this codebase where an AI model is selected or its cost is assumed: model IDs in config, hardcoded model strings, budget constants, and cost calculations in docs or comments. For each, report: the model, the price assumption if visible, and whether a cheaper model could serve that call path. Output as a table so I can attach price-verification dates and owners."
Run this once when you adopt a model on promotional pricing, and again a couple of weeks before the promo ends. The output is your worklist for guardrails 2 and 4.
Conclusion
Intro pricing can be a genuinely good deal because it lowers the cost of evaluation and early production use. Take the discount. Just refuse to let it become your architecture's baseline: budget at list price, calendar the expiry, watch unit cost, and have the downgrade decision made before the date arrives. The teams that get hurt by promotional pricing are not the ones who used it, but the ones who built on it.
Official Sources and Review Trigger
- Anthropic: Claude Sonnet 5 announcement — the launch date, the introductory rates, the August 31 2026 end date, and the August 10 2026 edit stating that the increase to $3/$15 no longer applies. Checked Sep 9 2026.
- Anthropic: Claude API pricing — the rates in force, and the note confirming that the September 1 2026 increase will not occur. Checked Sep 9 2026.
Review this page again by Sep 23 2026, or immediately if Anthropic changes Sonnet 5's price or announces a new model on promotional terms. The worked example is deliberately tied to one model and one published expiry date; if that example is replaced, the arithmetic must be recalculated rather than adapted.
Pair this with AI Cost Modeling: Tokens, Model Selection, and Budget Control, Run a Model Fallback Drill Before You Need One, When Your AI Model Gets Pulled, and The True Cost of Context.