Looking for the product page on per-request cost records and per-key caps? See LLM cost tracking. This post explains how to isolate workloads with keys, read spend per key, save request IDs for anything finer, and reconcile application activity with the gateway bill.
A monthly total does not tell you which application, agent, or teammate incurred it. Router One records each model request against the API key that sent it and enforces each key's spend cap, so giving every workload its own key turns the dashboard into a per-workload cost report. Anything finer than a key — an end customer, a run, a feature — is identity your application has to supply.
Use a separate key for each workload, set an appropriate spending cap, read spend per key under Dashboard → Usage, and export that key's logs to CSV when you reconcile. For attribution below the key level, save each request ID with your own label instead of estimating charges from a separate price table.
Why provider dashboards aren't enough
If you call two or three providers directly, your spend lives in two or three dashboards, each with its own update cadence, currency handling, and definition of a "request". Worse, attribution stops at the account level: the dashboard can tell you what the whole account spent, but not which of your services made the calls, unless you maintain separate accounts per service — which multiplies billing overhead instead of reducing it.
The usual workaround is application-side logging: wrap every SDK call, estimate token counts, multiply by a price table you maintain by hand, and hope nobody calls a model you forgot to add. It works until a price changes or someone adds a provider, and it silently breaks.
Step 1: One key per workload
Router One sits between your applications and the model catalog, recording model usage and request charges. Start by creating one API key per application, agent, or environment, so each workload gets its own spending limit and its own line in the usage report.
- a key named
prod-chatbotfor the production assistant batch-pipelinefor the nightly enrichment jobclaude-code-alicefor a teammate's coding agentstagingfor everything pre-production
Dashboard → Usage lists spend by key name and Dashboard → Logs shows the key name on every request, so name each key after its workload. In application or client logs, save the workload label, model, timestamp, and returned request ID; never log the key secret. For example, give a LlamaIndex pipeline its own key (setup guide) and retain request IDs with the pipeline run.
Step 2: Read spend by key, then the request logs
Dashboard → Usage ranks your API keys by spend, tokens and requests for the chosen range, and each key links to its own logs. Dashboard → Logs filters by model, API key, status and date range; the API key column (and the request detail) names the key that sent each request — web-console calls carry no API key and are labeled as such. Each record includes the model, input and output tokens, cost, latency, and status.
To reconcile, export the logs (current filters) to CSV, and the wallet ledger (chosen range) next to them. Within one key, match the request IDs your application saved to split that key's total by end customer, run, or feature: the dashboard's attribution stops at the key, and your labels take it further.
Cost is computed at the pay-as-you-go token line of each model's posted rate — the per-1M-token prices published on the models page — with FX and payment-channel fees shown separately at checkout. There is no price table for you to maintain, and nothing to estimate on your side: the trace records the settled cost of each request. When the client cancels a stream on /v1/chat/completions or /v1/responses after output has started and no final usage arrives, that cost includes an estimate of the part the upstream did not report (as of 2026-10-13), so the request's row in Dashboard → Logs can show the cost next to zero tokens — see LLM streaming. Metering uses token counts and request metadata. Router One does not retain prompt or model-response bodies from direct API calls. It records request metadata for billing, usage tracking, and troubleshooting. Playground saves conversation history so users can revisit and continue their chats.
Step 3: Cap before it hurts
Attribution without enforcement still leaves you reading about the incident in the invoice. Each key can carry a spend cap you set, and runs under two platform limits:
- maxSpend — a hard ceiling on what the key may charge to your wallet
- rateLimit — requests per minute, a platform default that support can raise on request
- tokenLimitTpm — tokens per minute, a platform default that support can raise on request
A wallet-billed retry loop in the staging environment hits the staging key's cap and stops; production keeps running. A leaked key is bounded by its own ceiling instead of the whole wallet. And when usable credit reaches zero, requests your plan does not cover get HTTP 402 rather than accruing surprise debt (see the error-code reference) — the pricing methodology page documents the billing semantics in detail.
The console sends an in-app notification when a key reaches 80% of its maxSpend and when it hits the cap, so a runaway workload shows up before the invoice does. These are in-app notices, not email or webhook alerts; to watch the wallet from a server, see balance monitoring.
Step 4: Review weekly, not monthly
Review your workload totals weekly. Start from the week's spend by key in Dashboard → Usage, compare request volume, model mix, and token counts with the previous period, and adjust each key's cap when needed. Keep requests that could not be matched to one of your labels separate instead of silently assigning their cost. The cost tracking and observability pages describe the available customer fields.
FAQ
How do I track LLM API costs per app or team member? Create a separate key for each app, agent, or teammate and name it after the workload. Dashboard → Usage then shows spend, tokens and requests per key for the chosen range, Dashboard → Logs filters by that key, and both the logs and the wallet ledger export to CSV for reconciliation. For anything below the key level, save your own labels with request IDs and match them in the request logs.
What does the gateway record for each request? Every request records its model, the API key that sent it, input and output tokens, cost at the posted rate, latency, status, and request ID. Metering uses token counts and request metadata. Router One does not retain prompt or model-response bodies from direct API calls. It records request metadata for billing, usage tracking, and troubleshooting. Playground saves conversation history so users can revisit and continue their chats.
How is the cost of each request calculated? Cost is computed at the pay-as-you-go token line of each model's posted rate — the per-1M-token prices published on the models page — with FX and payment-channel fees shown separately at checkout. There is no price table to maintain and nothing to estimate on your side: the trace records the settled cost of each request. When the client cancels a stream on /v1/chat/completions or /v1/responses after output has started and no final usage arrives, that cost includes an estimate of the part the upstream did not report (as of 2026-10-13), so the request's row in Dashboard → Logs can show the cost next to zero tokens — see LLM streaming.
Can I set a spending cap on a single API key? Yes. Set maxSpend on the key. A key's spend cap (maxSpend) limits what that key can charge to your wallet: once its cumulative wallet charges reach the cap, its wallet-billed requests return HTTP 402. Requests covered by your plan's quota draw from the account's shared plan quota and do not count toward any key's cap. Each key also runs under a platform-default rateLimit (requests per minute) and tokenLimitTpm (tokens per minute), which support can raise on request. A leaked key is bounded by its own ceiling instead of the whole wallet.
Will I be warned before a key hits its cap? Yes, in the console: it sends an in-app notification when a key reaches 80% of its maxSpend and again when it hits the cap. Key-cap notices are in-app only, and there are no webhook alerts; a server-side monitor can poll GET /v1/balance for the wallet instead (balance monitoring).
What happens when my credit runs out? When usable credit reaches zero, requests your plan does not cover get HTTP 402 rather than accruing surprise debt. The pricing methodology page documents the billing semantics in detail.
The takeaway
Separate keys control exposure and give every workload its own line in the usage report; request IDs connect anything finer to its charges. Keep the workload mapping in your application, read spend per key in the dashboard, and reconcile the CSV exports with your own labels to build a cost report you can explain.
Start with one key per workload at router.one, and see the cost tracking overview for the available fields. Related operational patterns include production fallback and spend-capped customer keys.