Stable model aliases (e.g. deepseek-flash-latest) so members never have to change version numbers #47

New Issue

2026-11-06T19:37:00Z

inference-bot commented

2026-11-06 19:37:00 +00:00

The problem

Our model names carry provider version numbers: greenpt/deepseek-v4.1-flash, greenpt/glm-5.3-flash, tinfoil/deepseek-v4-1-flash. Every time a provider deprecates or upgrades a model, the transition breaks member configurations: clients have to change the model name, the docs change, and the daily digest has to re-learn the expected list. This just happened with tinfoil/glm-5-3-flash (deprecated by Tinfoil, replaced by greenpt/glm-5.3).

Members shouldn't have to track provider version churn to keep using the co-op.

The proposal

On the next model transition, introduce co-op-controlled stable alias names that we re-point when we change the underlying model:

deepseek-flash-latest -> whatever model we currently serve as the fast DeepSeek tier
glm-flash-latest -> whatever serves the fast GLM tier
(extend the pattern to other tiers as needed)

Members pick the alias once. On a transition, we change what the alias points to in the gateway config, and nothing on their side breaks.

How it works technically

LiteLLM already supports this: a model_name is just a label mapped to an underlying provider model, and multiple names can point at the same model. Adding an alias is a config-only change in the gateway -- no member action, no client changes.

Considerations

Pricing must be stated at the alias. If the underlying model's price changes at a transition, members using the alias experience a price change without a name change. The docs and the transition note should say what the alias costs now; optionally the digest can flag alias price changes as part of a transition.
Old names should keep working during a transition window (both names served for a while), so members can migrate at their own pace rather than on our schedule.
Deprecation notice in-chat: when a model a member is using is about to be re-pointed or retired, a note in the chat UI or a message to affected members beats discovering it from a 404.
Docs/digest: the "expected models" list in the daily digest and the docs model page should reference the aliases as the stable names, with the underlying version listed as detail.

Who it's for

All members using the chat or the API, and the co-op's own ops (fewer digest and docs updates per transition).

## The problem Our model names carry provider version numbers: `greenpt/deepseek-v4.1-flash`, `greenpt/glm-5.3-flash`, `tinfoil/deepseek-v4-1-flash`. Every time a provider deprecates or upgrades a model, the transition breaks member configurations: clients have to change the model name, the docs change, and the daily digest has to re-learn the expected list. This just happened with `tinfoil/glm-5-3-flash` (deprecated by Tinfoil, replaced by `greenpt/glm-5.3`). Members shouldn't have to track provider version churn to keep using the co-op. ## The proposal On the next model transition, introduce co-op-controlled **stable alias names** that we re-point when we change the underlying model: - `deepseek-flash-latest` -> whatever model we currently serve as the fast DeepSeek tier - `glm-flash-latest` -> whatever serves the fast GLM tier - (extend the pattern to other tiers as needed) Members pick the alias once. On a transition, we change what the alias points to in the gateway config, and nothing on their side breaks. ## How it works technically LiteLLM already supports this: a `model_name` is just a label mapped to an underlying provider model, and multiple names can point at the same model. Adding an alias is a config-only change in the gateway -- no member action, no client changes. ## Considerations - **Pricing must be stated at the alias.** If the underlying model's price changes at a transition, members using the alias experience a price change without a name change. The docs and the transition note should say what the alias costs now; optionally the digest can flag alias price changes as part of a transition. - **Old names should keep working during a transition window** (both names served for a while), so members can migrate at their own pace rather than on our schedule. - **Deprecation notice in-chat:** when a model a member is using is about to be re-pointed or retired, a note in the chat UI or a message to affected members beats discovering it from a 404. - **Docs/digest:** the "expected models" list in the daily digest and the docs model page should reference the aliases as the stable names, with the underlying version listed as detail. ## Who it's for All members using the chat or the API, and the co-op's own ops (fewer digest and docs updates per transition).

limdingwen commented

2026-11-09 15:46:35 +00:00

An example we can learn from is from NanoGPT: https://nano-gpt.com/models/text/deepseek/deepseek-v4-flash-latest

The model slug is: deepseek/deepseek-v4-flash-latest

And details are in the description:

Moving alias for DeepSeek V4.1 Flash 1017, with text and image input, tool calling, structured output, and optional reasoning. Zero data retention and JSON Schema output are available on eligible routes; output limits and reasoning levels depend on the selected route.

I think if (when?) we move into owning servers, this would be pretty important policy: do we use latest models for most and update automatically, or do we need to hold a vote to update the model each time? Given that I proposed this, I think the former would make more sense; but we can still hold a vote to host old versions of models permanently, subject to server space.

An example we can learn from is from NanoGPT: https://nano-gpt.com/models/text/deepseek/deepseek-v4-flash-latest The model slug is: `deepseek/deepseek-v4-flash-latest` And details are in the description: > Moving alias for DeepSeek V4.1 Flash 1017, with text and image input, tool calling, structured output, and optional reasoning. Zero data retention and JSON Schema output are available on eligible routes; output limits and reasoning levels depend on the selected route. I think if (when?) we move into owning servers, this would be pretty important policy: do we use `latest` models for most and update automatically, or do we need to hold a vote to update the model each time? Given that I proposed this, I think the former would make more sense; but we can still hold a vote to host old versions of models permanently, subject to server space.

inference-admin added the Infrastructure label 2026-11-09 16:22:38 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: co-op/support#47