Checklist: find retired AI model IDs before your customers do

When an AI model shuts down, you rarely notice it in a meeting. You notice it when a spreadsheet stops filling rows, a form no longer summarizes cases, or a customer waits because a small script still calls a model ID the vendor has retired.

A model ID is the name an app, integration, or automation sends to an AI vendor to choose a model, such as gemini-2.0-flash or grok-build-0.1. It sounds technical. In practice, it is an operations issue. If the ID changes without a test, owner, and fallback, a working workflow can turn into a quiet source of errors.

Gemini 2.0 Flash shut down on June 1

Google wrote in the Gemini API release notes on June 1, 2026 that gemini-2.0-flash, gemini-2.0-flash-001, gemini-2.0-flash-lite, and gemini-2.0-flash-lite-001 are now shut down. The deprecations page points Flash variants to gemini-3.5-flash and Flash-Lite variants to gemini-3.1-flash-lite.

On paper, the replacement looks simple. In real workflows, the old name may still be hiding in code, environment variables, Zapier or Make scenarios, notebooks, templates, proxy rules, test suites, dashboards, and old instructions sent to colleagues.

Source: Gemini API release notes and Gemini API deprecations

A model in a menu is not the same as an API contract

The same week, xAI's Composer 2.5 appeared in Grok Build. xAI says the model is available in Grok Build and can be selected from the /models menu for SuperGrok and X Premium+. That is useful for people working interactively in Grok Build.

But xAI's public developer model catalog, at the time checked, does not list Composer 2.5 as an API model ID. It lists models such as Grok 4.3 and grok-build-0.1, but not a documented composer-2.5 ID with pricing, context window, and API guarantee.

This is a different risk from the Gemini shutdown. It is not an old ID disappearing. It is a new name someone may be tempted to paste into an API or no-code workflow before the vendor has published the contract.

Source: xAI: Composer 2.5 and xAI developer models

Sometimes the answer changes, not only the model

The updated Mistral reasoning docs show a third trap. The earlier native reasoning models magistral-small-latest and magistral-medium-latest are deprecated. Mistral now points users to mistral-small-latest and mistral-medium-3-5 with the reasoning_effort parameter.

There is a detail here that can break a workflow even when the model still replies. With reasoning_effort="high", the response can arrive as chunks, including ThinkChunk and TextChunk. With reasoning_effort="none", the content can be a plain string. If your workflow expects only a text string and then forwards the answer into a ticketing system, report, or CRM field, the parser needs a test.

A parser is just the part of the workflow that reads the AI answer and extracts the right text, field, or JSON. It is often invisible until it fails.

Source: Mistral: Reasoning

Run a model-ID audit before you switch

The simple version: do not only look for the model where you think it lives. Look where it may have been copied.

• List every model string. Search for model names in code, .env files, no-code tools, spreadsheets, prompt libraries, internal guides, and old test examples.
• Write down who owns each workflow. A customer reply, weekly report, and internal research bot should not carry the same risk just because they use the same vendor.
• Separate aliases from fixed IDs. An alias that follows the latest version can be convenient. A fixed ID can be better when you need reproducible answers. Both need documentation.
• Test the replacement with real examples. Run at least ten saved inputs from the workflow. Check answer quality, tone, field format, cost, latency, and what happens when the answer is empty or unexpectedly long.
• Check the parser, not only the prompt. If the vendor changes response type, streaming events, or reasoning format, the integration after the model may be the part that breaks.
• Choose the fallback before the shutdown date. It may be another model, a manual queue, a paused workflow, or a clear message to the user. The fallback should not be invented while the customer is already waiting.
• Put the next check in the calendar. Model changes are no longer one-off projects. They belong in the same routine as other vendor and system changes.

A small register beats a lot of panic

For Hammer customers, the best first version is often boring: a document or spreadsheet with model ID, vendor, where the ID is used, owner, fallback, latest test date, and next known shutdown date. Not perfect. Just clear enough that someone can act.

This is also a good Tool Forge question. If AI is already embedded in forms, case handling, reports, or customer workflows, Hammer can help find the model strings, build a regression pack, and make the switch less dramatic. The point is not to chase every new model. The point is to avoid discovering old models through broken workflows.