Privacy policy

1. Who this applies to

Prefill Systems, LLC ("Prefill Systems") operates an OpenAI-compatible inference gateway that serves the Qwen3.8-27B model (qwen/qwen3.8-27b). This policy applies to people who request direct API access and to approved evaluation customers ("you"). Distribution through OpenRouter is pending approval; when it is live, this policy will be updated to distinguish requests that arrive through OpenRouter, where OpenRouter's own privacy terms also apply to its users.

2. The short version

• Zero data retention: our policy prohibits persistent storage of prompts and completions. Transient prompt caching supports inference; content is not used for training. Policy scope is described in §3.
• We do retain metadata needed to evaluate access requests and operate the service: prospect, account, session/security, API-key, and usage/accounting records (§4–§7).
• No advertising and no sale of your information. The site uses basic aggregate analytics (Google Analytics 4) for page-view measurement; it runs no advertising trackers.

3. Prompts and completions: transient only

Requests travel over TLS to the public gateway and are processed by an inference worker. Inference requires transient prompt, output, and KV state. The gateway does not write request or response content to its database or logs, and streams responses without buffering them to storage.

• Zero data retention: request and response content is not persisted. Necessary operational metadata is retained separately.
• Prompt caching: transient tokens and KV state may be reused to reduce repeated processing, without persistent content storage.
• No training. Customer content is never used to train, tune, or evaluate models.

4. Access requests and account information

When you request access, we store your name, email, optional organization, expected token-volume range, use-case description, request status, and timestamps. Approved customers join by invitation. Their account also holds a hashed password (never the password itself), role, status, and timestamps. Invitation and recovery links are single-use and expire. Tokens are carried in the URL fragment, which browsers do not send in HTTP requests; the acceptance page removes that fragment from the current history entry.

5. Sessions and security metadata

Sign-in uses an opaque random session token stored in an HTTP-only cookie (Secure and SameSite-restricted in production) — it is never exposed to browser scripts. CSRF tokens protect authenticated actions. We keep administrative access-management audit events, credential timestamps and revocation state, and short-lived sign-in throttle counters. Disabling an account invalidates its sessions and stops its API keys from authenticating.

6. API keys

You create keys from your dashboard. The raw key is shown exactly once at creation; only a cryptographic hash and non-secret metadata (name, prefix, timestamps, revocation state) are stored. Each key is owned by one account and usage is attributed to that account and key. Revocation is immediate and permanent.

7. Usage and accounting metadata

Handled inference requests produce accounting records containing: request ID, start and end times, model, backend used and whether it was a fallback, HTTP status and error type, prompt/cached/completion token counts, timing measurements, finish reason, retry count, and the estimated charge at configured rates. This is how your dashboard reports usage and how we operate the service. No content is part of these records.

8. Cookies and local storage

We set one session cookie when you sign in (see §5). The site also loads Google Analytics 4, which sets its own first-party cookies for aggregate page-view measurement. A successful access-request submission records a generate_lead event without the name, email, organization, use case, or expected volume. No advertising identifiers are used. We do not use localStorage or sessionStorage for secrets. Raw API keys and invitation tokens are kept in page memory only, never in browser storage.

9. How information is used

Access-request data lets us evaluate demand, capacity needs, and whether to offer an invitation. Account and session data operates the service; usage and accounting metadata runs the service, detects abuse, and supports future billing. We do not sell personal information. Internal logs retain metadata, not inference content.

10. Sharing and processors

• Cloudflare — DNS and TLS-terminating ingress (Cloudflare Tunnel) for the public hostname.
• Operator-controlled servers — the gateway, PostgreSQL database, and Redis coordination store run on operator-managed hosts.
• Inference processing — operator-controlled GPU infrastructure that meets the data policy in §3.
• OpenRouter — not yet connected; the listing is pending approval. OpenRouter is a separate company with its own terms and privacy policy.

We do not disclose personal information to law enforcement except where legally required, and we do not sell it.

11. Retention

Prompt and completion persistence is prohibited by our operating policy (§3). Sessions and invitation/recovery credentials expire and are invalidated on use or revocation as applicable. Access requests, account, security, and accounting metadata remain in the operational database; an automated metadata deletion schedule is not currently implemented. Requests for access or deletion are reviewed manually, including any records that must be retained for legal or accounting reasons.

12. Security

Passwords use slow, salted Argon2 hashes. High-entropy API keys and session tokens are stored as cryptographic hashes. Authenticated mutations require CSRF tokens and same-origin checks; public ingress uses TLS via Cloudflare. Database and coordination services are on the private network. This is an invitation-only pilot; we make no SOC 2, ISO, or similar certification claims.

13. Your choices

• See your usage and keys any time in the dashboard.
• Revoke any key yourself, immediately.
• Change your password (this signs out all sessions).
• Ask us to close an access request that has not become an account.
• Ask for account deletion or a copy of your account data via the contact route.

14. Changes to this policy

This policy may be updated as the service evolves. Material changes will be published here and communicated to affected account holders through their established contact channel.