Logs

Finding a request

Each response has an X-Request-ID header like req_…. In the console, press F and paste it, or a provider generation id (gen_…), to jump straight to the request. The same data is available from GET /v1/requests/:id.

Send your own X-Client-Request-ID header to record a correlation id from your system alongside ours, and an ib-session header to group the requests of one conversation or job. To read requests from code, use GET /v1/usage, which pages through them as JSON or CSV.

Querying

The Logs page has one query bar. Bare text matches request and generation ids; anything else is a field operator value condition. Combine conditions with AND, OR, NOT and parentheses; a space between two conditions means AND. The bar autocompletes fields, operators and values, with counts for the selected time range. Clicking a model, provider, status, error, environment, key, end user or tag in the table adds it to the query.

For example: env = production AND (status >= 400 OR attempts > 1), error IN (policy_denied, insufficient_balance), or latency > 5s OR cost > 0.02. Export CSV downloads every request matching the current query and time range.

Views and sessions

Views are one-click queries: errors, server errors, failovers, rate limits, requests rejected before dispatch, pending charges, sessions, and requests with logged content. Save any valid query as your own view; saved views are kept in this browser.

End a query with GROUP BY session to get one row per conversation, with its turns, model switches and charge. Open a session to see which model served each turn and why (see Mixed-model sessions).

The receipt

Opening a request shows its receipt:

• The model requested and the model and provider that actually served it.
• Each dispatch attempt, in order, with its upstream status and timing: time to first token, duration, and output tokens per second.
• Token usage: prompt, completion, reasoning, and cached tokens.
• Cost: upstream cost, platform fee, and the amount charged.
• The Directives, pricing, and catalog versions that applied.

Content

By default Inference Bureau keeps no prompt or response content. When the Log content Directive is on for a request, its page has a Content section with the request body as you sent it and the response, or for a stream the output assembled from it, until the content's retention ends (7 or 30 days).

• Owners and admins choose Show content to open it. JSON is pretty-printed, a body cut at 256 KB says so, and each part has a copy button. Every opening is recorded in the audit log as request.content.view.
• Members see that content was logged and its size, not the content.
• Headers, and so your API key, are never kept. Content is encrypted at rest, deleted when its retention ends, and deleted at once when Log content is turned off for the level it was logged under.
• Content isn't in the downloadable receipt, GET /v1/requests/:id or usage export.
• To read it from code or an agent, give a key the Read logged content permission and call GET /v1/requests/:id/content. Each read is audited under that key.

Query content = logged, or pick the Logged content view, to list the requests whose content is kept; content IS EMPTY lists the rest. Those requests show content logged under their id.

Speed: TTFT and tokens per second

Every provider attempt records when it was sent, when its first byte came back, and when it ended. From these, for each attempt:

The Logs table shows TTFT under the latency of streamed requests, and each request shows the figures for every attempt. The project Overview and the Dispatch page show p50 and p95 TTFT, p50 and p95 latency, and median output tokens per second for each model and provider, over succeeded attempts in the selected period; console test calls are left out. The same per-attempt values are in GET /v1/requests/:id as ttft_ms, duration_ms and output_tokens_per_second.

Request states