Proxy cache for paid APIs

Cache paid API calls. Skip repeat charges.

Put ZeroCostCache in front of OpenAI, Maps, Search, or any paid API. The first request goes upstream. Matching repeat requests return from cache.

2.5s -> 20ms

repeat latency

1 -> 0

repeat upstream calls

stored API keys

Start with one endpoint. No backend rewrite. No permanent API key storage.

Same request, second time

POST /proxy/openai/summary

First request

upstream called

MISS

2.5s

Your app

ZeroCostCache

OpenAI

Repeat request

upstream skipped

HIT

20ms

Your app

ZeroCostCache

Cached response

Cache only routes that are safe to reuse. Bypass anything user-specific, sensitive, or stale.

Cache miss vs. cache hit

The logic is simple: fetch once, reuse safely.

ZeroCostCache only helps when a response is safe to reuse. Fresh or sensitive requests can still go straight to the provider.

1. Cache miss

First request goes upstream

ZeroCostCache checks for a matching cached response. If none exists, it forwards the request to the paid API.

GET /proxy/openai/summary
cache: MISS
upstream: called

2. Store by policy

Response is saved with rules

The response is cached using your TTL, bypass rules, and request fingerprint. Sensitive routes can opt out.

ttl: 10m
key: hash(method + url + body)
store: response only

3. Cache hit

Repeat request skips the provider

A matching request returns from ZeroCostCache. No upstream call is made unless the cached response is stale.

GET /proxy/openai/summary
cache: HIT
upstream: skipped

Technical utility

Use it where repeat API calls are measurable.

ZeroCostCache is not for every endpoint. It is for routes where the same request appears often enough to affect cost or latency.

LLM token savings

Cache repeated summaries, classifications, extraction jobs, and prompt outputs where the same input can reuse the same response.

OpenAI / Anthropic / Gemini

Maps and search latency

Return repeated geocoding, place search, SERP, and lookup responses without waiting on the provider every time.

Maps / Search / Places

Shared cache policy

Move TTLs, bypass rules, and request hashing out of scattered app code and into one proxy layer.

TTL / bypass / hash keys

Security manifesto

A proxy deserves scrutiny.

Developers should be skeptical of anything between their app and a paid API. ZeroCostCache is designed around that concern.

cache:
  store_api_keys: false
  key_source: request_hash
  bypass: auth_user_routes
  ttl: route_defined

We do not store API keys.

Keys are used to forward the request and are not persisted by the cache layer.

Cache keys are request fingerprints.

Matching is based on deterministic hashes of approved request parts, not raw secrets.

Sensitive routes can bypass cache.

User-specific, authenticated, regulated, or high-risk endpoints should be excluded by rule.

TTL is explicit.

Cached data expires based on route-level policy. No hidden retention window.

Cache behavior should be visible.

Each request should show cache status, upstream status, and latency.

Beta access

Start with one endpoint.

Bring one repeated, expensive route. We will help you decide whether it should be cached, bypassed, or left alone.

Early accessPrivate beta

Good fitrepeat paid API calls

Setupone route first

Sales callnot required

Private beta

Test ZeroCostCache on one expensive endpoint.

Join the private beta with one route that has repeat traffic. We will help evaluate cache safety, TTL, and expected savings.