Metering and settlement
How AnonRouter bills from content-free usage metadata, and why that separates it from a conventional router.
Every model router has to answer one billing question: how much did this request cost, and whose balance does it come out of. The way a router answers that question decides how much it has to see. AnonRouter is built so the answer never requires reading your prompt or linking it to you.
The short version: a request is settled from a handful of numbers, token counts, latency, status, and cost, reported by components that can see your content or can identify your account, but never the same component both at once.
What a conventional router does
A conventional OpenAI-compatible router terminates your request in one place. It holds your API key, so it knows which account you are. It holds the prompt, because it forwards the prompt to the upstream provider. When the provider returns a response, the router reads the token usage from that response and bills your account.
Metering is easy for that design precisely because the router sits in the middle of your content and already knows who you are. That single position is also the privacy cost: the same component that meters you is technically able to read, log, retain, or hand over your prompts, because it has your identity and your content in the same process at the same time.
How AnonRouter meters instead
AnonRouter splits that one position into separate roles and settles from a prepaid reservation. No role holds both your identity and your content.
| Role | Sees content | Can identify account | Part in settlement |
|---|---|---|---|
| Control plane | No | Yes | Reserves a worst-case amount, computes the final cost, charges the account, and stores the usage record |
| Relay | Yes | No | Measures token counts and latency and forwards those numbers |
| Credential worker | Yes, to call the provider | No | Calls the provider and reads token usage from the provider response |
A text request settles in three steps.
- Reserve. Before the model runs, the control plane debits a worst-case amount from your prepaid balance, computed from the input size and the output ceiling on your ticket, at prices pinned to that moment. Pinning the prices means a catalog change cannot move the cost of a request that is already in flight.
- Measure. The relay hands the request to a credential worker, which calls the provider. The provider reports token usage alongside the response, and the relay and worker read the input, output, cached, and cache-write token counts and measure the latency. The prompt and the response stay on this path. They are not sent onward to the control plane.
- Settle. Only those numbers travel back to the control plane. Because the control plane created the reservation, it is the one component that can map the request back to your account. It computes the final cost from the pinned prices, charges the smaller of the actual cost and the reservation, releases the rest, and writes a single usage record.
Image generation is a flat price per image and speech is priced per character, so those requests settle by capturing the reserved unit price rather than a token-derived amount. Even the token counts are not needed to bill them.
Separation of roles, not just a logging rule
The content-free property comes from how the roles are split, not only from a policy that says "do not log." In the private ticket flow no single role holds both your identity and your content, so even a component that misbehaved could not by itself link who sent which prompt. Confidential (TEE) and end-to-end encrypted (E2EE) routes add cryptographic guarantees on top. See the privacy model for the full trust boundary.
What the usage record contains
Settlement writes exactly one metadata record per request. You can read your own
records back through GET /v1/usage.
{
"request_id": "req_...",
"model": "meta-llama/llama-3.3-70b",
"operation": "chat",
"input_tokens": 812,
"output_tokens": 143,
"cached_tokens": 0,
"cost_usd": 0.00042,
"status": "ok",
"latency_ms": 1180,
"created_at": "2026-07-30T12:00:00.000Z"
}The record never contains, and settlement never receives, the prompt or response text, system prompts, tool arguments or tool outputs, uploaded file contents, raw provider request or response bodies, or your API key. Those are enumerated in the privacy model. Model usage is charged at the displayed provider rate with no per-model markup. The service fee applies to buying credits, not to individual requests. See credits and payments.
A request can never overspend
Because the charge is always the smaller of the actual cost and the amount reserved up front, a settlement can only lower what was held. It can never raise it. Inference cannot take your balance negative, and a request cannot cost more than it successfully reserved from a prepaid balance. If a route fails after delivery has started but the exact usage cannot be recovered, the reservation is captured conservatively at its authorized ceiling rather than guessed from content.
How this differs from a conventional router
| Conventional router | AnonRouter | |
|---|---|---|
| Position in the content path | One component terminates the request | Split across a relay and a credential worker |
| Who links identity to content | The router does, by design | No single component does |
| What settlement needs | Your identity plus the response it already holds | Token counts and latency only |
| What is stored to bill you | Whatever that component chooses to keep | A metadata record with no content |
| Price movement mid-request | Possible | Prices are pinned at reserve time |
The point is not that a conventional router necessarily abuses its position. The point is that AnonRouter does not occupy it. Billing is reduced to numbers that are meaningless as content and are reported by parts of the system that cannot, on their own, tie those numbers to you.
Compatibility mode meters differently
Compatibility mode skips the ticket step, so the broker holds your key identity and your prompt together in memory long enough to meter and forward the request. It still logs metadata only and settles the same way, but it is not unlinkable like the ticket flow. Prefer the ticket flow when a client can perform it.
The upstream provider still processes content
Content-free metering at AnonRouter says nothing about what the selected model
provider does while serving the request. The privacy classification on each
route, anonymous, private, tee, or e2ee, describes that. See
models and privacy labels.
End-to-end encrypted routes
On an E2EE route the relay never sees your plaintext at all, so it cannot size a reservation from the input the normal way. Instead it bounds the worst case from the length of the ciphertext, and settlement still refunds the difference from the token usage the provider reports. The billing path stays content-free even when the content is encrypted end to end.