My team's AI policy was written when frontier releases landed roughly every 37 days. They now land about every 11 days. Our procurement process approves models one at a time, with a quarterly review — which means every evaluation we finish is already two releases out of date.
That is model fatigue, and it is structural. The median gap between frontier releases fell from 37.5 days in 2023 to about 11 days in 2026. GPT-6 Astra shipped September 3, 2026 as the first model classified at the Critical cybersecurity capability level. Anthropic shipped Opus 5.5 and Sonnet 5.5; Google shipped Gemini 3.8 Flash on September 2, 2026. A procurement process built around approving models one at a time cannot operate at this tempo — it was designed for a world where you had months to think between releases.
Re-evaluate on a cadence, not per release¶
Stop approving models individually. Instead, run a fixed evaluation pipeline — your task suite plus a regression set — against every new model you might use, on a fixed cadence. The pipeline is the approval: a model that passes the suite with acceptable regressions is cleared; one that does not is not. Quarterly reviews of individual models become obsolete; the standing pipeline handles the churn, and your team reviews the pipeline's results rather than re-litigating each release.
Put cost gates on each model version¶
Every model version gets per-plan spend ceilings that fail closed. New models degrade in surprising ways — different token usage, longer retries, worse tool-call efficiency — and a degraded model that costs three times more than the one it replaced can burn through your budget while you are still diagnosing the regression. The cost gate bounds the damage: the model gets its envelope, and when the envelope is exhausted, it stops. No envelope, no deployment.
The open-weights vs. API checklist¶
When release cycles run at 11 days, switching costs and version drift dominate the decision. Build a checklist for the trade-off: decide explicitly which layer you pin (weights you control and can hold constant) versus which layer you rent (API models that will keep changing under you). Pinned layers give you stability and reproducible behavior; rented layers give you the frontier at the cost of constant churn. The wrong answer is not choosing either — it is drifting between them without deciding.
Rollback criteria in writing, before you switch¶
Define the metric thresholds that trigger an automatic rollback to the pinned version, in writing, before you switch models. Accuracy floors, cost ceilings, latency budgets — whatever your regression suite measures. And document who can switch models with the same rigor you document who can ship code. Model releases are infrastructure changes now; they deserve the same change control as a database migration, not the casualness of a config tweak.
The takeaway¶
A living procurement policy runs on cadence, not on approvals: a standing evaluation pipeline, per-version cost gates, an explicit pin-vs-rent decision, and written rollback criteria. The release storm is not slowing down — the median gap is 11 days and shrinking. Build the pipeline once, and let it absorb the churn. The copy-paste templates for spend ceilings, grant records, and audit rows are in the free playbook linked from the site.