How privacy works

Most model gateways authenticate you and forward your prompt from the same place. That one system sees both your identity and your content, and usually logs the pair. AnonRouter is built the opposite way: it routes model requests so that no single component ever holds both who you are and what you sent, and it never writes prompts or responses to disk.

This page is the whole picture in one place: the idea, the ticket that makes it work, the request lifecycle, the guarantees, and where those guarantees stop.

The core idea: separate who from what

A private router is not about promising to be careful with your data. It is about arranging the system so the sensitive join never exists in the first place.

AnonRouter splits a request across roles that each hold only one half of it:

• The control plane knows who you are (your key, balance, and policy). It never receives your prompt.
• The relay sees what you sent (the prompt and response) but never learns your key or account.
• The provider worker holds the provider credential and the authorized payload, but never sees your account.

Because identity lives on one side and content on the other, neither side can say who sent which prompt. The single-use ticket is what lets them cooperate without ever introducing you to each other.

What a ticket is

A ticket is a short-lived, single-use authorization that stands in for your identity. You spend your key once, with the control plane, to obtain a ticket; you then hand the ticket (not your key) to the relay that actually serves the request.

Every ticket is:

• Opaque. It carries no readable account information.
• Single-use. It is redeemed exactly once and then rejected forever.
• Short-lived. It expires in roughly 30 seconds, so a leaked ticket has almost no window.
• Request-bound. It is minted for a specific model, a specific output-token limit, and a digest of the request's routing and reasoning policy. A ticket cannot be replayed against a different or larger request than the one it was issued for.

The lifecycle of a request

1. Authenticate once, privately. Your client calls the control plane at POST /v1/inference/tickets with your inference key, naming the model and output limit. The control plane verifies the key and confirms you can afford the request. See authentication and the quickstart for the exact calls.
2. Reserve, then mint. The control plane reserves the worst-case cost of the request (the most it could cost at the requested output limit) against your balance, then mints a single-use ticket bound to that request. This is the last point at which your identity and the request meet.
3. Redeem at the relay. Your client sends the completion to the relay with the ticket in the x-anonrouter-ticket header. The relay redeems the ticket once, checks that the request matches what the ticket was bound to, and never receives your key or account.
4. Fence the provider attempt. Before any provider call, the attempt is fenced with a one-time authorization, so the same ticket can never fan out into extra provider work.
5. Serve. The provider worker, holding only the provider credential and the authorized payload, calls the model provider and streams the response back through the relay to you.
6. Settle. Billing is finalized from usage metadata (token counts, status, latency) only. The reserved amount is settled to the real cost and the remainder released. Content is never read to bill. See metering and settlement.

Security properties

What is and is not retained

Operational records may contain account and credential identifiers, provider and model identifiers, token counts, estimated and final cost, request status and latency, request identifiers and timestamps, and billing, security, and rate-limit metadata.

AnonRouter does not intentionally persist prompt or response text, system prompts, uploaded file contents, tool arguments or outputs, raw provider request or response bodies, or API keys, session cookies, and authorization headers. API keys are shown once at creation and kept only as a hash.

Privacy classifications

Separating identity from content protects you at the router. It does not change what the model provider on the other end can do with the prompt while serving it. That is what the per-route privacy label tells you. Every route carries exactly one classification, and automatic routing never silently widens the set you allowed.

Compatibility mode: an explicit trade-off

Some clients cannot perform the two-step ticket exchange. Compatibility mode lets those clients send a static key straight to the API with no ticket. To do that, a broker must hold your key identity and your plaintext request together in memory long enough to mint a ticket internally and forward the request.

That broker logs metadata only and holds no database or provider credentials, but this flow is not unlinkable the way the ticket flow is, because your identity and your content briefly meet in one place. It is opt-in per key, so you choose it deliberately when a client needs it, and every other key keeps the unlinkable flow.

How this is different from a typical router

A conventional gateway, including OpenRouter-style routers, is a trusted middleman: it authenticates you and forwards your prompt from the same service, so it can always tie your account to your content, and you rely on its policy not to keep that link.

AnonRouter removes the need for that trust. The link is not merely unlogged, it is architecturally absent: the component that knows you never sees your prompt, and the component that sees your prompt never knows you. The ticket is the mechanism that lets those two halves serve one request without ever being introduced.