Routing and Model Selection: How Channels, Models, and Clients Relate
When using an AI gateway, three concepts cause the most confusion: channels, models, and clients. Understanding how they relate will help you configure routing correctly and avoid puzzles like "why didn't my request go through the channel I expected."
The Three Core Concepts
- A channel is an upstream connection: an Ollama instance, or a cloud provider account.
- A model is a capability offered on a channel: a specific model name such as
qwen3:8b. - A client is the AI tool you use every day: Claude Code, Codex, opencode, and so on.
Together they form a one-way chain:
Client → (virtual key) → Gateway (routing strategy) → Channel → Model
On every request, the client specifies the model name in the request; the gateway then looks up a channel that can serve that model and forwards the request to it.
What "model (channel name)" in the Model List Means
In the model picker of clients like Claude Code and opencode, you'll see entries such as qwen3:8b (Ollama Qwen3). The name in parentheses indicates which channel this model comes from—it is not "another connection":
- There is always just one connection between your client and the gateway (one address + one virtual key).
- The same model can also be configured on multiple channels. In that case, the picker still shows only a single entry (with one of the source channels in parentheses); which channel actually serves each request is decided by the routing strategy (see below).
Three Routing Modes: Fixed, Failover, and Balanced
The routing strategy answers one question: when multiple channels can serve the same model, which one should be used?
| Mode | Behavior | Best For |
|---|---|---|
| Fixed | Always uses the same channel | Stable channel quality when you want to lock in a source |
| Failover | Switches to backup channels in order when the primary fails or runs out of quota | Setups with a primary plus backups |
| Balanced | Distributes requests round-robin across available channels | Spreading load across multiple equivalent channels |
Two key boundaries to keep in mind:
- Routing switches between channels only, never between models. Which model to request is always decided by your client—the gateway never swaps models for you.
- Different models naturally go through their own channels. Balanced never means "use the model on channel A this time, the model on channel B next time"—it only rotates among multiple channels of the same model.
The Client Decides the Model: How to Switch Models
The gateway only forwards requests: your tool includes the model name in every request, and the gateway routes accordingly. Switching models is done in the client:
- opencode: Type
/modelsin the TUI to select one; or configuremodel(main model) andsmall_model(for lightweight tasks like title generation) inopencode.json. - Claude Code: Switch with the
/modelcommand. - Codex: Specify with the
-m <model>flag or in the config file.
Safely Connecting Your Everyday Tools to the Gateway
Worried about disrupting your daily workflow? Follow this process:
- Start with a low-stakes project: Complete the one-click connection in an unimportant project directory first and make sure your workflow runs normally.
- Verify with a single request: Send one test request, then check the "Usage Records" page to see which model and channel it landed on and how much it cost.
- Roll back anytime: Stop the takeover on the "Access Management" page. Once stopped: the configuration ServBay wrote will be removed, and any virtual keys created by the takeover will be revoked; your previous custom configuration will not be restored automatically, so adjust it manually if needed and restart the client for the changes to take effect.
Summary
- Channel = upstream connection; model = a capability on a channel; the model name is specified by the client on every request.
- The routing strategy only chooses among "multiple channels for the same model": Fixed locks one, Failover provides primary/backup switching, Balanced rotates.
- Switch models in your client's model picker; verify the destination and cost of each request on the "Usage Records" page.
