For developers shipping apps that call AI models
Give every app its own key. Keep the real provider keys off every app.
The request path. Example labels, not live traffic.
knectar is a gateway you host. Each app gets one virtual key. The real provider keys stay on the gateway, and a request can fall back to a second model when the first one fails.
Built, not yet serving traffic. No app is wired to it today.
How it works
One key in. Real keys out.
Your app holds one virtual key. The gateway holds the rest.
The app sends its virtual key. The gateway swaps in the real key and calls provider A.
Click a path, or watch it cycle.
The usual setup puts a provider key in every app. One leak means rotating all of them.
With knectar, cutting off one app is deleting one virtual key. The provider keys never move.
What it does
Built, partial, or not built.
Each item carries its status from the repo. Nothing here is a promise.
- Built, not deployed
Virtual keys
One per app per environment. Mint, rotate and delete from the portal.
- Built
Server-side provider keys
The real keys live in the gateway secret store, never in your app.
- Built, untested
Fallbacks
A second and third model named per request. Retried on the gateway.
- Built, not run end to end
Cache
Opt in per request with one header. Exact or similar match. Scoped to your org and key.
- Built, not deployed
Logs
One row per request. Model, latency, tokens, cost. Filter by key, model and status.
- Partial
Budgets and rate limits
Per-key budgets in the gateway. Rate limits at the edge.
- Not built
PII stripping
Remove personal data from a prompt before it leaves.
- Not built
MCP bridge
Tools reachable through the gateway.
- Not built
Zero retention
Today the log keeps request and response content for 90 days. Turning that off is a pending decision.
No app is wired to it yet. It is not serving production traffic.
Join the waitlistSafety
What it never does.
Design rules, each with the mechanism that makes it true.
- 01
Hand a provider key to an app
Apps get a virtual key. The provider keys sit in the gateway secret store and are read at boot.
- 02
Open the admin plane to the internet
The public host serves the inference routes and a health check. The dashboard and admin API answer only on the private network.
- 03
Cache without being asked
Nothing is cached unless the request carries the cache header.
- 04
Serve one org a cache from another
Cache reads and writes pass through a proxy that fails closed and opens only that org's own collection.
- 05
Let two apps share a key
One virtual key per app per environment, named after both. That is how logs and budgets stay separate.
- 06
Lock your app in
Every app keeps a bypass flag. Switch it off and the app goes back to its own provider keys.
Not yet true: it does not scan prompts for personal data, and it does not keep content out of the log. Both are listed above as not built.
Join the waitlistPairs with rflectr
The desktop half and the cloud half.
rflectr runs on your machine and records every request your coding agents make. knectar runs on your server and holds the keys your apps use. Two ends of the same request.
See rflectr- On your machine rflectr Records agent requests. Your login stays yours.
- On your server knectar Holds provider keys. Your apps get virtual keys.
Compatibility
What the gateway accepts.
From the integration guide, read 17 September 2026. Every row is documented and untested. No claims beyond it.
| Client | Base path | Key goes in | Notes |
|---|---|---|---|
| OpenAI SDK | /openai/v1 | apiKey | The SDK appends its own paths. Nothing else changes. |
| Any OpenAI-compatible client | /v1 | Authorization: Bearer | Raw HTTP, LangChain, Vercel AI SDK. |
| Anthropic SDK | /anthropic | apiKey | Sent as x-api-key. Beta headers must be allowed on the gateway first. |
| Gemini and Vertex | /genai | same key | Google native surface. |
| Health check | /health | no key | Liveness only. Not an inference route. |
Model names
Every model is written provider/model, in the request and in fallbacks.
Accepted key headers: Authorization Bearer, x-api-key, x-bf-vk.
openai/gpt-4o-minianthropic/claude-3-5-haiku-20241022gemini/gemini-2.0-flashgroq/llama-3.3-70b-versatileopenrouter/<vendor>/<model>
- openai Configured. No key loaded.
- anthropic Configured. No key loaded.
- gemini Configured. No key loaded.
- groq Configured. No key loaded.
- openrouter Configured. No key loaded.
Waitlist
Join the knectar waitlist.
Leave your email. One email when a key can be minted for your app. Nothing to pay or install today.
FAQ
Before you wire an app.
Does my app have to change?
Three things. The base URL, the key, and the model name, which gets a provider prefix. The SDK stays the same.
Where do the provider keys live?
In the gateway secret store, read at boot. Not in your app, not in your repo, not in the browser.
Is it running now, and what does it cost?
The gateway and the admin portal are built. No app is wired to it and it is not serving production traffic. Pricing is not set. The waitlist hears first.
Does it strip personal data from prompts?
No. There is no prompt scanner in the current build. Do not plan on one until it is listed as built.
What does it keep in the log?
Today, request and response content for 90 days, plus model, latency, tokens and cost. There is a switch to stop storing content. Whether it is on by default is not decided.
Can I turn it off in an emergency?
Yes. Each app keeps a flag. Switch it off and the app calls its provider directly with its own keys.
Is it open source?
The gateway core is Bifrost, open source under Apache 2.0, pinned to one commit. The knectar layer (tenancy, keys, portal) is closed for now.