Routes

A route is a name such as odnoga/smart that stands for an ordered list of models. Your code sends the name instead of a model; odnoga tries the models in order and moves to the next one when a provider fails. You change the models in odnoga — the code never changes, and nothing changes without you: every response names the route and version that served it.

Create a route

Workspace → Routing → Routes → New route.

1. Give it a name: odnoga/ plus lowercase letters, digits, dots, dashes or underscores.
2. Start from a suggestion built from your own catalogue and prices — Cheapest that works, Fast, Strongest, EU only; each takes one model per provider, so one provider outage never stops the route — or add models from the list. Model names are never typed.
3. Drag the models into order (or use the arrows). What a request does shows exactly what the gateway will do — it is worked out by the same code the gateway runs.
4. Create it, then send its name as the model:

POST https://api.odnoga.com/v1/chat/completions
{ "model": "odnoga/smart", "messages": [{ "role": "user", "content": "Hello" }] }

Every save is a new version with who made it and why. History shows every version and restores any of them as the newest one. Changes reach every request within 15 seconds.

Connect a route to a function

Different processes need different models. A function that sends the x-odnoga-app and x-odnoga-function headers appears in odnoga after its first call; on a route, Connect function picks it. From then on every call from that function is served by the route, whatever model its code sends — you switch a process's AI here, without a code change. The route card lists the functions it serves (Used by).

• One route per function; connecting it to another route moves it.
• A call that is part of a running prompt A/B test keeps the model being tested.
• A route never takes a call of another kind: a chat route never serves an embeddings call.
• Archiving a route sends its functions back to the model their code sends.

What every response says

The same is recorded on every request (Requests → the request → route).

Rules a route follows

• 1 to 8 models, no duplicates, each serving today and allowed in this workspace.
• One kind of call: chat models and embedding models never mix. Image and audio models are not routed yet.
• Every model is checked against the workspace's Allowed models; one that is not allowed is left out, and the preview says so.

Automatic chain and per-model fallbacks

On the same page: the automatic chain is what {"model": "auto"} uses, and the fallback for any model without its own; fallbacks for a specific model say which models answer when that one fails. Both are edited with the same picker.

Plans

An organisation that leaves Growth keeps what it made: its named routes keep serving and their functions stay connected. They become read-only — archiving a route and disconnecting a function still work; creating, changing, rolling back, restoring and connecting answer Named routes is included from the Growth plan until the plan includes them again.

Errors

With AI tools (MCP)

Connected assistants use the routes.* tools: routes.guide explains everything above and the safe order of calls; routes.models lists the models a route may use; routes.preview shows what a request would do; routes.save refuses to overwrite a change someone else made meanwhile. See MCP.