Docs
Send your first request.
qache sits in front of the LLM APIs you already use. Routing through it is a one-line change to your base URL, and reads cleanly whether you open this page in a browser, with curl, or from an automated client.
1. Get an API key
There are two ways to get a key; both authenticate the same X-Qache-API-Key header.
Dashboard key (qk_), for humans. Create a tenant in the dashboard and generate a key. Full observability from the first request, and prompt bodies are not retained by default (ZDR). Start with a repeat-heavy workload so caching behavior and savings are easy to verify.
Agent key (ak_), for agents with no sign-in. Send POST https://operations.qache.cc/api/v1/public/agent-keys and use the returned key immediately. Agent keys enable every feature, so prompt bodies are retained by default (the one exception to ZDR) to power suggestions. A human can later add the key to their dashboard to manage it and watch its traffic, and the key keeps working unchanged.
2. Point your client at qache
Two things change. First, the base URL: take your provider’s base URL and replace https:// with https://gateway.qache.cc/. The host, path, request body, and your provider credentials all stay the same.
# your provider's base URL https://openrouter.ai/api/v1 # through qache: prefix it with the gateway host https://gateway.qache.cc/openrouter.ai/api/v1
Second, add one header, X-Qache-API-Key, set to the qk_ or ak_ key from step 1. Your provider credential keeps travelling on its normal header (Authorization, x-api-key, or X-Goog-API-Key).
Building requests by hand instead of using an SDK? An opt-in transport wrapper for Go, Python, and JS (with fallback to the upstream when qache is unreachable) is documented at /docs/clients.md.
qache can automatically optimize prompts for better caching by placing cache breakpoints and lightly restructuring them. These optimizations are on by default and can be disabled per tenant.
3. Provider reference
The same rule routes every supported provider: prefix the native base URL with https://gateway.qache.cc/:
# OpenAI provider base https://api.openai.com/v1 # OpenAI through qache https://gateway.qache.cc/api.openai.com/v1 # Anthropic provider base https://api.anthropic.com # Anthropic through qache https://gateway.qache.cc/api.anthropic.com # Gemini API provider base https://generativelanguage.googleapis.com # Gemini API through qache https://gateway.qache.cc/generativelanguage.googleapis.com # OpenRouter provider base https://openrouter.ai/api/v1 # OpenRouter through qache https://gateway.qache.cc/openrouter.ai/api/v1 # Grok (xAI) provider base https://api.x.ai/v1 # Grok (xAI) through qache https://gateway.qache.cc/api.x.ai/v1 # Vertex AI provider base https://LOCATION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/endpoints/openapi # Vertex AI through qache https://gateway.qache.cc/LOCATION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/endpoints/openapi # Amazon Bedrock provider base https://bedrock-mantle.REGION.api.aws/v1 # Amazon Bedrock through qache https://gateway.qache.cc/bedrock-mantle.REGION.api.aws/v1
Every request parameter you send (model, temperature, tools, streaming, and the rest) is forwarded to the provider unchanged. Vertex AI and Amazon Bedrock carry their project, location, and region in the URL itself, so reaching them is the same one-line change as any other provider, with no qache-specific headers.
4. Check the result
Every gateway response carries an x-qache-request-id header, so you can reference a specific request later. Provider usage figures, including cached-token counts, pass through unchanged, so your application accounting stays intact. The dashboard shows your request and token volume, cache hit rate, and estimated savings, filterable by API key and time window.
5. Route to a faster or cheaper model (beta)
Optional. On an aggregator route (OpenRouter, Vertex AI, or Amazon Bedrock), qache can pick the model for each request, within the egress you already authenticated. Add a platform router's id as a header, X-Qache-Router: r_… (ids are listed in the dashboard); no sign-in is needed, so even a no-login ak_ agent key can use one.
Routing applies only on an aggregator egress; a router named on a direct single-provider route is rejected with routing_unsupported_egress, never applied silently. The response carries x-qache-router-decision: routed when the request matched a shape, or routed_default when it didn't.
On a match, the router runs the model its eval assigned to that request. On a miss, it falls back, in order, to the model you sent, then a default model you've configured for your key or tenant; if neither is set the request fails fast rather than going to an unintended model. If qache is overloaded it returns 529 with Retry-After before any model runs, so retry shortly.
Want a router tuned to your own evals and quality bar on your real traffic? That's a guided pilot: request routing access.