Skip to main content
The Omnia gateway is a single OpenAI-compatible endpoint that sits in front of many models across multiple clouds. Your application never talks to a provider directly; it talks to Omnia, and Omnia handles routing, metering, billing, and (when you opt in) capture for the rest of the improvement workflow.

​
One endpoint, every model

The base URL for all inference is:
You select a model by its id in the request body, and the id decides the route: Switching models is a one-string change: no new SDK, no new endpoint.

​
OpenAI compatibility

Omnia implements the standard OpenAI request and response shapes:
  • POST /v1/chat/completions: chat + vision
  • POST /v1/embeddings: embeddings
  • POST /v1/responses: the Responses API
  • POST /v1/rerank: reranking
  • GET /v1/models: the models you can call
Streaming, tool calls, and JSON mode behave the way your existing OpenAI code expects, and unknown parameters are ignored rather than erroring. In most cases, pointing your client at Omnia’s base URL and swapping the key is the only change you make.

​
What happens on each request

1

Authenticate

Your API key resolves to a workspace. A missing or revoked key is rejected with 401.
2

Resolve the route

Aliases resolve to their target (or canary arm), dedicated/ prefixes to your endpoint, catalog ids to shared capacity.
3

Gate on balance

For per-token models, Omnia places a hold against your wallet sized to the request’s worst-case cost. If your balance can’t cover it, the request is refused with 402 before anything runs.
4

Serve from cache, if you opted in

With response caching on, a byte-identical repeat within your retention window is served from the gateway’s cache at 25% of the normal price. X-Omnia-Cache: hit|miss says what happened.
5

Route, infer, fall back

The request is forwarded to the model; streams relay token by token. If you passed fallbacks (up to 2 backup models), the gateway retries them in order on upstream failure and reports which model actually answered.
6

Meter and settle

The exact tokens produced, including partial output on a cancelled stream, are metered and settled idempotently against the request id. Never billed twice, never billed for nothing.
7

Capture, if you opted in

With request logging enabled, the exchange is secret-scrubbed and stored under your retention window, where grading, judges, evals, and datasets can reach it. Off by default; telemetry without it stays content-free.

​
Label as you go

Two optional request headers thread through everything downstream, with no SDK changes:
  • X-Omnia-Tag names the task (“support”, “extraction”). Tags become filters in logs, populations for judges, and scopes for datasets and evals.
  • X-Omnia-Trace-Id groups the steps of one agent run or conversation, so a multi-step run can be read, graded, and judged as a whole.
Untagged traffic still gets grouped automatically by segments.

​
Two ways to run models

Shared (per-token)

The default. Pooled capacity, billed per input/output token. Ideal for most workloads: no provisioning, pay only for what you use.

Dedicated (per-GPU-hour)

Private GPU capacity for a specific model, billed per GPU-hour while running. For guaranteed throughput, isolation, or serving your own fine-tuned models.
Being in the request path is what makes the gateway the richest of the four integration paths: the same hop that routes and bills also gives you caching, fallbacks, canary splits, and capture, with nothing else to run.