How do you make OpenRouter return the actual cost and native token counts inline?

## The problem usage accounting solves Estimating cost client-side means multiplying a cached price table by a token count you also estimated. Both halves are wrong in interesting ways: the price depends on which provider served the route, and your token count depends on which tokenizer you assumed. Usage accounting removes the estimate — the platform tells you what it charged. ## Turning it on It is one field in the request body: ``` "usage": { "include": true } ``` That is an OpenRouter extension, and it is a common trip-hazard for people arriving from an OpenAI-shaped client, where the analogous streaming knob is `stream_options: {"include_usage": true}`. On OpenRouter the `usage` object in the request is the switch, and it covers both streaming and non-streaming calls. ## What comes back The response `usage` object gains: - `cost` — credits deducted for this request. One credit is one US dollar, so this is a dollar figure. - `cost_details` — a breakdown; the notable member is `upstream_inference_cost`, which is populated on bring-your-own-key routes to show what the upstream provider will bill you separately. - `prompt_tokens`, `completion_tokens`, `total_tokens` — counts as measured by the serving model. - `prompt_tokens_details.cached_tokens` — how much of the input was served from a prompt cache, on models that support one. - `completion_tokens_details.reasoning_tokens` — hidden reasoning tokens on reasoning models, which you pay for but never see as text. Those last two are where surprise bills live. A reasoning model can bill several times the visible output length, and a dashboard that counts only characters returned to the user will never explain the invoice. ## Normalised versus native token counts OpenRouter serves models with radically different tokenizers, so for cross-model comparability it reports normalised counts by default. Billing, however, happens against the tokens the serving model actually consumed — its **native** counts. With usage accounting enabled you see the native figures, which is why a token count from an accounting-enabled response will not always match one you computed with a generic tokenizer library, and why the accounting figures are the ones to reconcile against spend. If you are building a cost model, always compare like with like: native tokens against the provider's per-token rate. ## Streaming: the chunk after the last chunk With `stream: true`, deltas arrive as Server-Sent Events. The content ends, a chunk carries the finish reason, and then **one more chunk arrives whose `choices` array is empty and whose `usage` object holds the accounting**. Two very common client bugs drop it: 1. Breaking out of the read loop the moment a finish reason appears. 2. Guarding the loop body with something like `if chunk.choices:` and skipping everything else. Both produce a system that streams beautifully and reports zero cost. The correct shape is to keep reading until the stream terminator, and to handle a chunk with no choices by looking for `usage` on it. ## Cost of the feature itself Asking for accounting does not change what you are charged for the inference and does not meaningfully change latency — the numbers are already computed on OpenRouter's side. There is no reason to leave it off in production; the only argument for omitting it is that you have nowhere to put the number, which is itself the problem. ## Using it well Log `cost` per request alongside your own dimensions — tenant, feature, model slug, request id — at the moment the response completes. That single line is what lets you answer "which feature doubled our spend last Tuesday" without a reconciliation project. Aggregate it into a rolling spend metric and alarm on the derivative, not just the level: a 10x jump in cost per request usually means routing moved to a pricier provider or somebody enabled a reasoning mode, and both are cheaper to catch in an hour than in a month. ## Pitfalls to name in an interview The accounting reports what was charged **for that request**, not your remaining balance and not account-wide spend. Cached input is cheaper but still billed. Reasoning tokens count. And on a failed or aborted request, whatever tokens were generated before the abort can still be billed, so a client that cancels aggressively should still record whatever accounting it managed to receive.