Reading the results

The two conventions

Both exist for the same reason: a number you cannot support is worse than no number.

One row per request, not per log record

The LLM table writes request, response and streamed-chunk records separately under a single CorrelationId. Every query collapses to one row per request before aggregating. A "request" in any result below means a logical request, not a log line.

Disagreement reads as absent

Where several records report different values for the same field, the queries return nothing for it rather than picking one. Where no record reported a value, the result is likewise absent, not zero.

This is why UsageCoveragePct exists. Below 100%, the token totals rest on that share of requests and are a floor, not an estimate of the remainder. Quote the coverage whenever you quote a total.

The queries

00 · Preflight

Reports per table: READY, PRESENT BUT EMPTY, PRESENT WITHOUT TOKEN DATA, or NOT PRESENT. Anything other than READY on both means the later results are not trustworthy yet. See Prerequisites.

01 · Observed consumption by day

Daily request volume and token consumption.

UsageCoveragePct is the share of that day's requests the totals are derived from. A day showing high volume and low coverage is a day where the token telemetry is incomplete — not a cheap day.

02 · Where consumption concentrates

Requests and tokens by model and deployment, with each row's share of total volume. Values that were never reported, or that records disagreed on, group under (not reported) rather than being dropped — dropping them would shrink the denominator and overstate everything else.

03 · Attribution gaps

How much observed consumption cannot be tied to an accountable API and operation. Five outcomes:

Result	Meaning
ATTRIBUTED — API, operation and product	Fully accounted for
ATTRIBUTED — API and operation, no product	Accountable, no product dimension
PARTIAL — API known, operation not identified	Half attributed
UNATTRIBUTED — gateway record carries no API or operation identity	The gateway saw it and could not name it
UNATTRIBUTED — no gateway record for this model call	A model call with no matching gateway record at all

The unattributed rows stay in the denominator. That is the point of the query: the share you cannot account for is the finding.

04 · Failure and retry waste

Consumption grouped by request outcome — succeeded, 4xx, 429 throttled, 5xx, and indeterminate where gateway records disagree on status.

Tokens consumed under a 5xx were paid for and thrown away. That is exact.

429s are reported as throttling pressure, which is what drives client retries — not as a retry count. TokensConsumed is absent, not zero, for any outcome where no request reported usage: a throttled request that never reached a model has no consumption to report, and "we have no telemetry" must not render as "this cost nothing".

05 · Validation candidates

Operations ranked by input context paid for relative to output produced, highest total input first.

A high input-to-output ratio is the signature of context that may not be earning its cost — retrieved documents that go unused, prompts that accumulated, history replayed every turn.

It is a candidate and nothing more. Whether that context is waste or the reason the output is correct cannot be established from a log. No threshold is applied. Ranking is by total input tokens rather than by ratio, so a trivial operation with an extreme ratio does not outrank a dominant one.

Operations that produced no output at all show an absent ratio rather than infinity.