The Magic of AI

Model switch savings calculator

Switching models is the cheapest cost lever available, and the one teams put off longest because the migration feels risky. Quantifying the prize first makes the decision easier: if moving down one tier saves four figures a month, the evaluation work is obviously worth doing, and if it saves forty dollars it obviously is not.

Model switch savings calculator

Re-testing prompts, re-running evals, staged rollout.
Updates as you type. Nothing you enter leaves your browser.

A workload of 250,000 requests a month at 4,000 input and 800 output tokens costs $11,000 a month on GPT-5.6 Sol. The identical workload on GPT-5.6 Luna costs $440. That is not a typo and it is not an exotic comparison — it is two tiers of the same family from the same vendor, reached by changing one string in a config file.

Whether you should change that string is a question about evals, not about price. But you cannot sensibly decide how much evaluation effort to spend until you know what is at stake, and that is what this calculator is for.

The arithmetic behind the table

Every row uses the same two multiplications. Input tokens per request divided by a million, times the input rate; output tokens divided by a million, times the output rate; add them and multiply by monthly volume.

On GPT-5.6 Sol at $5.00 input and $30.00 output: 4,000 ÷ 1,000,000 × $5.00 = $0.020, plus 800 ÷ 1,000,000 × $30.00 = $0.024, giving $0.044 a request and $11,000 a month.

The same workload elsewhere in the index:

Move to $/request Monthly Saving/year Payback on $8,000
GPT-5.6 Terra ($2.00/$12.00) $0.0176 $4,400 $79,200 1.2 months
Claude Haiku 4.5 ($1.00/$5.00) $0.0080 $2,000 $108,000 0.9 months
GPT-5.6 Luna ($0.20/$1.20) $0.00176 $440 $126,720 0.8 months
DeepSeek V4 Flash ($0.14/$0.28) $0.000784 $196 $129,648 0.7 months
Gemini 2.5 Flash-Lite ($0.10/$0.40) $0.00072 $180 $129,840 0.7 months

Notice how flat the bottom of that table is. Between Luna at $440 and Gemini 2.5 Flash-Lite at $180, the annual difference is $3,120 — about a day and a half of engineering time. Once you have dropped a tier, choosing between the budget options on price is close to pointless; choose on eval results and take the $3,120 as noise. The money is entirely in the first move.

Note also that output rates drive the ranking. Output is 55% of the Sol bill here despite being a fifth of the tokens, because $30.00 against $5.00 is a six-fold premium. Workloads that write long — summaries, drafts, code — gain far more from switching than workloads that read long. If yours is input-heavy, check whether prompt caching beats migrating altogether.

What a migration actually costs

The default $8,000 is not a placeholder; it is roughly what a serious switch costs in a team that already has evals. Four things make it up.

Prompt re-tuning. Prompts are not portable. Instructions tuned against one model's quirks — how emphatically you must ask for JSON, whether it obeys negative instructions, how it handles a long system brief — do not transfer cleanly. Expect to rewrite the system prompt, re-tune few-shot examples, and adjust temperature and stop conditions. Two engineers for a week at a loaded $85 an hour is 75 hours and $6,375, which is most of the budget on its own.

Eval re-runs. The compute is trivial: a 500-case suite run ten times over on the origin model is 5,000 requests at $0.044, or $220. The cost is human grading of the cases where automated scoring cannot decide, and the calendar time it takes. If you do not have an eval suite, the migration cost is not $8,000 — it is the cost of building one, and you should do that regardless of whether you switch.

Staged rollout. Nobody sane cuts over 250,000 requests at once. Shadow the new model against 5% of live traffic, compare outputs, then ramp. Running both models on that slice for a fortnight adds about $275 of duplicated inference and a fortnight of watching.

Monitoring. New dashboards for refusal rate, format-validation failures, latency percentiles and escalation volume, plus alerts on each. This one is permanent overhead rather than a one-off, and it is the line most often forgotten.

Reading the payback column

Payback is the migration cost divided by the monthly saving: $8,000 ÷ $6,600 for the move to Terra is 1.2 months. Because the migration figure is a single field applied to every row, the payback column ranks in exactly the same order as the saving column. It is not telling you which model to pick. It is telling you the scale of the decision — whether you are looking at three weeks of payback or three years.

That distinction changes the conversation. A row that pays back in under two months is worth a fortnight of engineering time without further debate. A row that pays back in eighteen months should not be attempted at all, because the model landscape will have moved before you get there, and you will have spent the effort twice.

One correction to apply by hand: cross-provider moves cost more than cross-tier moves within a provider. Different SDK, different tokeniser (so your token counts shift by a few per cent), different tool-calling schema, different content filters that will refuse a small fraction of your traffic for reasons you have to discover empirically, different rate-limit behaviour under load. Sol to Luna is a config change. Sol to DeepSeek V4 Flash is a project. Set the migration field higher for the second sort of move and read the payback column again.

When cheaper costs more

Here is the calculation that should stop most migrations, and it is not in the tool because it depends on numbers only you have.

Suppose the move to GPT-5.6 Luna saves $10,560 a month, and suppose the cheaper model fails 5% more of your evals than Sol did. On 250,000 requests that is 12,500 additional failures. If a failure means a human spends four minutes checking and correcting the output, at a loaded $65 an hour that is $4.33 each, or $54,167 a month — five times the saving, on a workload that now also produces worse results.

Work out the break-even and it is brutal. $10,560 ÷ $4.33 is 2,437 requests, which is 0.97% of your volume. One extra failure per hundred requests wipes out a saving that looked like $126,720 a year. If failures reach customers rather than reviewers, the threshold is lower still, because the cost of the failure is not four minutes of somebody's time.

This is why price comparison is necessary and never sufficient. The right sequence is: use this table to find which alternatives are worth the effort of evaluating, run your own eval suite against the two or three that clear the bar, and let the pass rate pick the winner. If the gap in your evals is inside the noise, take the cheaper model and the $126,720.

Set the migration field to what your team would actually spend, then sort by annual saving and draw a line under every row that pays back in more than six months. Evaluate what remains. Choosing a model tier covers what to test, and the LLM API cost calculator prices the winner across your full traffic mix.


Prices used by this calculator were last verified on 15 August 2026 from the vendors' own pricing pages. See the full price index for every figure and its source, the change log for what has moved recently, and the methodology for how the index is maintained and where its limits are.