What does OpenRouter's GET /api/v1/generation endpoint tell you about a finished call?

## What this endpoint is for There are two ways to learn what an OpenRouter call cost: ask for it in the response, or look it up afterwards by id. `GET /api/v1/generation` is the second. It exists because some questions only make sense after the fact — reconciling a month of logged request ids against a bill, investigating one slow call, or finding out which upstream provider served a request when your routing rules allowed several. ## Getting the id The `id` on the chat completion response is the handle. Log it. A team that logs prompts and latencies but not the generation id has thrown away its only key into this endpoint, and reconstructing it later is impossible. Under streaming, the id appears on the chunks as well, so capture it from the first one rather than waiting for the end. ## What the record contains The useful fields group into three families. **Money.** `total_cost` is the credits charged for the generation. `cache_discount` shows the reduction attributable to a prompt-cache hit, which is how you prove a caching change actually paid for itself rather than merely appearing to. **Tokens.** `native_tokens_prompt` and `native_tokens_completion` are counted by the serving model's own tokenizer — the counts billing derives from. `tokens_prompt` and `tokens_completion` are OpenRouter's normalised counts, which exist so you can compare volume across models with incompatible vocabularies. Confusing the two is the standard reconciliation bug: you compare a normalised count against a native price and the arithmetic never closes. **Route and timing.** `provider_name` names the upstream that served the call — the single most valuable field here, because with fallbacks or provider preferences in play the slug you asked for does not tell you who answered. `latency` reflects time to the first token and `generation_time` the generation itself, so you can separate a slow provider from a long answer. `finish_reason` and `streamed` complete the picture of how the call ended. ## The asynchronous gap The stats row is written after the generation completes, and it is not instantaneous. Query the endpoint the microsecond your stream closes and you may get nothing back. The correct client is a short retry loop — a few attempts with a growing delay — and the correct mental model is "eventually consistent audit log", not "synchronous read-your-writes". Systems that treat the first miss as a hard failure end up with gaps in their cost data precisely on the fastest calls. ## When to use it versus inline accounting If you want cost on every request in production, enable inline usage accounting and log the number as the response lands: one round trip, no polling, no gap. Reach for the generation endpoint when: - You are auditing historical ids and never captured cost at the time. - You need `provider_name` to explain a quality or latency regression. - You want to prove a cache discount or compare native against normalised counts. - You are debugging one specific call rather than instrumenting all of them. Using it as your primary billing pipeline means one extra HTTP round trip and a retry loop per request, which at volume is real load and real latency for data you could have had for free in the response. ## Practical shape A sensible design records `id`, model slug, and your own dimensions at request time; records inline cost when the response arrives; and keeps a small background job that fills in `provider_name` and timing from the generation endpoint for a sample of requests, or for all requests in an incident window. That gives you cheap always-on cost data plus deep forensics when something goes wrong, without paying for forensics on every call.