---
title: Usage and logs
description: Consumption over a window, breakdowns by model, key and project, the request log, and how to find one particular call in it.
keywords: usage, consumption, logs, request log, tokens, call id, x-request-id
group: account
---

## Find one call {#find-call keywords="call id, x-request-id, search, support"}

:::steps
- **Take the identifier from the answer** — Every answer of both runtimes carries an `X-Request-Id` header.
- **Open the request log** — Find the call by time, model and key.
- **Open the row** — The call's card carries its identifier, its tokens and its latency.
:::

The identifier is always the platform's own: it never echoes back what you sent, so the value in the header is a real lookup key for an entry in the platform log. That is the thing to attach to a message to support.

> [What a refusal looks like →](/en/errors) [What to send support →](/en/support)

## Activity {#activity keywords="consumption, window, period, models, keys, projects"}

The activity screen shows **settled** consumption over a window: exact token quantities by day, the totals over the window, and — as a separate figure — how many calls are still in flight holding a reservation. Reservations are never added into the totals: until a call settles, its cost is an estimate rather than a fact.

There are four windows: the **last 24 hours, 7 days, 30 days and 90 days**. They are trailing windows, not calendar months.

The window narrows on three axes — **project, key, model**. The first two are a real narrowing of the read: the chosen projects resolve into their keys, the window is read again against them, and everything on the screen — the daily chart included — becomes about those alone. A project holding no key can narrow nothing, and the screen says so rather than showing you an empty result.

### What is counted

| Figure | What it is |
| --- | --- |
| `Tokens` | The five dimensions separately: input at the uncached rate, input from cache, input into cache, output, and image units. |
| `Spent wallet` | Dollars debited from the wallet. Zero when nothing was wallet-funded. |
| `Requests` | Settled calls in the window. |

Cached input tokens are a figure of their own and are never folded into the uncached one: they are charged at a different rate, and adding them would hide exactly the saving the cache was turned on for.

Spend is printed in two units and stays in two: package calls in package tokens, wallet calls in dollars, and the daily chart draws one of them at a time. That is not an interface inconvenience but the absence of a rate between them.

The breakdowns are by model, by key and by project, busiest first.

## The request log {#logs keywords="log, calls, columns, outcome, latency, filter"}

The log is the organization's immutable history of calls, newest first, with each call's confirmed token quantities and what it actually cost.

| Column | What is in it |
| --- | --- |
| `Model` | The model name as the caller wrote it, with an outcome mark beside it. |
| `Tokens cost` | Prompt and completion, plus the cost — in the unit the call was charged in. |
| `Key` | The key the call was admitted with. An erased key has no name left, and the cell empties. |
| `Time` | The instant of the call and its latency. |

A refused call prints its reason in place of tokens and cost.

The outcome filter offers all, answered and refused. Answered calls are requested from the platform; refusals are picked out of what has already been loaded, because a refusal has six different endings and the platform takes one at a time.

An opened call shows nine fields: time, model, key, prompt tokens, cached prompt tokens, completion tokens, latency, cost, and the call ID.

## What the log does not hold {#not-stored keywords="privacy, prompt, answer, headers, address"}

A call is recorded **by its shape and never by its content**: no prompt, no answer, no headers, no client address. They are not hidden from the screen — they are not stored at all, so there is nothing there that could be shown.

That has a practical consequence worth planning for: neither you nor support can reconstruct **what** you asked from the log. If the content of your requests matters to your own investigations, record it on your side.

> [Money movements →](/en/billing) [How keys are grouped →](/en/projects)