Zero conversation logs
Your conversations are not on our servers
Prompts and completions pass through memory and are gone when the request ends.
Not "we promise not to look". There is no step in our servers that writes it down in the first place.
Most relay privacy policies say some version of "we will not misuse your data" — a promise about intent. Ours is a different kind of statement: request and response bodies exist in process memory and are released with the connection, and no code path writes them to a disk, a database or a log. So there is no "we promise not to look" stage, because there is nothing to look at. What survives is the five fields billing and debugging require, and not one of them contains conversation text.
How it actually works
- Prompts and completions never hit disk
- Relayed in memory and released when the connection closes. Access logs carry request IDs and status codes, not conversation bodies — our own engineers with full access cannot pull up what you said.
- Exactly five fields survive
- Request ID, model name, token counts, timestamp, status code. Billing needs them, debugging needs them, and there is nothing else. That list is published and does not quietly grow.
- Not trained on, not passed on
- We do not train models, so your data has no second use to us, and we do not hand traffic to any third party that does. Your data does not become someone else’s capability.
- Scoped per key, encrypted end to end
- TLS 1.3 from your client to the inference node, and between our internal services too. Every key gets its own quota, permissions and usage ledger — leak one and you revoke it instantly without touching the others.
Check it yourself
None of these four steps need us. You can run them right now.
- 1
Send us a request ID and ask for the complete record of that call. What comes back is those five fields — no conversation body, because there is none.
- 2
Export the usage detail from the console and check it against the published field list. Look for anything extra.
- 3
If it needs to be contractual, sign the data processing addendum and turn "not written, not retained, not trained on" into a clause you can enforce.
- 4
For proprietary models, check upstream: our side treats every model identically, but vendors differ — Claude Opus 5 supports zero data retention while Claude Fable 5 currently carries a 30-day requirement. We state it on each model page.
The follow-up questions
Then how do you debug anything?
With request IDs, status codes, token counts and timestamps. The overwhelming majority of problems — timeouts, rate limits, malformed parameters, upstream faults — resolve from those plus your reproduction steps. When we genuinely need the content, we ask you to paste that request rather than going and reading it out of a store.
What happens under a legal or regulatory demand?
We can only produce what we actually hold, which is those five fields. Conversation content is not among them because it never existed. That is not a policy choice; it falls out of the system design.
Does this cover proprietary models — Claude, GPT, Gemini?
On our side, yes, identically for open and proprietary models. But the request does reach the vendor, and their data handling is governed by their own terms, which we cannot promise on your behalf. Where compliance is strict, prefer a model that supports zero data retention — we note that on every model page.
The other commitments
Don’t trust this page — test it
Take the trial credit and work through the verification steps above one by one. Anything that does not line up, send us the request ID.