Semantic Cache

Reuse What Your LLM Traffic Already Answered by Meaning

Cloptima matches requests semantically to serve near-duplicate requests from a local vector cache that serves an answer only when the match is close, the entry is fresh, and the app is the one that stored it.

Start freeTalk to the founders
app.cloptima.ai/llm/policies
Semantic response cache
Namespace: support-copilot · similarity threshold: 0.92
Illustrative
Can I get a refund on an annual plan? — 0.95 similarity
model=claude-sonnet-5-5 · freshness: 4h · class approved
Cache hit (enforce)
How do annual subscription refunds work? — 0.93 similarity
model=claude-sonnet-5-5 · freshness: 2h · class approved
Cache hit (enforce)
What is your refund policy for enterprise? — 0.84 similarity
similarity below threshold · forwarded to provider
Cache miss
Semantic cache hit rate (observe)
19%
Approved cache classes
3
The problem

Exact match misses most of the repeat traffic

Exact-match caching only catches requests that are byte-for-byte identical, but a large share of repeat traffic is semantically identical: the same question asked in different words, or the same classification with different phrasing. Without semantic caching, that traffic re-runs the full model every time, driving up latency and provider token spend.

  • Byte-identical caching misses the larger population of near-duplicate requests
  • Identical user intents worded slightly differently incur full model latency and cost
  • Wrong-answer risk from serving a semantically 'close enough' response with no safety gate
  • Risk of unverified or low-fidelity vector representations serving cached responses
How it works

A strict safety gate on top of vector similarity

Cloptima matches requests semantically using local vector embeddings against previous responses. Semantic cache eligibility is a strict gate: a request only qualifies for a cached hit after passing namespace isolation, same-app matching, route and model matching, tool-schema matching, a close similarity match, and a maximum entry age. A served answer stored under another guardrail version is checked again before it is returned.

  • Near-instant local vector matching across semantic candidate entries
  • Monitor only: log would-be matches with zero behavior change
  • Serve: return an answer only after namespace, app, route, model, tool-schema, similarity, and entry-age checks pass
  • Answers stay inside the app that stored them
  • Guardrails re-check a served answer that was stored under an older guardrail version
Day one

Monitor first, serve second

Start the semantic cache in Monitor only. Review match quality and projected cost savings with zero traffic disruption. Move one app to Serve once confidence is proven, then widen.

Architecture

Outside the synchronous provider path

Candidate lookups run outside the synchronous provider path: a lookup returns fast, or the request goes on to the provider with no added latency floor. A hit replays through the same safety checks as the exact cache, never on raw vector proximity alone.

Get started

Launch path

Choose who pays for the embeddings: your Cloptima credits or your own embeddings key. Turn on the semantic cache in Monitor only to review match quality and simulated hit rate, then move a policy scope to Serve once the matches look right.

FAQ

Questions teams ask

Put your first governed call through in five minutes

Point your SDK at the gateway, bind a policy, and watch the first call land on the ledger.

No credit card required
5-minute setup
Free plan