Skip to content

throughput

0.92 Default similarity threshold

Semantic Caching

Cache the meaning, not just the text

Semantic caching compares the meaning of a request, not its exact bytes, so near-duplicate prompts are served from cache. Queries are embedded and matched against an HNSW index in PostgreSQL with pgvector; a hit above the similarity threshold returns instantly without a billable provider call.

What you get

Everything in the box

  • Vector similarity matching (cosine)
  • Configurable similarity threshold (0–1)
  • TTL-based expiration for cached entries
  • PostgreSQL pgvector + HNSW index
  • Embeds and serves before a token is billed
Full configuration in the docs
config.yaml
# Semantic cache configuration
  similarity_threshold: 0.92      # cosine similarity (0.0–1.0); higher = stricter
  ttl_seconds: 3600               # entry time-to-live
  vector_dimensions: 1536         # must match the embedding model output
  embedding_model: text-embedding-3-small

When to use it

When to reach for this

FAQ and support assistants

Support bots field the same questions in countless phrasings. Semantic caching serves the repeats from cache so only genuinely novel questions reach the model.

High-traffic, repetitive prompts

When many users ask near-identical things — product lookups, definitions, boilerplate generation — caching the meaning collapses duplicate spend without changing your app.

Latency-sensitive surfaces

A cache hit returns before the provider would even start streaming, so repetitive queries on a latency-critical path feel instant.

Cost control on expensive models

Pair a high similarity threshold with an expensive model so only sufficiently-novel prompts incur the premium per-token cost.

FAQ

Frequently asked questions

How is semantic caching different from a normal response cache?

A normal cache keys on the exact request body, so reworded-but-equivalent prompts miss. Semantic caching embeds each query into a vector and matches on meaning, so near-duplicate prompts can share a cached response.

What backs the semantic cache?

PostgreSQL with the pgvector extension, using an HNSW index for fast approximate nearest-neighbour search over the stored embeddings. It is not a separate vector database.

How do I control how aggressively it caches?

With similarity_threshold (default 0.92). Raise it for stricter matching and fewer false hits; lower it to increase the hit rate at some cost to precision.

Will the cache return stale answers?

Entries expire after ttl_seconds (default 3600). Tune the TTL to balance freshness against hit rate for your content.

How much will it save me?

It depends on how semantically repetitive your traffic is, your threshold, and the models you use. Every hit removes a billable provider call, so the more repeated intent your traffic carries, the larger the saving.

Related features

Feature deep dives

Ready to deploy?

Stand up your AI gateway in minutes — open source, Apache 2.0, no credit card.