Inference data handling policy
1. Zero data retention
Our zero data retention policy prohibits persistent storage of prompts and completions. Transient processing and prompt caching support inference. Necessary account, security, and usage/accounting metadata is retained separately.
2. Content is transient
- In transit: requests and responses travel over TLS (Cloudflare-terminated ingress).
- During inference: requests are processed in memory and responses are returned without persistent content storage.
- Prompt caching: transient tokens and KV state may be reused to reduce repeated prompt processing. This does not create a persistent prompt archive or guarantee instantaneous memory erasure after each request.
- No training: customer content is never used to train, tune, or evaluate any model — ours or anyone else's.
3. Policy scope
Zero data retention applies to inference content, not the operational metadata described below.
4. Consistent handling
The same content-handling policy applies to every request we serve. Processing infrastructure must meet this policy before it can serve customer traffic.
5. Metadata that is retained
Five categories of non-content records persist. They do not contain prompt or completion text.
| Category | What is stored | Purpose |
|---|---|---|
| Access requests | Name, email, optional organization, expected token-volume range, use-case description, review status, timestamps | Evaluate direct API demand, capacity requirements, and invitations |
| Account | Name, email, hashed password, role, status, timestamps, hashed session tokens, hashed one-time invite/recovery tokens (expiring) | Identify who may access the service; sign-in; invitations |
| API keys | Hashed key material, name, prefix, created/last-used/revoked timestamps, owning account | Authenticate API calls; attribute usage per account and key |
| Usage / accounting | Request ID, timestamps, model, backend and fallback flags, HTTP status, error type, token counts (prompt/cached/completion), timings, finish reason, retry count, computed charge at configured rates | Usage dashboards, operations, abuse detection, future billing |
| Security | Authentication and authorization events with timestamps | Detect and investigate unauthorized access |
Internal logs follow the same rule: metadata, never content. Raw keys are shown once at creation and are never stored in plaintext; hashed session tokens are used instead of readable session IDs.
6. Retention periods
Prompt and completion persistence is prohibited. Sessions expire after twelve hours or are invalidated by logout, password reset, or account suspension. Invitation and recovery links are single-use and expire. Access requests, account, security, and accounting metadata remain in the operational database; an automated metadata deletion schedule is not implemented. Access and deletion requests are reviewed manually, including any legal or accounting retention requirements.
7. Where metadata lives
- PostgreSQL — durable accounting and account records on an operator-managed database host.
- Redis — ephemeral coordination state (concurrency slots, circuit breakers, traffic counters, and short-lived sign-in and access-request throttling counters). It does not store inference content or raw credentials.
- Operator infrastructure — application logs hold metadata only.
8. OpenRouter distinction
When OpenRouter distribution goes live, requests from OpenRouter users arrive at this gateway through OpenRouter's platform. OpenRouter is a separate company: its privacy policy and terms govern its relationship with its users, and our content-handling rules in §2 apply to every request we serve regardless of channel. Direct pilot customers have their own accounts and dashboards; OpenRouter users do not get dashboard accounts here.
9. Requests for deletion or information
Prospects can ask to close an access request that has not become an account. Invited customers can revoke their own keys and request account information or deletion through the contact route. Revocation is not deletion: key metadata remains for usage attribution and security history. The operator will explain which requested records can be removed and which must remain.
10. Changes
Version 0.1, September 2026. This policy may be updated as the service evolves; material changes will be published here.