A model change can become a gateway configuration update while the application keeps requesting the same name.
Cloudflare announced model aliases for AI Gateway on November 4. The beta feature lets a gateway expose a model pool through a name such as custom/my-alias. Developers can change the models or routing configuration behind that name without replacing it throughout their application.
The alias belongs to the gateway
The model-alias documentation describes gateway-specific aliases, supported model targets, and the authentication requirements. Requests need the applicable provider credentials or Unified Billing setup. An alias organizes access to models; it does not supply unrestricted access to every provider.
For an application with several request paths, the benefit is a central place to change the pool. The same name can continue to appear in those paths. Renaming the alias itself is different: clients then need to request the new name.
Choose how the pool selects a model
| Configuration | Selection behavior | Operational question |
|---|---|---|
| Default order | Tries models in the configured order with fallback | Which model should be attempted first? |
| Smart routing | Selects per request; uses the configured order when it cannot rank the models | What happens when ranking is unavailable? |
| Dynamic routes | A separate option for more complex routing rules | Does the application need conditions or traffic splitting? |
A stable alias can simplify a migration, but the application still needs an output contract. If fallback changes the responding model, the answer must remain usable by the code that receives it. Structured output, tool calls, and supported request options deserve separate checks.
Configuration changes have a propagation boundary
Cloudflare documents caching for alias configuration. A change does not necessarily reach every location immediately. Request-level options may also override the saved routing configuration. Record both when investigating why a request used a particular route.
That suggests a controlled rollout: change one evaluation alias, verify observed behavior, and then change the alias used by the application. Keep enough request information to distinguish the requested alias from the model that handled the request. This is an operating proposal, not a migration we executed.
Keep SDK migration separate from gateway routing
Our earlier Cloudflare createAI migration article covers changes to provider packages and credentials in application code. Model aliases address a different layer: choosing among configured gateway model targets behind a request name.
We have not measured cost savings, latency, or fallback reliability for this beta. For a team already using AI Gateway, the immediate decision is whether a centrally managed pool simplifies its existing model changes. Which routing change currently requires the most application edits?




