Shift Note: Keep Missing-Usage Charges Provisional

The request completed, but the usage fields never arrived. Or the connection dropped after generation began, leaving the application without a final accounting record. The duty desk still needs a cost number, finance still needs a defensible ledger, and neither team should mistake an estimate for a settled charge.

The practices worth keeping this year are straightforward: preserve uncertainty, record the calculation basis, and reconcile without losing the original trail. Missing usage is an accounting exception, not evidence that a request was free.

Keep estimated cost separate from confirmed usage

A successful response and a complete usage report are different events. Streaming interruptions, logging gaps, and delayed reporting can leave one present without the other. Record the request outcome separately from the availability of usage data.

Give every cost record an explicit status, such as estimated, confirmed, or unresolved. Store the amount alongside its currency, pricing source, calculation time, and reason for estimation. A dashboard can show a combined planning total, but it should also expose how much remains provisional.

An internal estimate is not automatically the provider’s bill. Call it an estimated cost unless the billing source actually identifies it as a charge. That distinction matters when engineers explain spending to customers or approve a budget adjustment.

Save the evidence needed for the next shift

Keep the request identifier, requested model, timestamps, response status, and any available usage fields. If a gateway exposes separate identifiers for its own request and the upstream request, preserve both. Avoid retaining sensitive prompt content merely to make accounting easier.

• Record the applicable rate and its effective date rather than recalculating historical requests with today’s price.
• Distinguish reported usage from locally counted or inferred usage, including partial counts.
• Track retries as separate attempts while associating them with the same application operation.
• Preserve available evidence about cancellation and interrupted streams without assuming either event eliminated billable work.

These records make a handoff useful. The next engineer should be able to explain the estimate without reconstructing a terminal session or guessing which rate table applied.

Use an estimation method that admits its limits

When authoritative usage is unavailable, apply a documented fallback suited to the request. A local token count may support a text-only estimate, but it may not reproduce the provider’s accounting. Cached input, tool activity, media processing, and other billable categories can require different treatment.

For example, if an application routes a request to Gemini 2.5 Flash, use the applicable published pricing categories and known request attributes. Do not silently substitute the rates or tokenization assumptions of another model. If important inputs are unknown, show a range or mark the amount unresolved instead of manufacturing precision.

Keep the method version with the estimate. Changing a fallback formula should not silently rewrite last month’s ledger.

Reconcile without charging the same attempt twice

Run reconciliation when authoritative usage or billing records become available. Match records using stable identifiers where possible, and treat timestamp-only matches as weaker evidence. Replace the provisional contribution to totals rather than adding a confirmed amount on top of it.

Retain the original estimate and the adjustment for auditability. Investigate recurring differences by model, request path, and failure mode. Persistent missing usage deserves an operational owner, not a permanent exception hidden inside a spreadsheet.

Check the relay’s accounting rules before relying on them

Relay365 is worth considering when a team wants pay-as-you-go access across multiple model families through a relay desk. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. For OpenAI clients, its API base is https://api.api365relay.com/v1.

Before adopting any relay, verify how it labels missing usage, calculates provisional amounts, handles retries, and exposes later corrections. Do not infer these behaviors from SDK compatibility. Create a Relay365 account if that access model fits your workflow, then check its current billing documentation and available records before depending on them for reconciliation.

The shift can close with unresolved records. It should not close with uncertainty disguised as a final number.