Build an LLM Cost Ledger That Includes Failed Requests

The useful unit in an LLM budget is accepted work. Build a small ledger that includes unsuccessful requests before comparing providers or announcing savings.

Define the row

Use one row per attempt with a task identifier, model identifier, timestamp, input usage, output usage, cache usage, paid tool usage and validation result. Keep retry attempts linked to the original task. Do not record private prompt content merely to calculate cost; a reference and task category may be sufficient.

Reconcile the totals

Calculate each charge with the dated price table for the selected service tier. Keep cached input and any cache storage separate. Compare your calculated total with the provider’s usage or billing view and explain any difference before using the ledger to choose a model. An estimate that omits failed calls is an incomplete baseline.

Compare accepted work

Divide total attributable cost by accepted tasks, then report the failure rate beside that number. If two configurations use different validation rules, their costs are not yet comparable. Re-run the same task set with the same acceptance rule and include the extra attempts required by either configuration.

Make the result actionable

Review the largest cost category first. A long output, repeated retrieval or a retry loop may matter more than the list price. Change one component, retain the baseline and keep a rollback threshold. This worksheet does not claim any measured saving.

Source and scope

Reference checked on 7 September 2026: Gemini API pricing. This article provides an editorial workflow. It does not report a paid account test or guarantee a platform outcome.

Separate a task from its attempts

Give the user’s requested job a stable task identifier and each model call a separate attempt identifier. A task that succeeds on its third call should remain one accepted task with three attributable attempts. Store the configuration version alongside the identifiers so that a later model or prompt change can be compared fairly. Keep the record independent of the full prompt where possible. A task category, usage values and validation outcome may answer the cost question without making the ledger a second repository of sensitive source documents.

Use explicit units in every column

Token counts, monetary amounts and elapsed seconds need separate fields. Record the currency and the unit used by the provider’s price table, such as a rate per million tokens. Keep input, output and any reported cached usage distinct. A cached quantity may already be part of a broader usage total, so read the provider’s field definitions before summing columns. The same caution applies to tools and storage. A ledger that double-counts cached tokens can be as misleading as one that omits them entirely.

A worked example with hypothetical charges

Suppose ten tasks create twelve attempts. The provider charges a total of 1.20 currency units across those attempts, and eight tasks satisfy the acceptance rule. Cost per accepted task is 1.20 divided by eight, or 0.15 units. Dividing by twelve instead would describe cost per attempt, a different metric. These are invented values for arithmetic, not benchmark results. Report the two unaccepted tasks beside the cost figure. Otherwise a configuration that abandons difficult work may appear efficient without delivering the same useful workload as its alternative.

Handle incomplete usage records openly

Some failures may not return the usage detail you expect. Mark those rows as incomplete rather than assuming a zero charge. Reconcile against the provider’s usage or billing records and keep an adjustment row if the aggregate cannot be assigned precisely to one attempt. Explain the remaining difference. This is particularly useful when a timeout leaves the client uncertain whether the server finished processing. Your application’s error message and the provider’s billing event are separate observations, and neither should silently overwrite the other in the ledger.

Make acceptance independent of price

Define the acceptance rule before reviewing which model was cheaper. For extraction, it may require every non-empty field to be supported by the source. For a coding task, it may require a particular test to pass. Keep human review effort visible if it is part of normal operation. Do not loosen the checker for a low-priced model and then compare its apparent success with a stricter baseline. The purpose is to price the same useful outcome. If different task categories need different rules, report them separately before creating an aggregate.

Use reconciliation as a release gate

Before making a routing decision from the ledger, compare a bounded period with the provider’s actual usage view. Confirm model identifiers, service tiers and dated rates, and investigate unexplained differences. Save the baseline and the calculation version. After changing a prompt, retry policy or provider, repeat the same comparison on an appropriate workload. The ledger should make a decision auditable: which cost changed, whether acceptance changed and which uncertainty remains. It should not become a dashboard that displays precise numbers after losing track of how they were calculated.