The model name saved in an old configuration

A small AI application can run unchanged for weeks, then stop accepting the model name saved in its configuration. Or it can keep working while its answers become slightly different. Both situations can begin with the same detail: the difference between a model’s public name, its API ID, and an alias.

These names are easy to treat as interchangeable. Understanding their roles makes upgrades less surprising and troubleshooting more straightforward.

§ The name you read and the ID you send

A display name is the human-readable label you see in a model catalog, such as Claude Sonnet 5.5 or Gemini 3.1 Pro. A model ID is the exact string your application sends in an API request to select a model.

The ID may resemble the display name, but you should not build it by guessing the spelling, capitalization, or punctuation. Copy the identifier documented by the API service you are calling. Different services can expose the same underlying model under different identifiers.

With Vana API, your application connects through one endpoint that supports OpenAI-compatible requests, Anthropic Messages, and the Gemini native protocol. That simplifies connection setup, but you still need a valid model ID for the request format you use.

§ An alias is a name that points somewhere

A model alias is an identifier that points to another model identifier or deployment. Think of it as a saved contact name: the label can stay the same even when the destination changes.

A service might offer an alias intended to follow the current release in a model family. When the service updates that alias, your application can receive a newer model without a configuration edit. This is convenient, but it also means an unchanged request does not necessarily select an unchanged model.

Not every short identifier is a moving alias, and not every version-looking identifier is permanently fixed. The service’s documentation determines what a particular name promises. Do not infer those promises from the name alone.

§ Why identifiers change

Model IDs change for several ordinary reasons:

• A new release arrives. A provider introduces a different model and gives it a new identifier.
• An older release is retired. An identifier may stop working after its supported lifetime ends.
• The catalog is reorganized. A service may revise naming conventions or distinguish deployments more clearly.
• An alias is updated. The accepted name stays the same, but its destination changes.

These events are related, but they are not identical. A rejected identifier is an availability or configuration issue. Different answers from an accepted identifier may require checking whether its target changed. Ordinary output variation can also happen without any model update.

§ Choosing convenience or tighter control

A moving alias can suit experimentation and applications where following a supported release matters more than preserving a particular model version. It can reduce configuration maintenance, although it does not remove the need to test.

For a workflow with carefully tuned prompts or strict output requirements, prefer an explicitly versioned identifier when the service offers one and documents its behavior. This gives you more control over upgrades. It does not guarantee identical answers on every call or indefinite availability.

Keep the model ID in one configuration setting rather than scattering it across your application. Record the requested identifier alongside test results. If the API returns a model identifier in response metadata, retain that too, without assuming it always reveals the exact underlying deployment.

§ A small check before changing the name

Before replacing an ID, confirm that the new model supports the features your application uses, including tools, images, or structured output. Run a few representative requests and compare answer quality, response time, and token cost. Avoid silently switching to another model when a request fails unless you have deliberately tested that fallback.

If you are starting with Vana API, create an account and check the current model catalog before saving your first identifier. The useful habit is simple: treat the model name as a maintained dependency, not a permanent label.