Migration Cost Estimator
What moving to a different model costs once re-embedding, dual-running two indexes, repeated eval runs and prompt rewriting are all counted — and how long the saving takes to repay it.
Repaid in 13.9 months at the saving you entered. Engineering time is 95.8% of it.
- Re-embedding the corpus
- $2.40
- Dual indexes for 2 month(s)
- $300.00
- Eval tokens — input
- 7.20M
- Eval tokens — output
- 1.80M
- Evaluation, 12 full run(s)
- $48.60
- Engineering, 80 h × $100.00
- $8,000
- Total one-off
- $8,351
- Engineering share of it
- 95.8%
- Monthly change after the move
- $600.00
- Payback
- 13.9 months
The cheap part is the tokens
Every migration estimate that comes in low made the same mistake: it costed the re-embedding and stopped. Re-embedding a corpus is a predictable multiplication and it is usually the smallest term on this page. The expensive parts are the ones denominated in hours — prompts that were tuned against the old model’s quirks and do not port, output parsers that break on a slightly different JSON habit, and the fortnight of watching production afterwards to find out what changed that nobody tested for.
The evaluation line is the one people find surprising once it is written down. A full suite is not run once; it is run after every fix, and each run bills the whole set at both rates. Twelve runs of a five-hundred-case suite is an ordinary migration, not a bad one.
Reading the payback
If the payback is short, the decision is easy and the risk is operational rather than financial. If it runs past a year, be honest that the migration is being done for a reason other than cost — quality, a deprecation notice, a data-residency requirement — and justify it on that. Cost paybacks in this field are also perishable: prices move downward often enough that a migration justified purely on rate arbitrage can be overtaken by a price change on the model you were leaving. Deprecation deadlines do not move, and they are the reason most migrations actually happen.