Reading Your Usage Records: Models, Tokens, Cache and Cost

The console records usage per request, not as a monthly total. This is what each column means — and where to look first when the question is "why did this call cost more than the last one".

What each record contains

Model and group The model actually used, the protocol it went through (Anthropic- or OpenAI-compatible) and the service group. When debugging "but I configured model A", start here: this column records what the gateway received, not what you believe you sent.

Token breakdown Input tokens, output tokens and cache-related tokens are recorded separately. They are priced differently, which is the main reason two conversations of similar length can differ several-fold in cost.

Billing mode and cost Not everything is billed per token. The gateway distinguishes token-based, per-call, image and video billing — image generation and video endpoints are typically priced per call or per artifact, not on the same basis as chat requests. This column tells you which applied.

Request type and latency Call time, endpoint type and processing latency. Latency is more useful than logs when a client appears to hang: if the gateway-side latency is low, the problem is between your client and the gateway rather than in the model.

Why cache tokens are tracked separately

For cached requests, the portion of input tokens served from cache is priced well below regular input. That produces a counter-intuitive result: two requests with identical input length can cost very differently, because the second one hit the cache.

So when cost fluctuates, compare the cache token column before suspecting anything else. It shows up most clearly with long contexts and repeated system prompts.

Where failed requests go

Failed requests are kept in a separate error log, not mixed into usage. The benefit is that usage statistics are not polluted by failures; the cost is that you have one more place to look when debugging.

If your client reports an error but you cannot find a matching entry in the usage list, check the error log — it usually shows directly whether the cause was authentication, an unavailable model or an upstream timeout.

Common discrepancies

My request is not in the usage list Most likely the configuration never took effect and the client is still using its previous credentials against the official endpoint. Everything looks normal client-side; only the usage list is empty. This is why it is worth checking usage after every setup change.

Same prompt, noticeably more expensive Check three things in order: is it the same model (see model and group), is the output longer, and did the cache hit. Most variance is explained by one of these.

The cost figure does not make sense Check the billing mode column first — per-token and per-call figures are not directly comparable.

Using it for cost control

Because records are per request, you can attribute spend to specific kinds of calls:

• Grouping by model shows whether some tasks could move to a cheaper one
• The share of cache tokens shows whether long prompts are actually being cached
• The volume in the error log matters too — failed requests still cost time and retries

To separate spend by purpose completely, issue a different API key per use case and give each its own quota. See "Setting Quotas and Expiry on API Keys".