Stable AI model IDs across changing provider routes

Failure mode: treating a vendor model string as the public contract

The common identity failure is letting a provider’s internal model string become the customer contract. Teams hard-code a vendor endpoint name, then discover Azure expects a deployment name, another host expects a different spelling of the same family, or a default alias quietly points at a newer build. When that happens, “the same model” is no longer the same request: quotes, options, and failover comparisons become incomparable.

OfflineCreator’s documented antidote is a stable public ID with configuration-backed mappings underneath. First-party notes warn that provider model identifiers are deployment assumptions until canary passes and that operators should kill a stale route instead of silently substituting another model or version. Live cloud disclosure currently states that the launch catalog is routed through fal, so do not treat managed multi-provider route matrices in internal docs as anonymously confirmed live availability for every account. Per-model marketplace endpoint pages answer a different question than this identity-stability URL.

Wrong contract

Vendor string ≠ public IDAzure deployment names and OpenAI model names already show how identities diverge across hosts.

Silent substitute

Identity breakReplacing a stale route with a different model or version invalidates the caller’s request.

Scope boundary

Identity vs endpoint merchandisingThis URL owns identity stability across routes; model endpoint guides own individual model identifiers.

Public model identity, provider mapping, version parity, option compatibility, and route changes

Treat the evidence requirement as five checks that fail independently. Public model identity asks whether callers keep one stable string across Studio, API, CLI, and MCP. Provider model mapping asks whether each route records the vendor model or endpoint used for that public ID. Version parity asks what happens when a provider route becomes stale or mismatched—disable it, or silently substitute another model. Option compatibility asks whether duration, resolution, and other priced settings are validated against the selected route before ranking. Route changes ask how credentials, health, kill switches, and rollout modes introduce or remove adapters without renaming the public ID.

OfflineCreator’s first-party routing notes describe those checks in operational language. The route catalog maps stable public model IDs to provider-specific identifiers—for example public grok-1-5-text to an xAI provider model string, or Seedance public IDs to provider-specific Seedance endpoint names—while feature-parity and allowed-option metadata decide whether a route may compete. Provider model identifiers remain deployment assumptions until a staging canary passes; a stale route should be killed rather than silently replaced with a different model or version. Managed selection depends on credentials, health, options, rollout mode, and kill switches, and missing optional direct-provider keys disable those routes while fal-only operation remains valid.

OpenRouter’s published provider object is useful as an external methodology check: the model stays in the request while order, allow_fallbacks, require_parameters, only, ignore, and sort constrain which providers may serve it. That is the same class of separation OfflineCreator documents—stable identity above, bounded adapters below—without claiming OpenRouter’s defaults or live inventory.

Public model identity

34 documented public IDsThe caller-facing catalog stays fixed while routes compete underneath.

Provider model mapping

Public ID → vendor stringEach configured route records the provider model or endpoint for that public ID.

Version parity

Kill, do not silently swapDisable a stale route instead of substituting a different model or version.

Option compatibility

Settings filter eligibilityAllowed options and feature parity remove incompatible routes before selection.

Route changes

Credentials, health, rolloutShadow, canary, active, and kill switches change adapters without renaming the public model.

Where to go next

If you need the broader product overview—Kayak-style booking language, signed quotes, and the full router narrative—use the parent AI Router page. Keep this URL focused on identity stability for the query “stable ai model ids across providers.”

If your next question is how health removes routes from selection, continue to AI provider route health. If you need the price lock that sits on top of a fixed model identity, continue to lock AI generation price before running. If you need the wider multi-provider routing method, continue to multi-provider AI generation routing.

Canonical ownership and evidence boundary

This URL owns identity stability across changing provider routes for “stable ai model ids across providers,” including public model identity, provider model mapping, version parity, option compatibility, and route-change controls. It does not own per-model endpoint merchandising, retail generation pricing, or competitor win/loss claims. The parent /ai-router hub owns the broader AI generation router overview.

Supported product statements are limited to OfflineCreator’s documented router behavior and live cloud provider disclosure. Supported external statements are limited to Microsoft’s Azure OpenAI deployment-versus-model naming distinction and OpenRouter’s provider-routing controls. Production GET https://offlinecreatorstudio.com/ai-router returned HTTP 404 during web supplementation on 2026-08-10; product claims were verified against first-party repository sources that implement the unpublished route. This draft does not assert that every managed alternate route is anonymously live, and it does not invent privacy, retention, benchmark, or outcome claims.