What a hit costs
The discount applies to the whole request, input and output tokens, because no model ran at all. For a model priced at 4.00 output per 1M tokens:
So a request with 1,000 input + 500 output tokens bills 0.00085** as a hit. Every model’s exact cache-hit price is shown in the
dashboard’s model catalog (click any model).
This is a stronger discount than provider-side “cached input” pricing (the
OpenAI/DeepSeek prompt-caching model), which discounts only the repeated
input-prefix tokens while output still bills at full price. A response-cache
hit discounts everything; the trade is that hits require the entire
request to repeat byte-for-byte, and you opt into response retention.
Caching is a per-workspace setting, and cached responses are never shared
across workspaces: your cache entries are keyed to your workspace and are
only ever returned to requests made with your keys.
Enabling it
In the dashboard → Settings → Workspace → Response caching (owner/admin only):1
Turn on the toggle
Enabling takes effect within a few seconds across the gateway.
2
Pick a retention window
15 minutes, 1 hour (default), 6 hours, or 24 hours. Cached responses are
deleted automatically when the window expires.
What this stores: read before enabling
Omnia’s default posture is content-free: we never retain your prompts or completions. Enabling caching changes that, by your choice: model responses (including their content) are kept in encrypted cache storage, scoped to your workspace, for the retention window you chose, then deleted. Request prompts are never stored as-is (cache keys are one-way hashes). Nothing is stored while the toggle is off, and turning it off stops all reads and writes immediately (existing entries simply expire).What gets cached
A hit requires the request to be byte-identical: same model, same
messages, same parameters. Changing
temperature, adding a message, or
switching models produces a different cache key. Whether you set
stream: true or not does not change the key: a streamed request can be
served from a response that was first produced without streaming (it’s
replayed as a normal SSE stream), and vice versa.
Using fallback models? The fallbacks
list is part of the cache key, and only primary-served responses are
stored; a response produced by a fallback model is never cached, so a hit
always replays (and bills) the model the request asked for.
Per-request control
With caching enabled on the workspace, individual requests can still opt out with theX-Omnia-Cache-Control request header, useful for mixed workloads
(cache your eval suite and embeddings, keep production chat always-fresh):
Both directives answer with
X-Omnia-Cache: bypass, and the request bills as
a normal (uncached) request. Use no-store for a call whose response you
don’t want retained even though the workspace caches, for example a request
carrying sensitive data.
The header can only reduce caching, never enable it: with the workspace
toggle off it does nothing (there is no per-request way to opt in, because
enabling retention is a workspace-level decision).
How hits look
- Every cache-eligible response carries an
X-Omnia-Cacheheader:hitwhen served from cache,misswhen it went to the model. (Workspaces with caching off never see the header.) - Streamed hits replay as standard SSE chunks ending in
data: [DONE], with the usual usage chunk. - In your usage ledger (and CSV export), hits appear as normal rows flagged as cached, billed at 25% of what the same request cost uncached. Token counts shown are the original response’s real counts.