A model-routing price needs an expiry date
Gemini 3.7 Flash’s launch rate has a scheduled step-up. Store the price period with the model route, and evaluate the workload across the dates the business will actually pay.
A router can keep choosing the correct model for an expired price. The code runs, the quality checks pass and the economic assumption quietly stops being true.
Google's Gemini 3.7 Flash launch lists introductory rates of $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026. Its footnote gives the subsequent rates: $1.50 and $7.50 from January 1, 2027.
The scheduled doubling is visible before a team starts its evaluation. I would put it into the routing and forecast data immediately rather than leave it as a note someone has to remember at year end.
That is not an objection to introductory pricing. A discount can make a useful experiment cheaper. It becomes a planning problem when the evaluation rate is treated as the permanent operating rate.
The price is a dated input
Consider a hypothetical document workflow being assessed in August for use throughout the following year. Its model choice looks attractive under the launch discount. The quality advantage may remain in January while the cost ranking changes.
A sound forecast uses the applicable rate in each period. It should not erase a real discount, and it should not extend that discount beyond its stated end. The business needs the cost of the work it plans to run, not the price of the week in which the comparison happened.
I would store the current rate, effective date, expiry date and announced replacement rate beside the model and billing mode. Keep input, output and any other relevant charge separate so the workload mix can be recomputed accurately.
The source of the price belongs there too. Public list rates, a negotiated contract and a temporary credit are different bases for a decision. A table that mixes them without labels can produce a misleading ranking even before anything expires.
The expiry is a reason to review the route, not an instruction to switch automatically. A more expensive model may still earn its place through better accepted outcomes or lower downstream correction cost.
Re-evaluate the decision, not just the token bill
My proposed check would replay representative workload measurements against the upcoming rates before the change takes effect. Include the actual input-output mix, retries, caching assumptions and human review burden that the application experiences.
If another route becomes preferable, validate its quality and operating constraints before moving traffic. If the original route remains the better choice, update the budget and record why. Either outcome is more useful than a surprise bill followed by a hurried downgrade.
A scheduled check also creates a natural moment to inspect changes beyond price. The model version, available features or task mix may have moved since the first evaluation. Keep those changes separate so the team can tell which one altered the decision.
I have not benchmarked this Gemini release against alternatives. Google's price schedule is enough to establish the timing issue; the best route remains a workload-specific measurement.
The small design change is to make time part of a price's identity. A number without a validity period is incomplete input to a decision intended to last longer than the launch window.
Store when a model price expires, forecast the rates that will actually apply and revalidate the route before the economics change.
