# Channels and routing

Source: https://platform.lyrouter.com/ai_gateway/docs/routing/en
Last updated: 2026-10-19

Each workspace has one set of Smart routing settings that decides which channel the gateway uses for a call. A model is usually served by several channels, counting both platform channels and your BYOK channels. The multi-channel routing strategy sets the order in which those channels are tried; the Default Model takes over when a request has no `model`, or when every channel of the requested model fails. The settings apply to every API key in the workspace and reach the gateway within seconds of saving.

## Workspace settings

The current Account Owner changes these settings on the workspace's **Smart routing** page, which has a single General settings card:

| Setting | Purpose | Default for a new workspace | How it is saved |
| --- | --- | --- | --- |
| Multi-channel routing strategy | Order in which a model's channels are tried when you call a model ID directly | Lowest Price | Saved as soon as you choose |
| Default Model | Used when a request has no `model`; also the last resort when the requested model fails | Not set | Saved as soon as you choose or clear it |
| Auto smart routing | Candidate models for `lyrouter/auto`; see [Auto routing](https://platform.lyrouter.com/ai_gateway/docs/auto/en) | All enabled models | Click **Save Auto settings** in the Advanced settings drawer |

(Screenshot: Channel sorting and the default model are separate settings; Auto has its own advanced configuration.)

The three settings are saved separately, so changing one never overwrites the others. Account Members do not see this menu, and opening the page link directly shows a message that their organization role cannot access it. Calls made with a member's own API key still follow these settings.

## Models, channels and credentials

The gateway first settles on a model, then picks a channel for it, then a credential within that channel. A provider identifies the vendor; the protocol, endpoint and access mode belong to the channel, so a provider's pay-as-you-go service and its Coding Plan are two different channels. A channel can hold several credentials: your BYOK credentials come first, in the order you set in BYOK, followed by platform credentials.

## Multi-channel routing strategy

When you call a model ID directly (for example `deepseek/deepseek-v4-flash`), the gateway sorts that model's channels with this setting and tries them in order:

| Option | Routing strategy shown in logs | How channels are sorted |
| --- | --- | --- |
| Lowest Price | `cost` | By estimated paid price per request, lowest first. The estimate uses the model's average input and output tokens per request, the channel's cache hit rate and the price at call time; channels that cannot be priced go last |
| Load balanced | `balanced` | By measured latency first; then each API key + model pair is consistently assigned to one channel (weighted by the platform's channel weights). The assigned channel goes first and the others follow in latency order as fallbacks |
| Highest Throughput | `throughput` | By measured output speed, highest first; channels without measurements go last |
| Lowest Latency | `latency` | By measured latency, lowest first; channels without measurements go last |

- **Session affinity**: Lowest Price and Load balanced keep calls from the same API key to the same model on one channel, which raises the upstream prompt-cache hit rate. The binding lasts 30 minutes and is renewed by every call; it moves to another channel when the current one returns 429, 408, a 5xx or a connection failure. For cache optimization, see [Reducing costs and improving cache reuse](https://platform.lyrouter.com/ai_gateway/docs/cost-practice/en).
- **Custom providers first**: under Load balanced, Highest Throughput and Lowest Latency, channels of the workspace's custom providers have no comparable platform measurements and always come before platform channels.
- **Scope**: the setting applies only to calls that name a model ID. [Virtual models](https://platform.lyrouter.com/ai_gateway/docs/presets/en) use their own Channel sort strategy, and `lyrouter/auto` ignores this setting.
- **No per-request override**: the note "a single request can override this setting" shown with the option is not implemented, and requests have no parameter that overrides routing. To give some calls a different order, create a virtual model for them and set its Channel sort strategy.

## Default model

The default model has two uses:

1. **Requests without a model**: when the body has no `model`, or `model` is `""` or `null`, the default model is used. Without a default model, such requests return 400 `you must provide a model parameter` (`error.code` `missing_model`).
2. **Last resort after failure**: after every channel of the requested model fails, the gateway tries the default model last. A requested model that is not enabled in the workspace is also answered by the default model instead of returning 403.

Before relying on it:

- **Not prefilled for new workspaces**: new workspaces start with Not set. Older workspaces may have been prefilled with `qwen/qwen3.7-plus`; check the page and clear it if you do not want a fallback.
- **Must be usable in this workspace**: the selector lists the platform catalog and also accepts a typed model ID, and saving does not check availability. If the default model is neither enabled in the model marketplace nor served by a working BYOK key, requests without `model` return 403 `Model is not available in the model plaza`, and no fallback happens.
- **Chat-style endpoints only**: image, video and audio endpoints never fall back to the default model. Embeddings requests do fall back, but the default model is usually a chat model, so the result is typically 400 `unsupported_model_api`; always name a usable model ID for embeddings.
- **Confirm in the logs**: when the default model answered, Model (actual) in the [log](https://platform.lyrouter.com/ai_gateway/docs/logs/en) details shows the default model.

## BYOK channel rules

In the usage settings of [BYOK](https://platform.lyrouter.com/ai_gateway/docs/byok/en) you can give a channel one of two preferences, both of which take precedence over the multi-channel routing strategy:

- **Prefer this Channel**: puts the channel first; on failure the gateway falls back to other channels and the default model as usual.
- **Only use this BYOK**: the model uses only this channel's BYOK credentials, never platform credentials, other channels or the default model, and the request ends when they all fail. When called through a virtual model or `lyrouter/auto`, the gateway still moves on to the next candidate model after the restricted model fails, but the whole request no longer falls back to the default model.

(Screenshot: Check caller scope and preference or exclusive-use rules in BYOK usage settings.)

## Verify

After changing a setting, send a test call and check the log details as described in [Inspecting request routing](https://platform.lyrouter.com/ai_gateway/docs/route-log/en): Routing strategy in the routing trace shows one of the values above, and Model (actual) and Provider show the model and channel that answered. All candidates is only the sorted candidate list and does not mean every candidate was called; actual calls are recorded under Upstream call attempts. How failures move between channels is covered in [Retries and fallback](https://platform.lyrouter.com/ai_gateway/docs/fallback/en).