Request logs

The Request logs page is the operator surface for recent runtime traffic. It helps you inspect whether requests were admitted, which Pool handled them, which upstream account was selected, how the route behaved, and what usage metadata was settled.

Use this page when you need to answer:

1. whether a client request reached Codex Pooler
2. which Pool, upstream account, model, API key, and transport were involved
3. whether the request succeeded, failed, retried, or is still in progress
4. how long routing and upstream work took
5. which token and cost metadata was recorded
6. whether errors were safe operational errors, quota issues, or upstream failures

Request logs are metadata-only. They do not show prompt text, generated content, uploaded file bytes, media contents, websocket frames, bearer tokens, upstream credentials, raw Pool API keys, raw idempotency keys, or raw provider payloads.

The screenshots in this guide redact live row values. The production UI shows safe labels and prefixes for operators, but public docs should not publish production identifiers or usage totals.

API-key usage boundaries

Keep these surfaces separate when investigating usage:

Surface	Scope	Use it for
/admin/api-keys	API-key lifecycle and policy	Create, edit, pause, resume, rotate, revoke, delete, inspect expiry and policy, and enable or disable Dashboard access. It does not show usage totals or charts.
API Key Observatory	One authenticated API key	Read-only bounded usage, model, cache, cost, latency, throughput, and recent sanitized outcome projections for that key.
/admin/stats	A visible Pool	Pool-level aggregate usage and capacity views for signed-in instance owners or assigned instance admins.
/admin/request-logs	Individual recorded requests	Sanitized request outcomes, attempts, settlement metadata, and routing context for administrative investigation.

The Observatory is a separate browser surface authenticated by the API key’s Dashboard access capability. It does not reuse the instance-admin session, does not grant /admin/* access, and does not replace the runtime compatibility usage routes. Opening the Observatory does not itself create a runtime request.

Filters

The top filters narrow the table without changing any data.

Primary filters are:

Filter	Meaning
Pool	Limits rows to one Pool. Owners can inspect all visible Pools; assigned admins only see their Pool scope.
Status	Limits rows by request outcome, such as completed, failed, rejected, or in-progress states.
Upstream account	Limits rows to a visible upstream identity. When a Pool is selected, this list narrows to accounts assigned to that Pool.
Model	Limits rows to a model name observed in request logs.

Advanced filters are:

1. Correlation or row id, for finding one request by known id
2. Date from, for the start of the time range
3. Date to, for the end of the time range

Invalid or unsupported filters are ignored with a warning so operators can fix the query without losing the page.

Table Columns

The table shows the latest matching rows, with a hard page size limit.

Column	Meaning
Status icon	Outcome indicator for the request row. Use the icon with the Errors column to understand failures.
Timestamp	Admission time and short row id. Use this when correlating with logs, audit events, or client reports.
Upstream account	Selected upstream account label and Pool name when selection metadata is visible.
Plan	Safe upstream plan badge when known.
Model / API Key	Requested or enforced model, effective reasoning effort with requested-vs-upstream detail when it was normalized, service tier, plus the API key label or safe prefix.
Transport	Request transport and protocol family, such as HTTP JSON or HTTP SSE.
Route	Runtime route family and safe client metadata. It can include path shape and latency, not request content.
Usage	Settled token and cost metadata when available. Missing usage can mean the request did not settle or pricing was unavailable.
Errors	Sanitized error summary lines. These should identify operational cause without exposing content or credentials.

Status and Errors

Use status and errors together. A completed row with token usage usually means the request reached an upstream and settled successfully. A failed row may still show route, latency, or partial attempt metadata. A rejected row usually means admission or policy failed before upstream work.

OpenAI Responses response.incomplete can be a successful delivered terminal response. For example, an upstream may stop at max_output_tokens or a content filter and still return safe usage metadata. Those rows stay succeeded and should not be treated as upstream health failures. Error-coded incomplete terminals, stale continuation anchors, stream truncation, and client disconnects still appear as failures or interruptions with sanitized error codes.

Common causes to inspect are:

1. Pool API key paused, revoked, expired, or attached to the wrong Pool
2. requested model not allowed by the key policy
3. no active upstream assigned to the Pool
4. selected upstream needing reauthorization or token refresh
5. quota evidence exhausted or stale
6. upstream route failure or timeout
7. request shape unsupported by the current compatibility surface

The Errors column should stay safe to copy into operator tickets. It should not include raw prompts, responses, uploaded file contents, credentials, or provider payloads.

Upstream Websocket Connection Details

For an attempt that actually used a current-release upstream websocket, the admin attempt-detail drawer can show an upstream_websocket_connection group with exactly four fields:

Field	Meaning
lifecycle_id	A generated canonical UUID shared by successful upstream websocket connections created within one in-process session lifecycle. It is not a provider or socket identifier.
generation	The positive ordinal of a successfully established upstream websocket connection within that lifecycle. Reuse keeps the same generation; a successfully established replacement advances it.
reused	Whether this request started on a connection that an earlier request had already established.
reconnected	Whether this request was retried on a newly established connection after its reused connection failed before a response became visible.

This group is attempt metadata only. It is omitted when metadata is missing or malformed, when a previous-release owner cannot provide it, and when a bridge falls back to HTTP. It is not added to request-level list rows and is not exposed by request-log MCP tools.

Websocket Close Triage

Websocket request rows are created after gateway admission and reservation. If a websocket closes before a request row exists, inspect application logs for sanitized websocket close metadata instead of looking for prompt or frame content.

Safe close metadata can include route family, endpoint, transport, route class, phase, reason_class, elapsed milliseconds, safe session id prefixes, owner or proxy instance ids, and downstream epoch. Typical reason_class values include max_frame_size_exceeded for an oversized inbound websocket frame, timeout for downstream websocket idle close, and closed for a normal client close.

For downstream idle closes on backend Codex websockets and narrow public /v1/responses websockets, check the admin-managed websocket_idle_timeout_ms setting. Its default is 1_800_000 ms and the accepted range is 60_000..3_600_000 ms. This setting does not change upstream receive timeout classification.

Usage Metadata

Usage lines summarize request accounting, including request count context, token totals, cached input tokens, and estimated cost when pricing is available. Treat these as operational attribution and capacity evidence. They are not a replacement for provider billing records or the key-local Observatory projection.

If usage is blank, check the request status first. A request can be admitted without final usage if it failed before settlement, if pricing was not matched, or if accounting metadata was not available for that route. A delivered incomplete response with missing upstream usage remains usage_unknown and does not get an invented settled cost from the reservation estimate.

Operational Checklist

When investigating a client report, check request logs in this order:

1. filter by Pool or API key context if known
2. filter by request id when the client provided one
3. narrow by model or upstream only after confirming the Pool
4. inspect status, transport, route, and errors
5. compare timestamps with Audit logs for recent policy or lifecycle changes
6. open the Pool page to confirm active status and assignments
7. open the Upstreams page to confirm readiness, quota, and freshness
8. open API keys to confirm key policy, status, expiry, and limits

If no row exists, the request may not have reached Codex Pooler, may have used a different Pool API key, or may be outside the visible operator scope.