If you only need the short version: xAI published a migration notice on May 6, 2026 saying that eight older Grok API models will be retired on May 15, 2026 at 12:00 p.m. PT. After that time, requests to those model IDs will stop working. For developers, this is a real production change, not a branding update. If your app still points at grok-3, grok-code-fast-1, grok-4-fast-reasoning, or other listed models, you need to switch them now.
The larger story is not only that xAI is deprecating older models. It is that model lifecycle management is becoming a bigger operational issue across AI platforms. Teams can no longer treat model names as static infrastructure.
What happened
xAI published an official documentation page titled Grok Model Retirement on May 15, 2026 and marked it last updated on May 6, 2026. According to the notice, the following models will be retired from the xAI API on May 15, 2026 at 12:00 p.m. PT:
grok-4-1-fast-reasoninggrok-4-1-fast-non-reasoninggrok-4-fast-reasoninggrok-4-fast-non-reasoninggrok-4-0709grok-code-fast-1grok-3grok-imagine-image-pro
xAI says requests to these models will no longer work after the cutoff.
The same notice includes recommended replacements:
- reasoning workloads: move to
grok-4.3 - non-reasoning workloads: move to
grok-4.20-non-reasoning - code workloads: move to
grok-4.3 - image generation: move from
grok-imagine-image-protogrok-imagine-image
For teams already running the xAI API in production, that is the actionable part of the announcement.
Background: why this is more important than it looks
Model retirement posts rarely get the same attention as new model launches, but they often matter more to developers. A launch gives you an option. A retirement creates a deadline.
In practice, these notices affect:
- production uptime
- fallback routing
- eval baselines
- prompt consistency
- pricing assumptions
- product messaging
That is why this topic matters even though xAI is not announcing a new flagship model here. The company is compressing its supported lineup and pushing users toward newer defaults.
This is also a sign of how foundation-model platforms are maturing. Vendors want fewer legacy branches, fewer ambiguous model choices, and more usage concentrated on current releases.
Which Grok models are being retired
The retired list spans multiple workload types.
Reasoning models
xAI says these reasoning-oriented models are retiring:
grok-4-1-fast-reasoninggrok-4-fast-reasoninggrok-4-0709
The recommended replacement is grok-4.3.
According to xAI's migration notice, grok-4.3 includes:
- a 1 million token context window
- three reasoning effort levels:
low,medium, andhigh - pricing of $1.25 per 1 million input tokens and $2.50 per 1 million output tokens
That tells developers xAI wants a single newer model to cover several older reasoning and coding use cases.
Non-reasoning models
xAI says these faster non-reasoning models are retiring:
grok-4-1-fast-non-reasoninggrok-4-fast-non-reasoning
The recommended replacement is grok-4.20-non-reasoning.
xAI also notes that teams with lower latency sensitivity can consider grok-4.3 with reasoning_effort set to low.
That is a useful migration detail because it suggests xAI is narrowing the gap between dedicated fast variants and configurable reasoning modes in its newer stack.
Coding and image models
Two older specialist models are also being retired:
grok-code-fast-1grok-imagine-image-pro
xAI recommends:
grok-4.3for code workloadsgrok-imagine-imagefor image generation
This matters because the retirement is not limited to one product lane. It affects text, coding, and image-generation users.
Why this matters for developers and AI product teams
1. This is a hard migration deadline
The biggest point is simple: after May 15, 2026 at 12:00 p.m. PT, the listed model IDs stop working. This is not a soft deprecation label. It is a removal notice.
Any team using xAI through:
- direct API calls
- SDK wrappers
- internal routing layers
- workflow automations
- no-code integrations
should check their configured model names before the deadline.
2. Model IDs are now operational dependencies
Many teams still treat model selection as a product-level preference. In reality, the exact model string is an infrastructure dependency. It can affect:
- cost
- latency
- output style
- reasoning behavior
- context limits
- tool-calling quality
When a vendor retires older IDs, every one of those assumptions may need revalidation.
3. Migration is not only a search-and-replace job
xAI says that in most cases moving to newer models is as simple as changing the model field. That may be true for request syntax, but it does not remove evaluation work.
Teams should still test:
- prompt behavior under the new model
- tool-calling reliability
- structured output stability
- response length and style
- latency under production load
- downstream guardrails and classifiers
The safest migration pattern is switch, test, compare, then promote.
Why this matters for the broader AI model market
This update is also a good example of a 2026 trend: vendors are shortening the practical life of older model names.
That creates a few broader implications:
- platform buyers need stronger model-governance processes
- developers need better observability around model usage
- product teams need clearer customer communication about backend changes
- unified AI gateways become more useful when providers change lineups quickly
In other words, model access is becoming more dynamic. The operational question is no longer just "Which model should we use?" It is also "How do we stay ready when that model changes or disappears?"
What this means for WisGate readers
For WisGate readers, the relevant lesson is not that xAI retirement notices are unique. It is that multi-model teams need a cleaner way to handle provider churn.
WisGate's public position is All The Best LLMs. Unbeatable Value. If you evaluate providers through a unified layer such as WisGate, stories like this highlight a practical checklist:
- which provider model IDs are stable
- how quickly deprecations are surfaced
- whether fallback routing is easy to update
- how much retesting is needed after a model swap
- whether pricing and capability changes are visible in one place
This kind of event makes model abstraction more valuable, but only if the abstraction stays honest. A gateway can reduce migration friction, yet teams still need to know exactly which underlying model powers production.
Useful WisGate context for that workflow:
- WisGate homepage
- OpenAI-compatible API overview
- Claude Opus 4.7 benchmarks article
- Hermes Agent guide
Practical migration checklist
If your team uses the xAI API, the safest next steps are:
- Search your codebase, config files, and workflow tools for every retired model ID.
- Map each retired model to xAI's recommended replacement.
- Run prompt and output comparisons before changing production defaults.
- Recheck latency, cost, and structured-output behavior.
- Update internal documentation, dashboards, and customer-facing references.
- Set an alert for model deprecation notices going forward.
That checklist is not specific to xAI. It is becoming standard operating practice for any team building on foundation-model APIs.
Limitations and risks
xAI hints at more releases, but does not name them yet
The migration notice says xAI has "exciting model releases planned in the coming weeks." That is directional context, not a concrete product announcement. It should not be treated as confirmation of specific upcoming models or dates.
Replacement recommendations do not guarantee identical behavior
Even when a provider recommends a replacement, the newer model may behave differently on latency, style, reasoning depth, or tool use. Teams should expect some retuning work.
This is an API change, not a full market ranking
The retirement notice is important for developers already using xAI. It does not by itself prove that xAI's replacements are better than every competing model for every workload.
Bottom line
xAI's May 6, 2026 migration notice matters because it sets a real shutdown date for older Grok API models. The immediate action is straightforward: if your systems still call one of the retired model IDs, switch before May 15, 2026 at 12:00 p.m. PT.
The deeper signal is broader. In 2026, model operations increasingly include retirement tracking, migration testing, and provider-change management. Teams that treat model names as stable infrastructure will keep getting surprised.
FAQ
What did xAI announce on May 6, 2026?
xAI published a migration notice saying eight Grok API models will be retired on May 15, 2026 at 12:00 p.m. PT and provided recommended replacement models for each workload type.
Which Grok models are being retired?
xAI says it is retiring grok-4-1-fast-reasoning, grok-4-1-fast-non-reasoning, grok-4-fast-reasoning, grok-4-fast-non-reasoning, grok-4-0709, grok-code-fast-1, grok-3, and grok-imagine-image-pro.
What should developers migrate to?
xAI recommends grok-4.3 for reasoning and code workloads, grok-4.20-non-reasoning for fast non-reasoning workloads, and grok-imagine-image for image-generation use cases.
Will requests to the old models still work after May 15, 2026?
No. xAI says requests to the retired model IDs will no longer work after May 15, 2026 at 12:00 p.m. PT.
Why does this matter beyond xAI users?
Because it shows how quickly model lineups can change. Any team building on foundation-model APIs needs a repeatable process for deprecations, migrations, and re-evaluation.