Configure 9Router combos and fallback

A 9Router combo gives your client one model name that can route to several configured models. Start with two independently working routes: a primary model and one compatible backup. Then verify the actual routing behavior in your installed version.

Fallback helps when a chosen route cannot complete a request. It does not guarantee identical answers, unlimited capacity, or a lower bill. A backup has its own capabilities, quota, data handling, and price.

Verify each route on its own

Before creating a combo, send a short request to each model separately. Record whether it completes, whether the request appears in the expected provider’s usage history, and whether the model supports the features your client needs.

For a coding task, a text-only test is incomplete. Check streaming and a harmless tool interaction. If you need images, structured output, or a large context, test those requirements explicitly. A backup that cannot accept the conversation is not a useful fallback for that conversation.

Prefer a short initial chain. A list of ten untested models makes it harder to tell whether a request succeeded for the intended reason, and can increase latency when several routes fail in sequence.

Create the combo

Open the dashboard’s Combos section and create a new combo. Choose a short name you will recognize in the client, such as coding-backup. That name is your own configuration choice, not a built-in model.

Add your two verified model routes. Review their order and the routing strategy offered by your installed version. The upstream guide describes ordered fallback, and newer controls may offer additional behavior. Do not assume a load-balancing strategy and an ordered fallback strategy are interchangeable.

Save the combo, then select its exact name in the client or map the client’s model alias to it. If the client sends a native model alias while the router expects a provider-prefixed ID, inspect the mapping rather than changing provider credentials.

The upstream default combo generators can create mappings for client model names. Inspect generated entries before relying on them. Existing names may be skipped, so rerunning a generator does not prove that it updated a customized combo.

Decide what the backup is allowed to change

Write down the tradeoff before enabling automatic fallback:

Requirement	Check before adding a backup
Cost	The provider’s actual billing unit, limits, and account balance
Tools	Tool-call and tool-result support through this route
Context	Whether the backup accepts your normal conversation size
Images	Whether image input is supported for this model and endpoint
Data handling	Where requests go and whether that destination is acceptable
Output	Whether a different model’s behavior fits the task

A route that is acceptable for a short public question may be unsuitable for private source code. Configure the chain for the data you intend to send, not just for a low advertised price.

Check the normal path

Send one small request using the combo name. In the router’s request history, confirm that the request was received under that name and identify the provider and model that answered it.

The visible client label may remain the combo name. That label alone cannot tell you which underlying model completed the request. Keep the distinction clear when comparing response quality or cost.

If a request goes straight to a backup, inspect the primary route’s current state, quota, cooldown, and strategy. A successful final response can conceal a failed primary attempt. Record that failure instead of treating every completed response as a clean first-choice success.

Test the backup deliberately

Use an isolated test combo and a short, non-sensitive prompt. Temporarily make the primary route unavailable through a supported dashboard control, then send the test request. Do not invalidate a working credential, delete an account, or exhaust paid quota just to cause an error.

Confirm the primary was unavailable, the backup was chosen, and the client received a complete response. Restore the original setting immediately afterward and verify the normal route again.

If your installed version has no safe way to induce the condition, record fallback behavior as untested. Testing the backup directly is still useful, but it does not prove automatic failover worked. Do not present the two tests as equivalent.

Fallback and retries have different costs

Retries send another attempt; fallback changes the chosen route. Depending on where an error occurs, a provider may already have processed part of a request. A client can also retry independently of the router.

Compare request counts across the client, router, and provider before drawing conclusions about unusual usage. A single user action may correspond to several attempts. The provider’s billing record is the source for actual charges; a dashboard estimate is not a receipt.

Likewise, shorter output does not automatically mean the same work was completed more efficiently. Compare task quality, required corrections, and total attempts when evaluating token-saving options.

Maintain a useful chain

Recheck the combo after a model removal, provider policy change, or router upgrade. Keep a record of the last working versions and the model IDs you tested. Remove dead routes once you have verified they are no longer appropriate; do not keep them merely because they once appeared in a tutorial.

If every route fails, stop adding providers and identify the shared failure. A malformed client request, an oversized context, or the wrong protocol may fail across all routes. Use the layer-by-layer diagnostic guide to find that common cause.