What Happens When an AI Model Is Retired? A Production Migration Checklist

On August 16, 2026, Groq shut down llama-3.1-8b-instant and llama-3.3-70b-versatile for free and developer-tier usage. Qlynk requests that still named those model IDs began returning HTTP 404 with model_not_found. The key was accepted and the API was reachable; the requested model simply no longer existed for that tier.

That distinction matters during diagnosis. Rotating a valid key, retrying the same request, or changing the user-facing error message cannot restore a retired model. The configured model ID has to change.

• Customer-facing chatQlynk moved the main response workload from llama-3.3-70b-versatile to openai/gpt-oss-120b, Groq’s recommended replacement for the retired 70B model.
• Lightweight workClassification and background tasks moved from llama-3.1-8b-instant to openai/gpt-oss-20b, the recommended replacement for that smaller model.
• ConfigurationModel IDs were centralized behind environment-aware configuration so a future migration does not require scattered source-code edits.
• CompatibilityReasoning controls are only sent to models that support them, preventing a nominally valid replacement from failing because its request schema differs.
• VerificationThe migration was tested with ordinary chat, streamed chat, and JSON-shaped responses before the agents were considered restored.

The visible chat endpoint is rarely the only dependency. Search the application, deployment variables, scheduled jobs, evaluation scripts, support tools, and fallback paths for the retired ID. A primary request can succeed while a classifier, title generator, moderation helper, or retry path still fails later.

Record the workload beside each reference: conversational generation, structured extraction, classification, embeddings, speech, or another capability. Replacements should be selected for the job and supported features, not by choosing one new model name for everything.

• Availability firstConfirm the exact model ID through the provider’s current model catalogue or API for the account and service tier you actually use.
• Capability fitCheck context size, structured outputs, tool use, streaming, reasoning options, language coverage, and any safety controls the workload depends on.
• Quality on your questionsRun the permanent evaluation set for factual support, completeness, boundaries, handoff, tone, and formatting. Generic benchmarks cannot represent an individual knowledge base.
• Rate limits and latencyTest realistic concurrency and token volume against the limits on your tier. A free model can be suitable for launch while still needing graceful handling for rate-limit responses.
• Fallback behaviorA fallback should be explicitly compatible and tested. Silently substituting any available model can change request semantics or answer behavior.

Send the smallest valid non-streaming request first, then exercise the exact production path. Verify stream events terminate correctly, structured responses parse, token limits behave as expected, and unsupported parameters are omitted. Log the provider request ID and error category without exposing secrets.

Treat a successful status code as the beginning of validation. Compare output against approved facts and expected behavior. A model migration can change Markdown style, verbosity, refusals, ordering, and how strongly the model follows formatting instructions even when the same prompt is used.

• Confirm the retirementRead the provider notice and deprecation history; capture the shutdown date, affected tiers, and official replacement IDs.
• Find all referencesSearch code, environment variables, jobs, tests, fallbacks, and operational documentation.
• Map workloadsChoose and document a replacement for each capability rather than each old model name.
• Check request compatibilityValidate supported parameters, reasoning controls, streaming, JSON output, tool calls, and token limits.
• Run regression casesTest normal questions, follow-ups, missing knowledge, boundaries, prompt injection, formatting, and human handoff.
• Deploy observablyMonitor status codes, model identifiers, latency, rate limits, empty streams, parse failures, and user-reported answer changes.
• Remove dead fallbacksA fallback pointing to another retired model creates a second failure, not resilience.

The outage was resolved by replacing retired dependencies, but testing also exposed a presentation difference: the new model produced richer Markdown than the previous rendering path displayed cleanly. Qlynk’s shared response renderer was updated so headings, lists, emphasis, links, tables, and code blocks remain readable across full-page and embedded chat.

Model migrations are therefore application releases, not string replacements. Provider availability, transport compatibility, answer quality, safety behavior, and final presentation all belong in the acceptance criteria.