Skip to content

Everything between your app and the model

Semantic Gateway is being built to cache by meaning, keep tenants apart, and show you exactly what each request did.

Semantic cachingIn progress

Match prompts by meaning instead of exact text, so a reworded question can return an answer that was already generated.

  • Embedding-based nearest-neighbour lookup
  • Configurable similarity threshold
  • TTL and manual retention policy

pgvector + Redis storageIn progress

Cached responses and their vectors are stored in PostgreSQL with pgvector; Redis handles hot-cache and infrastructure concerns.

  • Vector index plus response payloads
  • Scoped cache namespaces
  • Retention windows for prompts and responses

LLM provider integrationIn progress

Send requests to one endpoint. Cache misses are forwarded to the provider you configure.

  • OpenAI-compatible request shape
  • Configurable timeouts
  • Streaming passthrough is planned

API key managementPreview

Issue scoped keys per workspace, see the secret once, and revoke them at any time.

  • Keys shown only at creation
  • Per-key request attribution
  • Instant revocation

Multi-tenant architectureIn progress

Keys, cache entries, and logs are scoped to a tenant, so one team never receives another team's answers.

  • Tenant-scoped cache namespaces
  • Isolated logs and metrics
  • Owner and admin roles on the API

Request logs and analyticsPreview

Designed to show every request with its hit or miss result, similarity score, latency, and token count. The read APIs are not built yet.

  • Filterable request log
  • Hit-rate and latency trends
  • Provider usage breakdown

Some capabilities are labelled Preview because the underlying endpoint or user interface is still being completed. Status labels describe the build, not a release date.

Follow the build

Semantic Gateway is not open to the public yet. Leave an email to be considered for the private preview.

Demo form. Nothing is submitted, stored, or sent.