Model Switch Calculator

How the calculation works

The move consists of two quantities. A one-off one — re-testing prompts on the new model. And a recurring one — the token price difference that comes back every month.

The one-off part starts with hours. The baseline is four hours per prompt: reread the instruction, run the examples, adjust the wording, check the edge cases. Measuring it is not hard. Start a stopwatch on three or four scenarios and multiply the average by the number of prompts in production.

Sign-off depth multiplies the baseline. A spot check on a dozen examples carries a coefficient of 1, a custom suite of checks with expected answers — 1.8, manual labelling of output — 3. The spread reflects the effort of the procedure itself: labelling requires an expert and several rounds of fixes between runs.

Tokens are added on top of the hours. The test set is run in full, and that is separate money — 6% of the monthly bill in this calculation, multiplied by sign-off depth. A third line appears when the parallel run is switched on: while both models answer the same stream, both are billed.

The recurring part is more straightforward. The monthly bill is multiplied by the share the new price list removes, and weekly savings come from dividing by 4.33. The one-off investment is divided by that figure — which gives the timeline in weeks.

What moves the result the most

Bill size. It appears in both parts of the formula, but savings grow with it linearly while engineer hours do not get cheaper. So at a bill of 40,000 RUB payback stretches out over a year, while at 600,000 RUB the same volume of work pays back in a month.

The number of prompts in production is the second strongest quantity. Every added scenario costs a fixed number of hours and adds nothing to the savings. A setup with forty prompts takes three times longer to move than one with twelve at the same bill.

Sign-off depth changes the outcome threefold between the extreme options. The choice here is dictated by the cost of an error: where the model's answer reaches the customer without human review, manual labelling pays for itself on its own.

The parallel run usually turns out to be the most noticeable line at large bills. A month of double billing at 400,000 RUB adds an amount to the move comparable to all the engineer hours.

When the move pays off quickly

A test set exists. Fifty real requests with expected answers turn re-testing from an argument about taste into a measurable procedure. Assembled once, the set works for every model switch that follows — and those happen regularly.

The prompt base is kept in one place. When instructions live in configuration and are versioned, changing the model is a parameter edit and a run of the checks. When prompts are hardwired into code in a dozen places, hours of searching get added to the sign-off hours.

A price difference of half or more. A third also works, but at that level the payback period is noticeably sensitive to how accurately the hours are estimated — and it makes sense to combine the move with other work on the same prompts.

The bill is growing. If traffic increases month over month, weekly savings over the distance will exceed the calculated figure, and the real timeline will come out shorter than the calculator shows.

How to refine the numbers

The coefficients in the calculation are average benchmarks, and two of them can be verified in a single evening. Hours per prompt are measured on a couple of mid-complexity scenarios. The share of the bill spent on a test run is obtained directly: run the set once and look at the line in the provider's billing.

The hourly rate is taken fully loaded. For an in-house employee that is salary plus taxes and contributions divided by 164 working hours; for a contractor it is the rate from the contract.

Then the numbers go into the fields above. The result reads as an order of magnitude: "about three weeks" or "about a quarter". Precision to the day is not needed here — the decision is made on scale, not on tenths.

What stays outside the brackets

Differences in output format. The new model may structure a response differently, call tools differently, hold a long context differently. Such discrepancies become visible after the first sample run, and the fixes then land in the wrapper code.

Provider limits and availability. Request-per-minute quotas, data processing regions and request retention terms are checked before the move — they are capable of cancelling the savings entirely.

Team onboarding. Where several people edit prompts, a short walkthrough is added to the move: what has changed in the model's behaviour and which techniques have stopped working. A day for the team is usually enough, and this line is not part of the calculation.