What an API migration really costs
A price per million tokens is where the calculation starts. A migration also depends on prompt size, answer length, cache hits, retries and integration work. Build an estimate with adjustable assumptions rather than a universal savings percentage.
Make the assumptions visible
Assume one thousand input tokens and five hundred output tokens per request, no cache, no retries and off-peak rates. These are illustrative scenarios, not usage measured by this blog. For Flash, we use $0.15 per million uncached input tokens and $0.60 per million output tokens, checked against the official pricing page on November 3, 2026.
The formula is uncached_input × input_rate / 1,000,000 + output × output_rate / 1,000,000. Amounts are in US dollars and cover model consumption only. They exclude tax, currency conversion, web search, databases, networking and external tools. Keep those exclusions visible when moving from this example to an actual budget.
Three volumes, one workload
| Requests | Input tokens | Output tokens | Estimated usage cost |
|---|---|---|---|
| 10,000 | 10 million | 5 million | $4.50 |
| 100,000 | 100 million | 50 million | $45.00 |
| 1,000,000 | 1 billion | 500 million | $450.00 |
At the official peak rates checked on the same date, these amounts double for the same token quantities. Traffic timing is therefore an input to the estimate. A service used interactively cannot move every request to a cheaper window; a batch-processing system may genuinely have that option.
Output length is often the fragile assumption. If the new model produces answers twice as long, reusing the previous token count understates spend. Measure the complete payload and the usage fields actually billed, including differences associated with reasoning. Similar-looking answers can still have different accounting.
Compare the right GPT model
“GPT” is not a price list. Specify the exact model, API channel, any batch discounts and the proportion of input already cached. Use the project’s contract or dashboard rates from the same date. A chat subscription is not an equivalent unit cost for API traffic.
Percentage savings are 1 − new_cost / current_cost, compared at the same number of accepted tasks. If current cost is unknown, leave it as a parameter. A result explicitly conditional on an assumption is more useful than a comparison made impressive by choosing the most expensive possible alternative.
Count the failed work
Suppose some tasks need a second attempt. Adding that percentage to the nominal price is insufficient when failed answers consume different token quantities or the fallback uses another model. For each route, count requests, input, output and the observed probability of success.
Cost per useful result is total spend divided by accepted outputs. If people review the work, include their time too. A few minutes of correction can outweigh thousands of tokens. The migration should reduce the cost of completed work while preserving the required quality, not merely reduce the price printed next to the model name.
Include the switching cost
Separate recurring spend from the initial investment. The latter includes parameter changes, error handling, tool checks, prompts, observability and traffic evaluation. A compatible SDK reduces some integration work, but does not establish that structured outputs or tool calls behave the same way.
The break-even period is initial_cost / monthly_savings, provided monthly savings are positive. For example, a hypothetical $300 investment and hypothetical savings of $50 per month pay back in six months. These are demonstration figures. Replace them with actual engineering hours and costs before using the calculation to choose a migration date.
Move a small share first
Keep a representative request sample and compare outputs outside the main production path. Once the rubrics pass, route a limited share of traffic to the new model with a simple rollback. Track cost per task, errors, latency and manual intervention in the same view.
A migration becomes economical when the savings survive these measurements, not when the unit price looks low. Keep the model adjustable: volumes, answer lengths, caching and routing change with the product. Preserving the assumptions makes the calculation reproducible after a pricing change, instead of leaving a one-off headline that nobody can update.
Sources & verification
Sources checked on November 3, 2026. Prices and availability can change.
- DeepSeek — Models & Pricing, accessed November 3, 2026
- DeepSeek — Token & Token Usage
- DeepSeek — Context Caching
Analysis and calculations by Deepweight. Provider information is attributed; measurements require a method, a sample and logs. Read our editorial method.