Open a controlled change at the first verified notice
At 09:00 UTC, capture the provider's official notice or pricing page with retrieval time, affected model IDs, effective time, billing unit, and old and new input and output rates. A social post or third-party calculator can alert the team, but it is not the configuration source.
Identify every local rate table and report that uses the model. Record version, owner, currency, and whether the value drives monitoring, an approval threshold, or an enforced rule. The same stale number has different consequences in a dashboard and in an automated decision.
Bound the 150-minute gap
If configuration changes at 11:30 UTC, export usage from 09:00 through 11:30 by model and separate input, cached input where applicable, and output units. Multiply each quantity by the difference between old and new verified rates. This is the maximum known estimate correction before billing adjustments.
Do not back-edit raw historical estimates. Preserve what operators saw at the time and add a corrected view with rate version and reason. Auditability requires both the original decision signal and the later reconciliation.
| Control-log event | Required value | Evidence |
|---|---|---|
| Notice received | 09:00 UTC | official provider URL and capture |
| Effective time | provider-stated time | pricing notice |
| Old/new input rate | enter verified rates | versioned configuration |
| Old/new output rate | enter verified rates | versioned configuration |
| Local update | 11:30 UTC | deploy/change record |
| Gap usage | units by model and type | provider/local exports |
| Invoice variance | final amount | month-end bridge |
Limit decisions only where the gap is material
Estimate the worst credible dollar difference over the time until update. If it cannot change an approval or breach a budget tolerance, keep monitoring and update normally. If it can, pause only estimate-dependent automation for the affected model while deterministic request or token ceilings remain in place.
Avoid disabling customer AI because a display rate is stale. The operational risk is incorrect cost interpretation, not necessarily higher traffic or a broken request path. State which controls remain reliable during the gap.
Update one source and test every consumer
Change the canonical verified rate source once, increment its version, and propagate it through supported consumers. Test input-only, output-heavy, cached-input, and zero-usage examples where applicable. Confirm rounding and billing units rather than comparing only one familiar request.
Have a second person verify the model identifier and rate direction. A correct rate assigned to the wrong model can create a larger silent error than the original lag. Record the review and rollback value.
Reconcile after the invoice arrives
Compare corrected gap estimates with the provider invoice and assign differences to actual usage, discounts, credits, tax, rounding, or unresolved items. Use the invoice as authority for payment while retaining the control log to evaluate how the monitoring performed.
Close when every affected model has a verified version, consumers pass tests, the 150-minute window is quantified, and invoice variance is explained. The product pricing page is a next step for plan costs; provider model rates must continue to come from the provider's official source.
Use the rate-change control log from “A model price changed before the rate table: contain the estimate gap” on a real first installation. Download AI Cost Circuit Breaker for free, begin in Monitoring, and move to enforcement only after the expected signals and rollback are verified.