Start here · Step 5: Models and providers

    AI models and providers: snapshots, aliases, catalogs

    What an AI model is, what a model provider does, and how dated snapshots and aliases work, with the providers in the Gatewayz catalog today.

    Last updated · 10 min read · Gatewayz

    An AI model is a trained file of numerical weights together with the runtime that turns input text into output. A model provider is the organization that trains or hosts that model, publishes it under an id, sets its price, and eventually retires it. Your code refers to a model only through that id.

    What is an AI model?

    An AI model is a large set of learned numbers, the weights, produced by training, plus the code that runs those weights on hardware to produce output. On its own, a weights file does nothing. It becomes useful when a runtime loads it onto accelerators and performs inference: reading your input and generating a response one piece at a time.

    It helps to separate the two parts, because they change on different schedules.

    • The weights define what the model knows and how it tends to behave. Changing the weights produces, in practice, a different model, even if the name looks similar.
    • The serving runtime covers everything around the weights: the hardware, batching, request limits, safety filters and the API in front of it. A provider can improve the runtime without touching the weights.

    Anthropic's documentation draws this same line. It describes model ids as fixed identities for weights and configuration, while the serving infrastructure behind them can be updated over time. See Anthropic's page on model ids and versions.

    For a builder, the practical consequence is simple. When you pick a model, you are really picking a specific set of weights, and the only handle you have on those weights is the id string you send in each request.

    What does a model provider do?

    A model provider trains or hosts a model and makes it available through an API. The provider decides what the model is called, what it costs per token, what limits apply, and how long each version stays available.

    Four responsibilities matter most to anyone building on a model:

    1. Training or hosting. Some providers train their own models. Others host models trained elsewhere. Either way, the provider runs the machines that answer your request.
    2. Setting the list price. Providers publish a list price, usually a separate rate for input and output tokens. Prices differ across models and sometimes across versions of the same model.
    3. Releasing versions. New versions ship under new ids. A provider may also publish a shorter name that points to the newest version in a family.
    4. Retiring versions. Older models are deprecated and then retired on a published schedule. After retirement, requests to that id stop working.

    That last point is easy to overlook when you first build something. Every model you depend on has an end date, even if it has not been announced yet. Both Anthropic and OpenAI publish deprecation pages that list retired and soon-to-retire models, and it is worth checking them when you plan a release.

    What is the difference between a dated snapshot and an alias?

    A dated snapshot is an id that always refers to the same weights. An alias is a convenience name that points to a snapshot and can be moved to a newer one by the provider.

    Here is how the two compare, using ids from the Gatewayz catalog and the undated Anthropic alias that resolves to one of them:

    Dated snapshotAlias
    Exampleopenai/gpt-4o-2024-08-06openai/gpt-4o
    Exampleanthropic/claude-sonnet-4-5-20250929claude-sonnet-4-5
    Refers toOne fixed model versionWhatever snapshot it currently points to
    Can change without your code changingNoYes, when the provider moves it
    Behavior next monthSame as today, until retirementPossibly different
    Best used forProduction, evaluations, anything you testedExploration, prototypes, quick checks
    RetirementHas its own deprecation dateMoves or disappears as its targets retire

    OpenAI's model pages describe snapshots as a way to "lock in a specific version of the model so that performance and behavior remain consistent", and list each model's aliases and dated snapshots side by side. See the OpenAI models documentation. Anthropic's documentation says an alias such as claude-sonnet-4-5 resolves to the most recent dated snapshot for that minor version.

    Not every dateless id is an alias

    One detail trips people up. A missing date does not always mean the id is an alias. Anthropic's documentation states that from the 4.6 generation onward, ids such as claude-sonnet-4-6 carry no date but are themselves pinned snapshots: the weights behind that id do not change, and an updated model ships under a new id. Earlier Anthropic models used dated ids with dateless aliases in front of them.

    The general rule, then, is not to guess from the shape of the string. Read the provider's documentation for the family you use, and check the id against the catalog you call.

    Why should you pin dated snapshots in production?

    Pin snapshots because an alias can change the model under a running system without a deploy, a code review, or a line in your changelog. Everything you tested was tested against one set of weights, and a pinned id keeps it that way.

    A few concrete ways an alias move shows up:

    • Output format drifts. A newer version may phrase answers differently, wrap JSON in extra text, or format tool calls slightly differently. Parsers that worked yesterday start failing.
    • Evaluation results stop applying. A test suite that passed against one snapshot says nothing about the next one.
    • Cost changes. A newer version can have a different list price or produce longer outputs, so the same traffic costs a different amount.
    • Debugging gets harder. When behavior changes, the first question is "did the model change?" With an alias in the config, answering it requires reconstructing what the alias pointed to on a given day.

    Pinning does not remove change. It moves change to a moment you choose. When a provider announces a retirement, you update the id, run your evaluations against the new snapshot, and ship it like any other dependency upgrade.

    A short pinning checklist

    1. Store model ids in configuration, not scattered through code.
    2. Use dated or otherwise pinned snapshot ids for every production path.
    3. Log the model field returned in each response, not only the one you sent.
    4. Check configured ids against the live catalog at deploy time.
    5. Track the provider deprecation pages for every model you use, and schedule upgrades before the retirement date.

    Which providers are in the Gatewayz catalog?

    The Gatewayz catalog today includes models from OpenAI, Anthropic, xAI, Moonshot and Meta. The authoritative list is the live catalog at https://api.gatewayz.ai/v1/models, which is public and needs no API key.

    Gatewayz has no model of its own and does not choose a model for you. It is an inference layer: one API key and one endpoint in front of models from several providers. You name the model in each request, and the provider behind that model runs it. Models are billed per token at the provider's list price plus a routing fee, from one prepaid balance. For the broader picture of what that layer does, see What is Gatewayz?.

    A few ids from the catalog, by provider:

    ProviderExample ids
    OpenAIopenai/gpt-5, openai/gpt-5-mini, openai/gpt-4o-2024-08-06
    Anthropicanthropic/claude-sonnet-4-6, anthropic/claude-haiku-4-5-20251001
    xAIgrok-4
    Moonshotmoonshot/kimi-k2.6
    Metameta/muse-spark-1.3

    Most ids carry a provider prefix, such as openai/ or anthropic/, but not every one does, as the xAI row shows. Copy ids exactly as the catalog lists them rather than constructing them by pattern. Catalogs change as providers release and retire models, so treat any table in an article, including this one, as an example and the live endpoint as the source of truth.

    How do you list model ids with curl?

    Send a GET request to the catalog endpoint and extract the id field of each entry. No key is required.

    List every id:

    curl -s https://api.gatewayz.ai/v1/models \
      | python3 -c 'import sys, json; [print(m["id"]) for m in json.load(sys.stdin)["data"]]'

    List only one provider's models, for example Anthropic:

    curl -s https://api.gatewayz.ai/v1/models \
      | python3 -c 'import sys, json; [print(m["id"]) for m in json.load(sys.stdin)["data"] if m["id"].startswith("anthropic/")]'

    Check that a specific id exists before you deploy it:

    curl -s https://api.gatewayz.ai/v1/models | grep -c '"openai/gpt-4o-2024-08-06"'

    A result of 0 means the id is misspelled or no longer offered. Each catalog entry also carries fields such as a display name, context length and per-token pricing, so the same response can feed a configuration check or an internal model picker.

    What happens when you request an alias or an unknown id?

    On Gatewayz, an alias resolves to one exact dated snapshot, and an unknown id is refused with 400 model_not_found. A different model is never run in its place.

    That behavior is called model resolution, as opposed to substitution. A request for claude-sonnet-4-5 runs the dated snapshot that alias points to. A request for an id that matches nothing returns a 400 with an error body in this shape:

    {
      "error": {
        "message": "...",
        "type": "...",
        "code": "model_not_found"
      }
    }

    Branch on the status and the code field, not on the wording of message, which is written for people and can change.

    A 400 is a terminal error. Retrying the same request will not help, so SDKs do not retry it and it should not count against a provider's health. The fix is to correct the id. The reasoning behind refusing rather than guessing is laid out in Resolution, not substitution, and the case for status codes as control flow is in Who reads the error?.

    Common misconceptions about models and providers

    A handful of assumptions cause most model-id problems.

    • "The model name is the model." A family name like GPT-4o or Claude Sonnet covers several snapshots. Only the full id identifies one.
    • "Dateless means it will change." Sometimes. Some providers now publish dateless ids that are pinned. Check the documentation.
    • "If a model is listed, it will be there next year." Every model has a retirement path. Plan for upgrades.
    • "A gateway will pick something close if my id is wrong." On Gatewayz it will not. An unknown id is an error, by design.
    • "Same weights, same results everywhere." Sampling settings, system prompts and serving limits all affect output. Pinning the id is necessary for consistency, not sufficient on its own.

    Frequently asked questions

    Is a model the same thing as a provider?

    No. The model is the trained weights and the runtime that serves them, identified by an id. The provider is the organization that trains or hosts it, sets its price and controls its lifecycle. One provider usually offers many models, and the id in your request is how you select one of them.

    Should I ever use an alias in production?

    Only if you have decided that automatic upgrades are acceptable for that path and you monitor output quality closely. For anything you evaluated, anything that parses structured output, and anything running unattended, a pinned snapshot id such as anthropic/claude-haiku-4-5-20251001 is the safer default.

    How do I find out when a model will be retired?

    Read the provider's deprecation page. Anthropic and OpenAI both publish them. It is also worth re-checking the Gatewayz catalog at deploy time, because an id that is no longer offered will return 400 model_not_found.

    Does Gatewayz change which model runs my request?

    No. Gatewayz runs the model you name. An alias resolves to exactly one dated snapshot, an unknown id returns 400 model_not_found, and a different model is never substituted. Choosing a model, and any fallback between models, stays in your code.

    Do I need an API key to see the catalog?

    No. The catalog at https://api.gatewayz.ai/v1/models is public. You need a key only to send inference requests. What is an API, an endpoint and an API key? covers how keys are sent.