Metering and settlement

AnonRouter reserves funds before a paid request runs and settles from usage metadata afterward. The control plane needs token counts, the serving route, status, and prices to bill you; it does not need your prompt or response text.

Reserve, measure, settle

1. Reserve. AnonRouter holds funds from your prepaid balance using an input bound, the authorized output budget, and the permitted provider routes. The hold covers the most expensive single attempt in the funded plan. If funds cannot cover a later fallback, that fallback can be left out of the plan. A hold is not an additional charge.
2. Measure. The content path reads the provider’s usage counts and measures latency. When usage is missing, it can supply estimates. Only usage metadata goes to the control plane for settlement.
3. Settle. AnonRouter calculates the charge at the serving route’s pinned prices, charges no more than the reservation, and releases the unused funds. Retrying settlement does not charge the same request again.

Prices are pinned when the request is authorized, including the schedules for its permitted routes. A later catalog update does not change an in-flight request’s prices. Use the listed route prices when comparing models; the service fee applies to credit purchases.

A large hold can exceed the final bill substantially. The input bound used to protect your balance is separate from the estimate used to decide whether a prompt fits a model. See context limits. Free model variants use separate allowances and require explicit opt-in.

With an active subscription, the same reserve and settle loop runs against the plan's usage allowance instead of your prepaid balance, at your plan's price for the route. The reservation counts toward the rolling 5-hour, rolling 7-day, and monthly limits until the request settles. A request that does not fit all three limits does not start. Whether it then uses your purchased credits depends on the plan's limit setting.

Token prices and caching

Input and output tokens have separate rates. When the provider reports cache usage, cache-read and cache-write tokens use their respective listed rates; those tokens are not also charged as ordinary input. If a separate cache rate is absent, the input rate applies. A cache discount depends on the usage the provider reports, so do not assume a repeated prompt will receive one.

Image generation and speech, where available, use their listed unit prices rather than this text-token calculation.

Long-context pricing

Some routes charge higher rates when the total prompt token count exceeds a published threshold. That total includes ordinary input, cache reads, and cache writes. At exactly the threshold, the lower tier still applies. With several thresholds, the highest one the prompt exceeds selects the rate schedule.

The selected schedule prices the whole request: every input, cache, and output token uses its rate in that tier. Only charging the tokens above the threshold would give the wrong bill. For example, with a 200,000-token threshold, a 200,001-token prompt selects the higher schedule for all of its input and its output; a 200,000-token prompt does not.

The reservation can account for a higher tier that the input bound could reach. Final tier selection uses provider-reported prompt usage, so a large hold alone does not establish that your prompt crossed a threshold. If exact usage is lost, a ceiling capture does not apply a higher tier solely because the bound could have crossed it.

Missing usage and interrupted requests

Provider-reported usage is used when available. When a provider omits token counts, AnonRouter can charge estimates from the content path. Missing usage does not make a completed response free, and an estimate may differ from the provider’s own tokenization. Do not rely on a cache discount for usage the provider did not identify as cached.

Stopping a stream or disconnecting does not necessarily cancel work already sent to the provider. Delivered partial output can be billed. If the request was dispatched or delivery began and reliable usage cannot be recovered, settlement can conservatively capture the serving attempt’s authorized ceiling, up to the reservation. A confirmed provider rejection before delivery releases the hold. If a content node is lost and its dispatched request’s usage is unknown, the node-loss recovery path releases that request’s reservation rather than charging an unknown amount.

Inference cannot take your prepaid balance negative: the final charge never exceeds the amount successfully reserved.

Billing across provider attempts

The reservation covers the most expensive permitted attempt in the funded plan, not the sum of every possible attempt. If an upstream attempt fails and a fallback succeeds, you are billed for the serving attempt at that route’s pinned prices. AnonRouter absorbs the failed-attempt costs rather than charging you for each try. A route cannot be dispatched outside the authorized price envelope. See provider routing.

Identity and content boundaries

In the ticket flow, control identifies your account and issues a one-use authorization without receiving the prompt. The relay and credential worker process content using that authorization rather than your stable account credential. Usage metadata returns to control, which maps the reservation to your balance.

Compatibility mode has a different boundary: its broker receives your API key and prompt together to authorize and forward the request. It uses the same reservation and settlement rules, but does not provide the ticket flow’s separation of stable identity from content. Settlement itself remains content-free in both flows.

On an E2EE route, the relay sees ciphertext rather than plaintext and bounds the reservation from ciphertext length. Provider-reported usage can still settle the request. Confidential-compute verification and provider privacy practices are separate from billing; see the privacy model and models and privacy labels.

What the usage record contains

Settlement writes one usage metadata record per request. Read your records with GET /v1/usage, or view them in the dashboard.

{
  "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 billing record contains no prompt or response text, tool arguments or tool outputs, uploaded file contents, raw provider bodies, or API key. Token counts can reflect estimates when the provider did not report usage. See credits and payments for balances, purchase orders, and receipts.