Request logs and analytics

What is recorded

For every request the gateway serves, it records metadata: the route called and the upstream model that served it, the key and project, the HTTP status, how the request ended, its timings (total, time to first token, time per output token), token counts, the settled cost in rupees, whether the request ran on your own provider key, the calling client's user agent, and any X-I2-Meta-* tags you sent. The content of prompts and completions is not part of this log.

Two of those deserve a note, because each changes how a figure next to it should be read.

Prompt caching. On a route that caches, a row carries the tokens written into the cache and the tokens read back out of it, and the row's total counts both alongside the prompt and the completion. A request that read a large cache therefore shows a total many times its prompt and completion added together, and that is correct rather than a fault. On i2's own global routes, which do not cache, both counts are absent: absent means the route has no cache, which is a different statement from a cache that was missed.

BYOK. A request served against your own key from the vault is marked as such, and its cost on i2 is a fraction of what the same request costs on i2 capacity, because the provider billed you directly and i2 settled only its own share. A near-zero cost on a marked row is the arrangement working, not a billing fault. Your provider's own invoice is the other half of that request's cost and i2 never sees it.

In the dashboard

• Request logs is the row-by-row view: search by request id or tag, filter by window, project, key, model, status class, termination reason, minimum cost and billing mode, page through, open any row for every recorded field, export the page as CSV. A cached request shows its cache total under the token split, and a BYOK request is marked under its cost; both appear only on rows that have them.
• Overview and each key's detail panel aggregate the same telemetry: request volume, average latency, time to first token, throughput, tokens and spend, per key, per project and per model, over 24 hours, 7 days or 30 days.
• Activity is a different log: the control plane's audit trail of administrative changes (sign-ins, keys created and revoked, renames, deposits). It records who did what, not traffic.

Over the API

Three endpoints under Analytics, all scoped to your organisation by your session:

A minimal pull of yesterday's failed requests:

curl -b cookies.txt \
  "https://api.intelligentinference.ai/api/analytics/requests?time_range=24h&status_category=5xx&limit=200"

See Auth endpoints for obtaining the cookie jar.

Throttling

GET /api/admin/usage-throttling answers the question the log itself cannot: how much of a window i2 refused rather than served. It takes the same time_range, project_id, key_id and model_alias filters as the analytics endpoints, and despite sitting under admin/ it is scoped to your own organisation and open to any member of it.

{
  "time_range": "24h",
  "total_requests": 15234,
  "rate_limited_count": 340,
  "guillotine_count": 12,
  "throttled_requests": 352,
  "throttle_rate": 0.0231,
  "computed_at": "2026-08-26T12:00:00+00:00"
}

rate_limited_count is requests answered 429; guillotine_count is requests the gateway cut off on its own server-side timeout. throttle_rate is null, not 0, over a window with no requests at all.

Treat throttled_requests as a floor, not a total. It counts requests that were attributed to your organisation and carried a 429 or a server-side timeout. Some rejections happen too early in the request path to be attributed to anyone, so they are not in this number. Real throttling against your organisation can only be higher than this figure, never lower.

The dashboard shows the same four figures on the Request logs page, under the window totals and narrowing with the same filters.

Timings, defined

Averages over an empty window are null, not zero: an average of no measurements is not a fast response.

Retention and history

Rows served before the gateway's telemetry pass of 2026-08-24 lack prompt_tokens and the upstream block; those fields read as null on historical rows, which is the absence of the measurement, not a failure to resolve it.