Can I use a cheaper model for every step of my app?

You can use a cheaper model for many steps, but not safely for all of them without testing. Steps that involve tool definitions, images, or complex multi-field extraction often require the model you originally chose. For plain text tasks like classification or summarization, a cheaper model frequently works just as well, but you need to verify this on real data before committing.

What happens when an AI model I hardcoded gets deprecated?

When a model reaches its shutdown date, API calls to that model ID start returning errors. OpenAI, Anthropic, and Google all publish deprecation timelines in advance, but if your model IDs are scattered across your codebase rather than in a single config file, updating them under pressure is error-prone. Several popular OpenAI models are scheduled to shut down on October 23, 2026, and the gpt-4o and gpt-4.1 families follow on January 14, 2027.

How do I know if a cheaper model is good enough for a specific step?

Test the cheaper model on a representative sample of real production inputs for that step, not just hand-crafted examples. Add automated format or quality checks so you can measure failure rates, and monitor those checks after the switch. Manual review of a random sample each week is also useful for catching subtle quality regressions that pass format validation.

How much can I actually save by routing to cheaper models per step?

Savings depend entirely on which steps you move and how much token volume they carry. As a concrete example, moving 500,000 output tokens per day from Claude Sonnet 5.5 at $10 per million tokens to Haiku 5.5 at $0.50 saves about $4.75 per day, roughly $142 per month. Higher-volume steps with clear quality equivalence produce proportionally larger savings.

Is hardcoding model IDs in code a bad practice?

Hardcoding model IDs as string literals scattered across call sites is a maintenance risk because every model retirement or price update requires hunting through the codebase. Keeping all model IDs in a single configuration file or environment variables gives you the same static assignment with much less work to update. That is the minimum best practice; per-request routing based on request characteristics is a more flexible but more complex alternative.

Hardcoding a Cheaper AI Model Per Step: What Goes Wrong

Yes, you can hardcode a specific cheaper model for each step of your app, and it will reduce your bill compared to using a flagship everywhere. The problems come later: models get retired on short notice, quality varies by task in ways you only discover in production, and a cheaper model that was right six months ago may no longer be the cheapest or the best fit today. The savings are real, but so is the maintenance cost.

Why Developers Hardcode Models Per Step

The impulse makes sense. You profile your app, notice that the summarization step uses Claude Opus 5.5 at $4.00 per million input tokens when Haiku 5.5 at $0.10 would probably do fine, and you swap the model string. You do the same for your classification step and your rewrite step. Monthly costs drop, and nothing breaks at first.

This is a reasonable starting point. The issues below are not reasons to avoid cheaper models. They are reasons to build some flexibility into how you pick them.

Problem 1: Quality Breaks in Task-Specific Ways

A cheaper model rarely fails uniformly. It tends to fail on the specific subtask you are using it for. A model that handles short classification prompts perfectly may produce poorly structured JSON on a multi-field extraction task, or lose coherence when the system prompt is long.

The usual discovery path is: swap model, run manual tests, looks good, ship, then find out two weeks later that 3% of outputs have malformed JSON because a real user sent a prompt slightly longer than anything in your test set.

Testing cheaper models on representative samples before committing the model string to code is the only way to catch this early. Automated format checks help too, since they catch structural failures even when you are not reading every output.

Problem 2: Model Retirements Happen on a Fixed Schedule

Every major provider deprecates models on a published timeline. When you hardcode a model ID, you are coupling your app to that model's support window.

The current retirement schedule from the vendor documentation (as of October 2026) includes several near-term shutdowns worth knowing:

Model	Shutdown date	Announced replacement
gpt-4o-2024-05-13	October 23, 2026	gpt-5.6-sol
gpt-4-turbo-2024-04-09	October 23, 2026	gpt-5.6-sol
o4-mini-2025-04-16	October 23, 2026	gpt-5.6-terra
o1-2024-12-17	October 23, 2026	gpt-5.6-sol
o3-mini-2025-01-31	October 23, 2026	gpt-5.6-sol
gpt-4o (2024-08-06, 2024-11-20)	January 14, 2027	gpt-6-luna
gpt-4o-mini-2024-07-18	January 14, 2027	gpt-6-luna
gpt-4.1-2025-04-14	January 14, 2027	gpt-6-luna
gpt-4.1-mini-2025-04-14	January 14, 2027	gpt-6-luna
gpt-5-2025-08-07	December 11, 2026	gpt-5.6-sol

On Anthropic's side, Claude Sonnet 4.5 is deprecated as of September 30, 2026, with a retirement date of November 30, 2026.

Each of these represents a hardcoded model string that will start returning errors on its shutdown date. If you have ten steps with hardcoded IDs and three of those models retire in the same quarter, you are doing three unplanned production changes at once.

The practical fix is to treat model IDs as configuration values, not string literals scattered through your codebase. At minimum, keep them in one place so you can update all steps in a single change. A linter that flags known-deprecated model IDs in pull requests can catch this before the code ships.

Problem 3: The Cheaper Model Changes Too

The model that was the best price-to-quality option for your classification step in April may not be the best one today. New models launch, prices drop, and the competitive landscape shifts.

A concrete example from current pricing: GPT-6 Luna is now $0.10 per million input tokens and $0.50 per million output tokens. GPT-5.6 Luna, which was the cost leader in the same family a generation earlier, is $0.20 input and $1.20 output. If you hardcoded gpt-5.6-luna as your "cheap option" and never revisited it, you are paying twice the input price and 2.4 times the output price of its successor.

The same pattern plays out across providers. Gemini 3.8 Flash is currently $0.75 input and $3.75 output per million tokens (through December 31, 2026), while its predecessor Gemini 3.6 Flash carries identical pricing. DeepSeek Flash costs $0.15 per million input tokens off-peak (cache miss), making it one of the cheapest capable options for latency-tolerant tasks. These numbers will shift again.

Hardcoding locks you into a snapshot of the market. A review every quarter, or whenever a major new model launches, is the minimum to stay near the efficient frontier.

Problem 4: You Have No Signal When Quality Degrades

When a model is hardcoded, the only signal that it is underperforming is usually a user complaint or a spike in error rates on your output validation. You do not know whether a cheaper model would have handled yesterday's traffic as well as the model you are actually running, because you never ran both.

This is the core measurement problem with static model assignments. You set the model once based on a batch of test prompts, then assume the distribution of real requests matches that test set forever. Production data rarely behaves that way. Seasonal topics, new user segments, edge cases in longer inputs: all of these can shift the distribution in ways that change which model is adequate.

Tracking cost and quality per step in production is what separates a model assignment that is holding up from one that is quietly degrading.

What Savings Actually Look Like (And What They Require)

To make the numbers concrete: if a summarization step processes 500,000 tokens of output per day and you move it from Claude Sonnet 5.5 ($10.00 per million output tokens) to Haiku 5.5 ($0.50 per million output tokens), the output savings are:

Sonnet 5.5: $10.00 per million × 0.5 million = $5.00 per day
Haiku 5.5: $0.50 per million × 0.5 million = $0.25 per day
Savings: $4.75 per day, roughly $142 per month

That is a real saving worth capturing. But it requires: verifying that Haiku 5.5 actually produces acceptable summaries for your data, monitoring quality after the switch, and being prepared to update the model string when Haiku 5.5 is eventually retired or superseded.

For steps that involve tool definitions or images, the routing decision is more constrained. Most providers only guarantee consistent tool-call behavior on specific models, and a cheaper model that handles plain text well may return malformed tool responses on complex schemas. Agent loops that use tool calls are particularly sensitive to this, since a single bad tool response can derail an entire multi-step workflow.

The Alternative: Routing With Evidence

Rather than committing to a cheaper model statically, some teams route per-request: send each call to the cheapest model likely to handle it well, based on the request's characteristics. This adds engineering complexity, but it avoids the "set it and forget it" failure mode.

One way to approach this without building the routing layer yourself is to use PromptUnit. You point your app's AI API base URL at it and add your PromptUnit key; your own provider key stays. Each request is checked, and if a cheaper model is just as good for that request, it uses that instead. The dashboard shows what each step of your app costs and what each model substitution saved, so you can see exactly where the savings are coming from.

For teams that want evidence before moving a whole step permanently, PromptUnit's optional side-by-side checks run cheaper models against a sample of real requests after the answer has already gone back to your app. A step only moves automatically when at least 20 judged checks show 9 in 10 cheaper answers as good as the original, and the cheaper model costs at least 10% less. That standard means you are not flying blind the way you are with a hardcoded swap.

A Practical Approach If You Are Hardcoding Today

If you are already hardcoding model IDs and want to reduce the risk:

Move all model IDs into a single configuration file or environment variables. Never scatter them across call sites.
Subscribe to deprecation announcements from every provider you use. OpenAI, Anthropic, and Google all maintain deprecation pages with shutdown dates.
Set a calendar reminder to review model assignments quarterly. Check whether a newer, cheaper model now exists in the same capability tier.
Add output validation for every step, not just the flagship ones. A cheaper model's failure mode is usually structural, and format checks catch it before it affects users.
Test on a slice of real production data, not just hand-crafted test cases. The distribution matters.

Hardcoding is not wrong. It is just a snapshot. The maintenance cost of keeping that snapshot accurate is the part that often gets underestimated.