Shift log: missing usage and estimated charges

The request completed, but the response did not include usable billing metadata. The duty desk now has two separate questions: did the application receive useful output, and what evidence supports charging for it? A successful response answers the first question, not necessarily the second.

For missing usage, two approaches deserve a head-to-head review: post a provisional estimate immediately, or leave the charge pending until authoritative usage arrives. Neither turns missing data into certainty. The operational difference is where each approach puts the uncertainty.

The missing usage field is not a zero-cost signal

Usage can be unavailable because a stream ended before its final metadata arrived, a client failed to retain that metadata, or an upstream response omitted it. A timeout also does not prove that processing stopped before billable work occurred.

Record the request identifier, model, timestamps, completion state, response identifier when available, and any usage fields actually received. Preserve the distinction between absent data and an explicit zero. Without that distinction, a billing incident can quietly become an accounting error.

Immediate estimates make spend visible sooner

A provisional estimate uses available evidence, such as retained request content and visible output, to approximate usage. It can give teams an early budget signal instead of leaving active workloads looking artificially inexpensive.

The weakness is precision. Local tokenization may not match provider accounting. Cache treatment, tool-related content, non-visible processing, and model-specific billing dimensions may affect the bill where applicable. Counting characters is an even rougher approximation, not a replacement for usage records.

Consider a Claude Haiku 4.5 request whose visible output was saved but whose final usage metadata was lost. A local estimate may help identify an unexpectedly large response. It cannot, by itself, establish every billable component.

• An estimated record should identify its calculation method and the evidence available at the time.
• The displayed amount should remain distinguishable from a confirmed charge.
• Any later correction should preserve the original estimate and explain the adjustment.

Pending charges protect accuracy but delay visibility

A pending record acknowledges that work may have occurred without pretending the amount is known. If authoritative usage later becomes available, the system can apply the relevant rate and finalize the charge.

This approach is stronger for auditability, but weaker for immediate spend reporting. A dashboard that shows only confirmed charges can understate exposure while requests remain unresolved. Teams need a visible pending-request count and, where useful, a separately labeled estimate of that exposure.

Pending must also have an operational owner. Otherwise, unresolved requests become a permanent blind spot. Define a review process, an escalation path, and a documented outcome when usage cannot be recovered. Do not assume every provider can supply missing records later.

The billing calculation needs more than a token guess

Both approaches need the applicable model rate, the billing dimensions covered by that rate, and the units used. Keep input, output, and any other applicable categories separate. Use the pricing terms relevant to the request rather than silently recalculating old activity with today's prices.

Retries require special care. A repeated operation can represent multiple upstream requests, while a duplicated log entry can represent just one. Reconcile identifiers before adding charges. Application success, retry count, and billable usage are related evidence, not interchangeable measurements.

Relay365 fits consolidated access, not assumed billing rules

Relay365 is a pay-as-you-go relay desk for multiple model families and works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. That makes it relevant when a team wants consolidated access across tools and models.

Those capabilities do not establish its missing-usage charging policy. Before relying on estimates, ask how provisional amounts are identified, whether they affect the available balance, and how corrections are recorded. Create a Relay365 account if that access model fits your workflow, then verify these billing details before scaling traffic.

The shift verdict favors estimates for alerts, evidence for settlement

For budget alerts, provisional estimates win. They surface potential spend earlier, provided their uncertainty remains visible.

For final billing, authoritative usage wins. A pending charge is preferable to presenting an unsupported estimate as measured consumption. If unrecoverable usage is settled using estimates under disclosed terms, the record should still identify it as estimated. Missing metadata is a reconciliation task, not permission to invent certainty.