One secure control plane for your AI models, applications, routing policies, usage and failures.
OmniRouter sits between your product and every AI provider you use. It decides which model handles each request, recovers when a provider fails, and keeps a readable record of what happened — so an outage becomes a line in a trace instead of an incident.
The demonstration runs on a deterministic in-process provider. No external API key is required, and no request leaves the deployment.
The problem this solves
A team ships an AI feature against one provider. It works. Then the provider rate-limits at peak, or returns a 500, or triples in price, or a newer model becomes the better fit.
Now the provider call is spread across a dozen files, no one can say what a request actually cost, and adding a second provider means touching every one of them.
What OmniRouter changes
- Your application calls one endpoint and never learns which provider served it.
- Routing is a policy an operator edits in the interface, not a branch in application code.
- A provider failure triggers a classified, bounded fallback instead of an exception.
- Every request leaves a trace explaining the decision, the attempts and the cost.
- Credentials live encrypted in one place, behind virtual keys you can revoke.
Built like an operations tool, not a chat wrapper
Explainable routing
Eight selection strategies, each producing a stored explanation naming every candidate considered, every candidate rejected, and why.
Controlled fallback
Failures are classified into eleven categories before anything is retried. An authentication error is never hammered; a safety refusal is never shopped to another provider.
Request traces
Every request opens into a stage-by-stage timeline with per-attempt latency, tokens and cost — including the attempts that failed.
Virtual API keys
Per-application, per-environment keys stored only as a SHA-256 hash. Shown once, revocable instantly, scoped and expiring.
Usage analytics
Success rate, fallback rate, P50 and P95 latency, token volume and estimated cost — computed from real rows, not decorative charts.
Workspace isolation
Five roles enforced on the server. Provider credentials encrypted with AES-256-GCM. Content logging defaults to metadata only.
A routing decision you can read afterwards
Most gateways log which model they picked. OmniRouter stores why — as structured data attached to the request, including the candidates that were filtered out and the reason each one was dropped.
That record survives the policy that produced it, so a decision made last month is still explainable after the policy has been edited.
{
"strategy": "BALANCED",
"selectedCandidate": {
"modelLabel": "astra-fast",
"providerKind": "DEMO"
},
"reason": "Astra Fast scored highest
against the configured scoring
policy. 3 candidates were eligible.",
"rejectedCandidates": [
{
"modelLabel": "nimbus-reasoning",
"reason": "missing_capability",
"detail": "Does not support required
capability: vision."
}
],
"fallbackOrder": ["astra-pro", "local-ember"]
}See a provider fail and recover, in sixty seconds
Client Story Mode walks through creating an application, defining a balanced policy, sending a request, simulating a provider timeout, and watching the fallback succeed — with the trace open the whole time.
Start the guided demo