Routing and Reliability

Token360 resolves each public model name to an eligible upstream route. The platform applies authentication, model configuration, route health, metering, and account policy before forwarding a request.

What the model name means

Use the public model name shown in the Token360 catalog. It is a stable product-facing identifier, not an upstream account, deployment, or API-key name.

A model can have one or more eligible service routes. Availability and parameter compatibility are evaluated against the configured route. Token360 does not promise that every request will use the same upstream provider unless your enterprise configuration explicitly pins that behavior.

Route selection

The platform may consider:

• whether the route and its credentials are active;
• recent provider health and rate-limit state;
• model and parameter compatibility;
• tenant model-access and data-residency policy;
• capacity and routing policy configured for the account.

Token360 does not expose OpenRouter-style request fields for arbitrary provider ordering, provider allowlists, price ceilings, or cross-model fallback. Do not send those fields unless they appear in the selected model's published schema.

Failure behavior

When no compatible route is available, the request returns a standard error. A route change is not a reason to change the public model name in your application.

Automatic route handling does not replace client resilience:

• retry only transient errors;
• cap attempts and total elapsed time;
• add exponential backoff and jitter;
• do not retry invalid requests or insufficient balance without correcting the cause;
• take extra care with asynchronous create operations, because an upstream operation might have started before the client observed a timeout.

Response and audit signals

Where available, capture:

• response model name;
• provider or route metadata;
• request or generation ID;
• X-Request-Id and X-Trace-ID response headers;
• status, latency, usage, and cost.

Use the console request detail and generation metadata endpoints to investigate the route that served a request. When contacting support, include correlation IDs and timestamps, but never include the API-key secret.

Data policy and routing

Enterprise data-residency settings constrain eligible routing. A preferred or required region is a routing policy; it does not by itself describe every retention, logging, or training behavior. Review Security and Data Handling for the full data path.

Design for continuity

• Keep public model names in application configuration rather than source code.
• Validate a replacement model before switching production traffic.
• Use streaming for interactive long responses when supported.
• Use Async Chat or Batch Jobs for work that should survive a client connection ending.
• Monitor success rate, P95 latency, and error categories by model.
• Keep enough spendable balance or credit for expected bursts.

What Token360 does not guarantee

• A fixed upstream provider for an unpinned route.
• Identical output across providers, model revisions, or retries.
• That retrying a non-deterministic request returns the same result.
• Cross-model fallback unless it is part of an explicitly contracted route.