Skip to main content

Semantic Cache

Semantic caching stores LLM responses indexed by the semantic meaning of the input. When a similar query arrives, the cached response is returned without calling the LLM — reducing costs and latency.

Quick Start

Configuration

Scope

How It Works

  1. Before calling the LLM, the input is embedded and searched against the vector store
  2. If a result exceeds the similarityThreshold, it’s returned as a cache hit
  3. Output guardrails still run on cached responses
  4. After an LLM call, the input + output are stored in the vector store (fire-and-forget)
  5. TTL is enforced on lookup — expired entries are evicted lazily

Events

Supported Backends

Any VectorStore implementation works: InMemoryVectorStore, QdrantVectorStore, MongoDBVectorStore, PgVectorStore.

Backend Examples

InMemory (Development)

Fast, zero-config. Cache is lost when the process restarts — ideal for development and testing.

Qdrant (Production)

PgVector (PostgreSQL)


Cache Hit vs Miss Behavior


Tuning similarityThreshold

Start with 0.92 and adjust based on your cache hit rate and quality.

Cross-References

  • Tool Caching — Cache individual tool results (different from semantic cache)
  • Cost Tracking — Semantic cache reduces LLM costs; track savings with CostTracker