xAI is pulling the plug on a batch of Grok models on May 15, 2026, according to a deprecation notice posted in the company’s developer docs. After that date, applications still pointing to the retired endpoints will stop working, and xAI is telling builders to migrate to the current Grok lineup before the cutoff.
This is the kind of housekeeping move that’s easy to ignore until your production app breaks. If you’ve shipped anything against the Grok API, this notice deserves a calendar block this week, not in May.
What’s happening
xAI publishes deprecation timelines in its docs as part of normal model lifecycle management. The pattern is familiar from OpenAI, Anthropic, and Google: roll out newer models, give developers a heads-up window, then turn off the older endpoints to stop maintaining duplicate infrastructure.
For xAI, this is one of the first big sweeps since Grok started competing seriously in the developer API space. The company has been pushing Grok hard as a frontier option alongside the consumer-facing version inside X.
Why this matters
Deprecations look boring until they bite. A few things to flag:
- Hardcoded model strings break silently. If your code references a deprecated model name in a config file or environment variable, requests will start failing the moment the cutoff lands. No graceful degradation.
- Behavior shifts on migration. Newer Grok models won’t respond identically to the older ones. Prompts tuned for a deprecated model can produce different outputs, especially on edge cases. Eval suites need a rerun.
- Cost structures change. Pricing tiers shift between model generations. Teams that built financial models on old per-token rates should recalculate.
- Fine-tuned weights and cached prompts may not carry over. If you’ve invested in customization on a deprecated base model, check whether the work transfers cleanly.
The industry-wide pattern here is worth naming. Frontier labs are settling into roughly 12-to-18-month deprecation cycles for older models. That’s tighter than most enterprise software lifecycles, and it puts pressure on teams that treat LLM choice as a one-time decision rather than an ongoing one.
What practitioners should do now
A short checklist if you’re running anything on Grok:
- Audit your codebase for Grok model identifiers. Grep for the deprecated model names listed in xAI’s docs. Centralize them into a single config variable if they aren’t already.
- Spin up a parallel test environment pointing to the current Grok models. Run your eval suite against both. Document any behavior drift.
- Update prompts where needed. Newer models often handle instruction-following differently. What worked verbatim on Grok-2 may need light tuning on Grok-3 or whatever’s current.
- Re-baseline costs. Pull the new pricing and rerun your unit economics.
- Set a migration deadline well before May 15. Aim to finish by mid-April. That gives you a buffer if anything surfaces in the last mile.
The bigger picture
xAI is signaling that Grok is being treated as a real production API, not a research toy. Production APIs ship with deprecation policies. They have to. The flip side is that developers building on any frontier model now need to budget for migration work as a recurring cost, not a surprise.
This is also a moment where multi-model architectures start paying off. Teams using a routing layer or abstraction (LiteLLM, OpenRouter, or a homegrown wrapper) can swap underlying providers with a config change. Teams that hardcoded Grok directly into business logic are about to learn an expensive lesson.
Expect more notices like this from every frontier lab through 2026. The cadence is accelerating, not slowing down.
Full deprecation list and migration guidance live in the xAI developer docs at the original source.