Model Lifecycle

Anticipating model changes

Your production application depends on a specific model ID stored in its configuration. That ID isn’t permanent: new versions launch, old ones get deprecated, then removed. Teams that ignore this timeline discover the problem the day their requests start failing en masse—even though nothing changed in their deployments. Understanding the lifecycle turns this outage into a planned migration.

The three states of a model

An active model is fully operational and the only state you should use in production. xAI can apply minor optimizations without changing the ID: the model you call by this name today isn’t necessarily byte-for-byte identical to the one from three months ago—a nuance the next lesson will address practically.

Moving to deprecated status doesn’t break anything. The model continues to respond normally, but xAI announces its future removal. This is the signal you’ve been waiting for: from this announcement, you have a window—usually several weeks—to prepare, test, and deploy the switch to the successor. A team that monitors deprecation announcements migrates at its own pace; a team that doesn’t migrates in a rush.

The obsolete state is the end of the road: the model is withdrawn, and any request bearing its ID fails. There’s no automatic fallback to a nearby version, no grace period. If your application still references this model on that day, it stops.

Endpoints and their status

Endpoints follow a similar logic, with their own status.

The case of /v1/chat/completions deserves an explanation, since its longevity causes confusion. Its compatibility with the OpenAI format made it the natural entry point for all teams coming from another provider: you change the base URL and the key, and existing code works. This advantage has a downside—the endpoint no longer receives new features, as development now focuses on /v1/responses. You can continue using it, but every new capability will pass you by.

Isolating the model reference

All the difficulty of a migration plays out before it happens, in how your code names the model. If it appears hardcoded in fifteen files, changing the ID becomes a treasure hunt with inevitable oversights. If it’s declared in one place, the migration takes a minute:

# config.py
GROK_MODEL = "grok-4.20-0309"  # Fixed version for production
GROK_MODEL_FAST = "grok-build-0.1"

# Facilitates migration: only one place to modify

Try this exercise on your own codebase: search for all literal occurrences of a model name. If the count exceeds one, you have technical debt to settle before the next deprecation, not after.

Migration process

Once this centralization is in place, the switch follows four steps:

1. Update the model field in your configuration
2. Test your existing prompts with the new model in a staging environment
3. Adjust if necessary: newer models may respond differently, with variations in tone, length, or format
4. Deploy gradually: start with a percentage of traffic before switching completely

Step 3 is the most underestimated. A newer model is generally better, but “better” doesn’t mean “identical”: a more detailed response breaks a calibrated display, a slightly different format fails JSON parsing, a more cautious tone changes the user experience. This is precisely what step 4’s gradual deployment allows you to detect on real traffic before all your users suffer it.

Key takeaways

• Models go through three states: Active, Deprecated, then Obsolete (removed)
• The /v1/responses endpoint is primary; /v1/chat/completions is legacy and no longer receives new features
• Centralize the model name in a configuration file to facilitate migrations
• Always test your prompts with the new model before migrating to production
• Monitor deprecation announcements to plan your migrations ahead of time