Activity and logs

The dashboard has two views of your traffic. Logs lists individual requests: which endpoint served each one, what was tried and what it cost. Activity turns the same records into spend, usage and performance analytics you can filter, compare and export. Both show only the active account, and neither shows prompts, responses or secrets.

Logs

Open Logs to see requests newest first. A request appears once it finishes. Models appear by catalogue name, linked to the model's page; a model no longer in the catalogue shows its model ID.

Request detail

Select a row to open the request. The header shows the model, its status and the generation ID with Copy generation ID, followed by:

The Route panel starts at Request received and lists each endpoint tried, in order, with its time, usage and cost. Attempt numbers can have gaps. No endpoint received this request. means the request never reached a provider; Provider handoff could not be confirmed. means it may not have. Each attempt shows a result:

An attempt that ended without charge reads Not charged. Pending means the charge isn't final yet; it doesn't mean zero. Billing details expands to the price revision and rates applied, including Locked · USD-indexed for USD-indexed Bitcoin prices.

The Usage and cost panel shows Input (split into Uncached, Read from cache and Written to cache), Output, Total tokens, Charged, Saved by cache when caching saved money, and the currency charged. When the provider didn't report cache use, all input was charged at the uncached rate. A request that delivered nothing reads Nothing was charged.

The same record is available from the API with GET /generation.

Activity

Open Activity for analytics. The header states your scope: Personal activity, All organization keys for owners and administrators, or Your keys only for other organization members.

Query controls

Completed reports support Model, API key, Key creator, Provider, App, Task and Outcome. Other dimensions remain visible in saved query definitions but return an unavailable view; they do not scan individual request history. App grouping and filters are also unavailable for estimated percentiles.

Overview and Explore

Overview shows what the range cost, what used it and whether it worked:

• Figures: Spend with its change against the previous period, Requests with the share that succeeded, Tokens with the share of input read from cache, and Cost per 1M tokens.

• One chart and its table: choose the Metric (Spend, Requests or Tokens) and what to Group by (Model, API key, App or Provider). The chart shows the five largest and Other; the table lists every entry. Select up to five names to chart only those.

• Results: requests over time as Succeeded, Cancelled and Failed.

• Time to first token: the estimated median over time, with the p90 and median output speed for the range.

Explore builds any query: choose a Metric, a Dimension, an optional Subgroup, a Rollup, a Ranking and what to Rank by, then view the result as a chart and a table.

The chosen view, metric and grouping are part of the page address, so a link reopens the same view.

Metrics

Money metrics are exact decimals in the selected currency. Token metrics count only what providers reported; missing data shows as missing, not zero. Time to first token and output speed percentiles are estimates and are marked as such.

Range limits

Overview loads its figures, breakdown and charts together from the same completed intervals. Short ranges use hourly buckets; long ranges use daily or weekly buckets so every panel includes the same retained history. Selecting breakdown rows changes the chart using that loaded result.

Reports show Complete through a time, Partial results, or an unavailable state. A range that ends now is complete through the end of the latest processed activity; requests from the last few minutes appear once they're processed. Partial results include only the displayed completed intervals; an uncovered period does not count as zero activity. Last updated is the last aggregate update, which can stay unchanged while no new evidence arrives. Corrections appear after processing.

The change against the previous period compares two equally long completed periods: the completed part of your range, trimmed to whole hours or days where older history is only kept at that detail, and a period of the same length before your range, moved back to the nearest stored hour or day where older history is only kept at that detail, so a short gap can separate the two. It's shown whenever the earlier period is fully covered, also when your range is partial, and reads Comparison unavailable otherwise.

Activity is kept in five-minute detail for 7 days, hourly detail for 90 days and daily detail for one year, aligned to UTC. Totals, rankings and tables always include every completed period in the range. A chart period only includes stored detail that lies entirely inside it, so older history can be left out of the chart while still counting in the totals: hourly charts in time zones with a half- or quarter-hour offset (such as India or Nepal) beyond 7 days, the hour around local midnight on daily charts in those zones beyond 7 days, hourly charts in any zone beyond 90 days, and daily charts in any zone other than UTC beyond 90 days. The coverage line then says Totals include periods the chart leaves out. A range that starts between stored edges starts its completed results at the next edge: in a half- or quarter-hour zone, a range starting at local midnight more than 7 days back starts at the next whole UTC hour, and in any zone other than UTC, one starting more than 90 days back starts at the next UTC midnight.

Minute rollups, end-to-end latency percentiles and unsupported dimensions or filters return an unavailable view. Open periods, processing backlog and expired detail never trigger a scan of individual history. Relative ranges such as 24h or 30d start on the next edge of stored detail (five minutes, an hour or a UTC day), so they can be complete; they're never longer than their name.

Ranges of 24 hours or less refresh every minute while the page is open. Analytics never delay billing or balances.

Export, print and saved views

• Download CSV exports the filtered rows of the current query, up to 100,000 rows, with coverage status, refresh time and included intervals. A result without value rows contains one metadata-only row.

• Print / PDF opens a print layout of the same query, including its requested range, covered intervals, last update, timezone and filters.

• Save view stores the current query under a name. Saved views are private to you and never grant access to more data than your role allows.

To jump from a key to its traffic, open the key's menu in Keys and choose Activity.

Attribute traffic to your apps

Send an HTTP-Referer header with your app's public URL to group traffic by App in Activity:

curl https://api.numes.ai/api/v1/chat/completions \  -H "Authorization: Bearer $NUMES_API_KEY" \  -H "Content-Type: application/json" \  -H "HTTP-Referer: https://app.example-store.io/checkout" \  -d '{"model": "openai/gpt-6-luna", "messages": [{"role": "user", "content": "Hello"}]}'

Only the public origin is kept, here https://app.example-store.io. Values that aren't public app origins, such as IP addresses and local hostnames, are ignored.

X-Title is accepted for compatibility and ignored. Neither header is forwarded to providers. With the OpenAI SDK, set the header in the client's default headers; see OpenAI SDK.

Request IDs and generation IDs

Every response, including errors, carries an X-Request-Id header. Responses that started delivering also carry X-Generation-Id, which equals the chat completion id and identifies the request in GET /generation and Logs.

You may send your own X-Request-Id of 1–128 characters from A–Z, a–z, 0–9, ., _ and -; other values are replaced with a random ID. Request IDs must be unique per account, including for requests that were rejected: reusing one returns 400 invalid_request. It's a correlation ID, not an idempotency key, so generate a fresh value for every request, including retries.

When you contact support, quote the X-Request-Id and, where you have it, the generation ID. Never send your API key or the prompt.

What is never shown

Logs, Activity, exports and the generation API contain metadata only. They never include:

• prompt or response content, including media and tool arguments;

• key secrets; keys appear by name and masked label;

• session IDs, prompt-cache keys or the request's user field;

• your client's IP address, X-Title or the full HTTP-Referer URL.

A shared key identifies the person who created it, not who sent a particular request. To tell users or services apart, give each its own key.

Next steps