OmniRoute is a local AI gateway: it puts one OpenAI-compatible endpoint () in front of hundreds of providers, then routes requests between them with automatic fallback.
Install it, point your coding tool at , and it "just works." But "it starts" and "it works" are not the same thing.
A gateway that answers but falls over on streaming, tool calls, or a provider outage is decorative, not functional.
This article is a checklist for proving a fresh local install actually does its job before you wire a coding agent into it.
1.
Install and boot it The server boots on port , the dashboard opens at , and the API base URL is .
If you use pnpm, add the native build flags: .
A fresh install is zero-config: the free providers (OpenCode Free, Felo) are pre-wired into the combo, so a brand-new server answers out of the box with no API key.
2.
Run local diagnostics () OmniRoute ships a health checker that runs without starting the server: Treat this as the first gate.
If reports a broken runtime, native module, or DB issue, fix it before touching the network.
Other useful CLI probes:
3.
Verify the model list A connected provider should show up in .
If you've created an API key on the Endpoints page, query with it: A non-empty list means the gateway can see providers.
But don't stop here — a model list is not a working request.
4.
Smoke-test a real request The fastest end-to-end proof: You can also call a specific free backend directly (e.g. for OpenCode Free) to isolate one provider, then graduate to and let the router pick.
Each response carries an header naming the strategy, provider, and latency that served it — use it to confirm routing is doing what you expect.
5.
Test streaming Many tools depend on streaming.
Send the same request with : You should see chunks arriving incrementally rather than one blob.
A gateway that only works in non-streaming mode will break most agent CLIs.
6.
Test tool calling Coding agents live on tool/function calling.
Verify it round-trips: A valid reply should include a block with correctly structured arguments, not a plain-text answer pretending to be a tool call.
7.
Test fallback (the whole point) The reason you run a gateway is resilience.
To prove it: Create a combo on the dashboard with two or more providers.
Watch the header to confirm the primary provider is serving.
Intentionally break the primary (remove its key, exhaust its quota, or disable it), then repeat the request.
The request should still succeed, now routed to the next provider — silently, with no error surfaced to your client.
If it 500s instead, your fallback chain isn't wired the way you think.
8.
Point a real tool at it Once the API surface checks out, connect an actual agent: Or let OmniRoute write the config for you, per tool: Even simpler — launch a CLI through the gateway with no config written: Then do a real task (edit a file, run a tool) rather than a hello-world.
A finished task proves the whole pipeline.
Verification checklist Check Pass condition No failing checks Providers listed Plain chat Valid completion + header Streaming Incremental chunks Tool calling Structured in the response Fallback Request survives a dead primary provider Real agent task A coding CLI completes an actual edit When a check fails complains about a native module — reinstall with the correct build flags for your package manager.
Model list empty but provider shows connected — verify the key on the Endpoints page is the one you're sending.
Works non-streaming, breaks streaming — check timeouts; streaming stalls are governed by .
Fallback doesn't trigger — confirm the broken provider actually fails with an error OmniRoute can act on (4xx/5xx), and that the combo has more than one step.
Ten minutes of this checklist beats an hour of debugging why your agent silently "can't reach the model" in the middle of real work.