| Level | Chooses between | Configured with |
|---|---|---|
| Endpoint routing (the router) | the upstream endpoints of one model | the router: block of gateway.yaml and a model’s upstreams[] |
| Routing configs | different models, for failover, canary, latency and conditional routing | named configs, created in Gateway → Routing or /admin/gateway/configs |
gateway.yaml model with upstreams[] has. A model registered through the console has a single endpoint, so it is routed with a routing config instead.
Endpoint routing
The default strategy applies to every request, whatever config it carries. These are the settings with their defaults:gateway.yaml
strategy (except score), health_interval, failure_threshold, cooldown, prefix_bytes and session_ttl in the administration console’s settings (Router section); the other fields are gateway.yaml only.
| Strategy | Description |
|---|---|
least_inflight | Routes to the endpoint with the fewest active requests; a higher weight breaks ties. Best general-purpose choice. |
round_robin | Rotates across healthy endpoints. |
prefix_affinity | Hashes the first prefix_bytes of the prompt to pick the same endpoint for similar prompts, which helps KV cache locality. Falls back to least in-flight when it has no prompt. |
score | Grades each endpoint on a moving average of success rate and latency, penalised by queue depth: health / (1 + latency × (1 + pending × 0.1)). Two endpoints are drawn at random and the better one wins, so traffic does not herd onto one. It sheds traffic from an endpoint that has gone slow or started erroring before it fails outright. |
Sticky sessions
When a request carries anX-Session-Id header (or a user field in the body), the router remembers the endpoint that served that session for session_ttl and prefers it on later requests, under any strategy. If the endpoint is no longer usable, the session is remapped. On a virtual model, the same key also keeps a session on one side of a canary split.
Upstream health
- Ejection. An endpoint is taken out of rotation after
failure_thresholdconsecutive failures, or when its health average falls belowhealth_threshold. Connection errors, timeouts,5xx,429,408and401/402/403from the provider count as failures; other4xxresponses reject what the caller sent and do not. - Window. The ejection lasts
cooldown, multiplied by the number of ejections since the last success, up tomax_ejection_duration. When the provider states its own wait (Retry-After) andrespect_retry_afteris on, that wait is used instead, unescalated. - Recovery. Every
health_intervalthe gateway probes ejected endpoints withGET /v1/models. One that answers comes back atrestore_health, so it earns traffic back instead of taking its old share at once. A real success clears the escalation. - Failover. With several endpoints, a request that fails before any byte reaches the client moves to the next endpoint. If every endpoint is ejected, the request fails immediately with
provider_unavailable.
gateway.yaml:
healthy, ejected_until, inflight, consecutive_fails, score and latency averages) and the last hour’s request count, error rate and p95 latency per model. It requires the analytics permission in the workspace.
Routing configs
A routing config picks among models. Create one under Gateway → Routing, or with the API; the full schema, retry policy and per-target settings are on Virtual models.?workspace_id=<id>. Configs belong to one workspace and serve requests made in it.
Routing strategies
- Fallback
- Canary
- Conditional
- Latency
- Complexity (Auto Routing)
- Single
Try targets in order. A target is retried per
retry, then the request moves to the next target on a status in fallback_status_codes (by default 400 401 403 404 408 413 422 429 500 502 503 504, plus the retry codes).Using a routing config
A config applies to a request in one of three ways, in this order: the request’smodel is the name of a config that has model_types (a virtual model), the X-ManyLayers-Config header names a config by id or name, or the team’s default_config_id applies. An unknown header value returns 400 unknown_config.
X-ManyLayers-Config, X-ManyLayers-Routing-Strategy, X-ManyLayers-Routing-Model-Order and X-ManyLayers-Target.
Config management API
All routes are onhttps://app.manylayers.io and need the routing permission in the workspace (gateway.routing.read to read, gateway.routing.manage to change).
| Method | Path | Description |
|---|---|---|
GET | /admin/gateway/configs | List the workspace’s routing configs |
POST | /admin/gateway/configs | Create a config |
GET | /admin/gateway/configs/{id} | Get a config |
PUT | /admin/gateway/configs/{id} | Update a config |
DELETE | /admin/gateway/configs/{id} | Delete a config |
GET | /admin/gateway/configs/usage | Last 30 days of requests per virtual model and target |