Most model gateways make two separate decisions look like one: which model the customer requested, and which upstream route will serve it. That shortcut is convenient until a route changes. Then a customer-visible identifier starts leaking operational detail, billing history becomes hard to explain, and a routine infrastructure change can become an integration migration.
01
Identity and delivery are different objects
OurToken treats the public Model as the durable contract. It has an official publisher/model ID, capabilities, lifecycle state, and customer-facing prices. A Provider Offering is private operational inventory: an upstream model reference, credentials, capabilities, cost, and health evidence.
A verified route connects the two. Only one compatible route is active for a model at a time, and activation is an explicit admin action. Customers keep sending the same model ID while operators can repair or replace delivery infrastructure behind it.
02
Compatibility has to be proven
Hiding a provider is only safe when the replacement behaves like the contract it serves. Before activation, a route must be checked for required input and output modalities, context limits, tool support, metering, and normalized error behavior.
A cheaper route that drops image input or reports usage differently is not equivalent. Cost is a routing consideration only after compatibility and verification pass.
- Customer requests contain the stable public model ID.
- Provider credentials and upstream identifiers never enter the public response.
- Unavailable routes return a provider-neutral model error.
- Route changes are audited and deliberately activated.
03
The response keeps the same boundary
A normalized response returns the official model ID, output parts, finish reason, and usage meters. It does not disclose which upstream account, route, or credential fulfilled the request. The same rule applies to logs and exports.
{
"id": "chatcmpl_…",
"object": "chat.completion",
"model": "publisher/model-name",
"choices": [{
"message": { "role": "assistant", "content": "…" },
"finish_reason": "stop"
}],
"usage": {
"input_tokens": 184,
"output_tokens": 63
}
}04
Why the boring contract wins
Stable IDs remove provider selection from application code. They also make deprecation honest: a model can move through preview, active, deprecated, and retired states without confusing that lifecycle with the health of one upstream route.
The result is intentionally uneventful for the developer. Infrastructure can change, but the integration changes only when the actual model contract changes.