gpt-5.2-chat-latest and gpt-5.3-chat-latest shut down on August 10, 2026. That's six days from now. After that, they'll return errors.
If one of them sits behind your agent, that date isn't product news. It's a production incident with advance notice. Your code and your prompts can stay exactly the same, your infrastructure can be healthy, and your app can still break. AI teams underestimate this failure mode because nothing in their own stack changes.
We were optimizing the wrong decision
We used to believe the gateway should choose the best model for every prompt. So we built a router that classified requests by complexity and sent each one to a different model. The pitch made sense: cheaper models for easy work, expensive ones for hard work. We ended up deprecating it ourselves.
The prompt didn't contain enough information to predict the full task. Switching models made behavior less consistent. The savings introduced a new layer of uncertainty that teams then had to evaluate, observe, and maintain.
The uncomfortable lesson: choosing a model more often doesn't make an agent more reliable.
For most workloads, you should pick a model deliberately, learn its behavior, and keep it stable. The infrastructure around that model should focus on a different job: keeping your app alive when reality stops matching your assumptions.
A deprecation is a scheduled failure
Teams treat model deprecations like changelog housekeeping, when they behave like expiring certificates. The provider announces a date, the endpoint keeps working for months, nothing feels urgent, so the migration stays in the backlog.
Then the date arrives and the model ID that worked yesterday returns a 404. Your agent can't reason its way around a dependency that no longer answers, and it can't even explain the failure to your user if the retired model was supposed to write that explanation.
Reliability starts before the request.
A retry covers a transient timeout, a fallback covers a provider outage. Neither one tells you that your primary model has a published shutdown date. You need the warning while you still have time to test the replacement.
Your agent should know what is disappearing
We built modeldeprecations.dev for that reason. It's an open-source catalog of AI model lifecycles. For each model, it answers the questions that matter operationally:
- Is this model active, deprecated, or retired?
- Has the provider published a shutdown date?
- What replacement does the provider recommend?
- When was this information last checked?
Every date links back to a source. If a date can't be verified, the catalog leaves it blank instead of guessing.
The useful part isn't just the website. The data is available as JSON and Markdown. There is a calendar feed, a changelog feed, status badges, and agent-readable files. An agent can check its own dependency before starting a long workflow. A CI job can flag a model that is already deprecated. A team can subscribe to shutdown dates instead of relying on someone to remember a provider announcement.
It's a small piece of infrastructure, and that's deliberate. Reliability comes from boring checks you run before they become urgent.
Detection is not recovery
Knowing a model will disappear buys you time, not uptime. You still need a recovery plan. Start with the boring version:
- Pin the model you have actually tested.
- Track its lifecycle outside the provider dashboard.
- Choose a replacement before the shutdown date.
- Run your real evals against that replacement.
- Configure a fallback for failures you can't predict.
- Keep the request and error history you'll need when behavior changes.
The distinction is intent: your primary model is a product decision, your fallback is an availability decision. Teams that confuse the two end up with agents whose behavior drifts on every request.
A gateway shouldn't improvise your primary model on every request. Its job is to stop one provider error, broken request, or retired dependency from taking down the whole agent.
Reliability is the product
Your users don't care that a provider changed a model ID or rejected a parameter. They care that the app worked.
Manifest is built around that idea. It puts one OpenAI-compatible endpoint in front of your providers: it records full request and error bodies, can fall back to another configured model when a query fails, and can repair supported request-side errors before they reach your user. The goal isn't to make model choice more mysterious, it's to make failure less visible to your users.
Models will keep changing: some will route internally, some will vanish, and old assumptions will expire with them. Your agent should survive all of that.
Check the model your agent depends on at modeldeprecations.dev, and make sure its retirement date isn't also your app's.
Top comments (0)