Model names will change

Model rankings change quickly. Providers release new versions, change aliases, adjust limits, and retire old models. A recommendation tied to one name can become obsolete while the underlying decision remains useful.

This means Which model should I use? is not a decision you make once. It is a dependency you manage.

Record what you selected

For important workflows, record:

• provider and exact model identifier
• date of the evaluation
• prompt or system instructions
• relevant settings and available tools
• evaluation examples and scores
• acceptable cost and latency

The model name alone is not enough. A changed prompt, tool description, or retrieval step can alter the result as much as a model upgrade.

If an API offers a dated or pinned model version, use it when repeatability matters. A moving alias is convenient for experimentation, but it can change behavior without a code change in your application.

Treat upgrades like dependency upgrades

A newer model is not automatically better for your task. It may follow instructions better and still produce a different JSON shape. It may be faster but call tools more often. It may reject an input the old version handled.

Run the saved evaluation before switching. Compare quality, latency, cost, and failure behavior. Then roll out gradually if the workflow matters to users.

Keep a rollback path. This can be a previous model identifier, a feature flag, or a routing rule that sends only part of the traffic to the new version.

Keep the durable criteria

Names will change, but the useful questions remain:

• Is the task simple or complex?
• How much and what kind of context is needed?
• Does latency matter?
• What is the cost of a wrong answer?
• Which tools or data types are required?
• Can we evaluate the output reliably?

Your evaluation set is more valuable than a list of this month’s winners. It lets you reconsider the choice whenever the market changes.