Questions, answered.

No. You only need to change the base URL and add a Gateway API Key. No changes to your prompts or code are required. qache automatically places cache_control breakpoints, but only where they deliver real savings on future requests. It can also restructure prompts and reduce latency, so the overall benefits justify the cost of those breakpoints (this is enabled by default and can be turned off per tenant).

The application still sends provider keys using the provider's normal auth path.

Yes. qache is designed to be transparent. You can continue using the official SDKs; just update the base URL and add the X-Qache-API-Key header.

qache is currently free to use. You can create a Gateway API Key at no cost and start routing traffic through it immediately.

Yes. You can run the gateway locally against a local or remote provider for development and testing.

Create a separate tenant for each environment. Each tenant has its own API keys, analytics, and settings.

Yes. For teams that need prompts and traffic to stay in-house, qache can run entirely in your own infrastructure, so your data never leaves your perimeter. Self-hosted deployments are arranged on a case-by-case basis. Tell us about your environment on the enterprise page and we'll follow up.

qache analyzes the shape and structure of your prompts (plus arrival patterns) to automatically place cache_control breakpoints where they are most effective.

Adding cache_control to every message is often counterproductive. On some providers it increases costs when creating cache entries, and many parts of prompts are too variable or appear too late to benefit from caching. qache automatically determines where breakpoints are actually worth the cost based on your real traffic patterns. It can also restructure prompts and reduce latency, delivering better economics than blanket caching.

qache detects caller-set markers on the wire (Anthropic cache_control, OpenAI cache_control / prompt_cache_key, and Gemini cachedContent) and forwards those requests to the provider unmodified. The gateway will not add, move, or strip your markers. The decision is per request: calls that carry a marker pass through, while your other calls still get qache's automatic breakpoint placement and rewrites. Pass-through requests appear on the dashboard as passthrough · client_cache_control so they're easy to spot.

Yes. Prompt restructuring is enabled by default but can be disabled per tenant in the dashboard settings.

On a cache hit, the provider returns cached content (faster and cheaper). On a miss, the full prompt is processed normally by the provider.

Overhead is minimal. In practice, cache hits usually result in significantly lower end-to-end latency and cost.

OpenRouter offers basic prefix caching. qache performs deeper prompt shape analysis, automatic breakpoint placement, and optional rewriting for significantly higher hit rates.

Those tools are primarily for testing, evaluation, or thin SDK wrappers. qache is a production-grade gateway focused on automatic, high-performance caching at scale with minimal code changes.

The dashboard shows request and token volume, cache hit rate, and estimated savings, with filters by API key and time window.

The dashboard shows your cache hit rate, token usage, and estimated savings over time. Each response also carries the provider's own usage figures, including cached-token counts, and qache forwards provider responses unchanged, so that accounting reaches your application intact. qache also attaches an x-qache-request-id response header you can keep to reference a specific request.

Yes. The dashboard breaks savings down by model, API key, and time period.

Yes. qache fully supports streaming. It passes through the stream while still performing analysis and placing cache breakpoints.

Yes. Tool calls and function calling are passed through to the provider. qache focuses on the surrounding prompt structure for caching.

No. Per-request endpoint overrides (api_base, base_url, user_config) are rejected at ingress for consistency and security. To route to a specific provider (including OpenRouter, Vertex AI, or Amazon Bedrock), prefix that provider's base URL with the qache gateway host; the provider is determined by the URL itself, not a per-request field.

qache supports OpenAI, Anthropic, Google Gemini, OpenRouter, Grok (xAI), Vertex AI, and Amazon Bedrock. You route to any of them the same way: prefix that provider's base URL with the qache gateway host. Need a provider that is not listed? Request it from the dashboard or support.

Not yet. qache currently focuses on text-based LLM requests.

Embeddings are not currently supported.

Audio and speech-to-text models are not currently supported.

Model routing lets qache pick the model for a request, choosing from a cost-accuracy frontier built from your eval: a cheaper model where it holds up, a stronger one where it's needed. The choice happens within the egress you already authenticated; qache reuses that aggregator's credential and never crosses to a different provider. Routing is opt-in (you turn it on per request with the X-Qache-Router header) and orthogonal to caching, so a routed request still gets qache's automatic cache breakpoint placement.

Routing is available only on the aggregator egresses (OpenRouter, Vertex AI, and Amazon Bedrock), because picking a model means reusing one aggregator credential across several models. A router named on a direct single-provider route (or a URL-prefix forward-form request) is rejected with routing_unsupported_egress; routing is never applied silently on an unsupported egress.

It returns a 529 with a Retry-After header before any model runs, so you back off and retry (the Anthropic SDKs already do this automatically). A 529 means “retry shortly,” not a silent passthrough of your original model. (A request the router can't classify is different; it falls back to a model rather than returning a 529, covered next.)

On a confident match, the router runs the model its eval assigned to that kind of request (x-qache-router-decision: routed). On a miss, or if the classifier is briefly unavailable, it falls back rather than guessing: it uses the model you sent on the request, or a default model you've configured for your key or tenant, and reports routed_default. If you've set neither, the request fails fast with a clear error instead of going to an unintended model.

For platform routers, no. Any key, including a no-login ak_ agent key, can use a platform-global router just by adding the X-Qache-Router header on an aggregator route. To create and run your own router you do need the dashboard: open /dashboard/routers, pick a point on the frontier, and create the router. Once created, every key under the same owner can use that router's r_… id.

A custom router is built from an evaluation set that reflects your real traffic and what “good enough” means for your workload. Bring your own evals or we'll help you build them, then you publish a router from the /dashboard/routers page. Because each workload needs a little setup, routing for production traffic starts as a guided pilot: request routing access and we'll follow up.

No. By default qache processes prompts in memory and does not store prompt bodies. Body storage is controlled by one dashboard toggle, “Request improvement suggestions,” set per tenant. When it is on, qache retains canonical request bodies for that tenant so it can generate offline improvement suggestions; when it is off (the default), no prompt content is persisted. Because the toggle is per tenant, you can opt one environment in without affecting the others.

By default, not at all: qache follows a zero-data-retention model and does not persist prompt bodies. They are retained only if you enable “Request improvement suggestions” for a tenant, and then only for that tenant's retention window, configurable per tenant, 14 days by default and 90 days maximum. Once the window elapses the retained bodies are deleted.

qache is not yet SOC 2 or HIPAA certified. For enterprise compliance use cases, please reach out to discuss your requirements.

Creating a tenant in the dashboard issues its first API key, shown once right after creation; copy it then and store it securely. You can add more keys to a tenant anytime.

Yes, a tenant can have several API keys; add them from the API Keys page. To isolate services or environments, create a separate tenant for each, and every tenant has its own keys, analytics, and settings.

Revoke the affected key in the dashboard; it stops working immediately, while the tenant's other keys keep running. Historical analytics are preserved. Add a new key to the tenant for replacement traffic; deleting the whole tenant revokes all of its keys at once.

Add a new API key to the same tenant, point your application at it, then revoke the old key once traffic has moved. Both keys work side by side during the switch, so there is no downtime.

Yes. An autonomous agent can POST to /api/v1/public/agent-keys (no sign-in, no body) and receive an ak_ key it can use immediately, through the same X-Qache-API-Key header as a dashboard qk_ key. Agent keys enable every feature, so prompt bodies are retained by default to power suggestions, the one exception to qache's zero-data-retention default. A human can claim the key later to turn that off.

On the API Keys page choose Add an existing key, paste the ak_ key, and name the tenant. The key keeps working unchanged; claiming it attaches its traffic to your account and lets you manage it like any other key. A key must have been used at least once before it can be claimed, and it can only be claimed by one account.