Reading a Per-Request Cost Log, Line by Line

A per-request cost log should explain a charge, not merely display one. When investigating an unexpected bill, read each record in a consistent order: identity, execution, usage, pricing, and settlement. For teams using CodeRelay Hub, this gives engineers a practical way to investigate activity across a shared API endpoint without treating every integration as a separate accounting system.

The field names below are illustrative, not a documented CodeRelay Hub schema. Match each concept to the fields available in your logs and billing export.

1. Establish what one line represents

Before interpreting any amount, determine whether a line represents a client operation, an upstream attempt, or a billing event. These are different units. One user action might produce several attempts, while a later record might finalize an earlier charge. Write down the record type and its timestamp. If your export does not identify its accounting unit, resolve that ambiguity before summing anything.

2. Anchor the record to a request

Start with identifiers such as request_id, trace_id, and attempt_id. Use the request identifier to find the corresponding application log, then use the trace identifier to connect related work. An attempt identifier helps separate an original call from a retry. Preserve these identifiers in your investigation notes; timestamps alone are weak join keys when requests overlap or clocks differ.

Next, locate the workspace, service, environment, or credential label responsible for the request. Prefer a nonsecret credential identifier, never the API key itself.

3. Check what actually executed

Read the requested model separately from the model recorded as executing the request, if both are available. A request labeled Claude Sonnet 5 identifies the intended model, but it does not by itself establish which pricing rule the ledger applied. Inspect any recorded route, model version, or billing SKU rather than deriving a rate from a display name.

Also check the outcome. An application error is not enough evidence to conclude that no billable work occurred. Look for explicit usage and billing status.

4. Interpret usage without double counting

Separate input, output, and any cache-related counters. Before adding them, establish whether cache reads or cache writes are included in the reported input total or listed as additional categories. A field named total_tokens is useful only after you understand its definition.

• Input usage: Identify the quantity associated with material sent into the model.
• Output usage: Identify the quantity associated with generated material.
• Cache usage: Determine whether these quantities overlap with another counter.

Do not estimate billable usage from the visible response length when a recorded usage measurement exists.

5. Reconstruct the charge with matching units

Find the applicable rate, currency, pricing unit, and effective pricing version. A token count cannot be multiplied directly by a rate until their units match. For each category, the calculation is quantity divided by rate-unit size, multiplied by rate. Then apply any separately recorded adjustments according to the ledger's rules.

Keep full available precision while checking the calculation. Round only at the documented boundary. If the export contains a final charge but no rate breakdown, treat that as an audit limitation rather than reverse-engineering an authoritative rate from a rounded amount.

6. Follow retries and interrupted streams

Search for sibling attempts sharing the same logical operation. Keep their charges separate before calculating an operation-level total. Do not deduplicate records merely because their prompts or timestamps look similar; confirm that they are duplicate records, not distinct attempts.

For a canceled or disconnected stream, distinguish what the application received from what the billing record reports. If usage is absent, mark the charge as unresolved rather than substituting zero. A missing measurement is not a confirmed free request.

7. Reconcile against the billing ledger

Finally, compare finalized request charges with the billing ledger over the same time window, currency, and workspace. Account for pending entries, credits, reversals, and settlement timing separately. Keep request execution time distinct from posting time so a delayed charge does not appear to be missing.

A useful investigation ends with an attributable operation, identifiable attempts, interpretable usage, and either a reconciled charge or a specific missing field.

Open a free workspace to get started.