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: 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. On September 1 the price becomes $3 and $15 — a 50% increase on both sides for the same uncached token volume (source: Anthropic announcement, verified Jul 10 2026).
Suppose one request uses 20,000 input tokens and 4,000 output tokens. At Sonnet 5's intro price, it costs $0.08: $0.04 for input plus $0.04 for output. At list price, the same request costs $0.12. At 100,000 requests, that is an $8,000 plan turning into a $12,000 bill — before traffic growth, retries, caching, batch discounts, or regional pricing.
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.
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.