Requests

Search the request log, watch requests arrive live, and read one request's cost, timing, route and payload.

The Requests screen is the log of every request made with your organization's keys. Each row opens a detail page for that request. Everyone in the organization can open both.

To find a request from its id in code or from a response header, see Look up a request.

The request log

Requests are listed newest first, 25 to a page. Older loads the next page and Newest returns to the first.

Filter the log

The filter bar has:

a model list (all models by default);
a status list: ok, error, cancelled, budget_exceeded, timeout or rejected;
a project list;
a search box for a tag, user id, app or request id. Press Enter to apply it;
a minimum cost, in micro-USD. It applies when you leave the box;
only errors, which keeps failed requests;
only fallbacks, which keeps requests that needed more than one attempt.

Filters are kept in the page address, so you can share a filtered view. The explain links on the Usage screen open the log already filtered by model, provider, project or key.

Tick Live tail (2 s). New requests that match your filters appear at the top as they finish, and a green live badge shows the connection is open. If it drops, the badge turns amber and the screen reconnects by itself. Untick the box to stop.

What each row shows

Column	What it shows
Time	When the request started, in your time zone. Hover for UTC.
Request	The start of the request id. Click it to open the detail page, or press the copy button beside it to copy the full id.
Model → endpoint	The model asked for and the provider that served it.
Status	The status, with the error code or the stop reason beside it.
Tokens in/cached/out	Input tokens, how many of them were read from cache, and output tokens.
Cost	What the request was charged.
TTFT	Time to the first token, in milliseconds.
Duration	The whole request, in milliseconds.
Flags	See below.

The flags are:

a number of attempts, when the first provider tried did not serve the request. These rows are also tinted amber;
estimated, when the provider sent no token counts and they were counted by the gateway;
BYOK, when the request went through your own provider key;
ZDR, when it ran under zero data retention;
logged, when its payload was stored;
stream, when the response was streamed.

If no request matches, the screen reads "No requests match" with a button to the quick start. Clear the filters, or send a request with one of your keys.

When analytics are more than 60 seconds behind, an amber "analytics delayed" banner appears. The newest requests may be missing until it clears. Charges are not affected.

The request detail page

The page title is the full request id, followed by badges for the status, the error code if any, estimated usage, ZDR and BYOK. When the failure came from the provider, a badge names the provider and, for some providers, links to its status page.

A request that has only just finished may not have its record yet. The page then reads "Finalising" and checks again every 2 seconds for a short while.

Actions

Replay in playground opens the playground with the same model and the first user message filled in. It is disabled when no prompt was stored.
Copy as curl copies a command rebuilt from the stored model and messages. It is not an exact copy of the original call: other parameters are left out. The command uses the route and the body of the format the request came in: Chat Completions, Responses, Messages, Gemini or native. It carries the text of the messages, so images, tools and files from the original are not in it. Your key is never stored with a request, so the command has a placeholder where the key goes.
Share (org-internal link) copies the page's address. Only members of your organization can open it.
Report problem starts an e-mail to support with the request id, model, provider and status filled in.

Summary

The first panel lists the Time, the Model → endpoint with its region, the Project / key (the key links to its page under API keys), the Dialect the request was sent in and whether it streamed, the App / user it was attributed to, its Tags, Bytes in / out, and the Client address prefix and user agent. The user is shown only as a hash of the id you sent.

Cost lines

The Cost panel shows the total and, under it, one line per kind of charge. Each line gives the kind, the number of units, the unit price in nano-USD, and the line's amount in micro-USD. The lines add up to the total. How each line is rounded is explained in Billing basics.

Below the lines, price version names the prices the request was charged at and links to the model's price history.

Timing

Timing gives the time to first token, the provider's own time to first token, the total duration and the gateway's overhead, followed by a bar that lays out where the time went, attempt by attempt.

Route trace

Route trace is the router's account of how it chose where to send the request: which endpoints it considered, which it dropped and why, and the order it tried the rest. Read it when a request went somewhere you did not expect, or when a routing policy is involved. A request under zero data retention has no stored trace, and the panel says so.

Attempts

Attempts has one row for each provider call the request made: the Provider · endpoint, the Outcome with the class of error if it failed, the HTTP status, the time to first token, the Duration and the Key used. More than one row means the request fell back. The panel is empty for a request that was refused before routing.

Usage

Usage lists the token counts by kind in two columns: normalised, which is what you were charged on, and provider raw, which is what the provider reported. A badge says whether the counts came from the provider or were estimated because the provider sent none.

Warnings

Warnings lists anything the gateway adjusted or wants you to know about the request, each with its code, the field concerned and a reason. It reads "none" when there are no warnings.

Payload

The last section shows the stored Request and Response as a conversation, block by block. Tick raw JSON on either to see the stored document instead. If the request failed, an Error panel shows the code and message. When redaction rules applied, a line says how many redactions were made before storage; markers in the text show where.

A payload is shown only if it was stored. Otherwise the section says why:

Message	Meaning
Payload not logged: zero data retention	The key, project, organization or the endpoint that served the request is zero data retention, so nothing was stored.
Payload not logged: logging is off	Payload logging is off for the key, its project or the organization. Turn it on in the data policy or the key's settings to store future payloads.
Finalising	The payload is being archived. Press Refresh after a few seconds.
Payload expired	The retention period has passed and the record was deleted.
Payload erased	The record can no longer be read because of an erasure request.
Payload viewer unavailable	This installation cannot read stored payloads.
Payload fetch failed	The store did not answer. Press Retry.

Everything else on the page is available whether or not the payload was stored.