Cost per attempt: what must the billing record prove?

The total can be right and the bill still unexplained. To trust an AI budget per task, the company must demonstrate the cost per attempt: which attempts had billable usage, how the price was applied, whether the record survives failures and how the internal amount compares with the provider billing.

When a request is resent or changes route, the dashboard can present the correct sum without identifying the attempt. The total satisfies finance, but it does not resolve the investigation of a divergence or of a fallback policy.

The thesis is simple: cost per attempt is not a new tariff. It is an evidence requirement before a total becomes an operating limit for the period under analysis.

Does one request show every attempt?

A request may include several attempts and still appear as a single line in the report. If that line correctly includes every cost, the total is not wrong. The limit is elsewhere: without per-attempt attribution, the company cannot separate the effect of each send.

Task is the work that must reach an accepted result. Request is a logical call made to fulfill part of that work. Attempt is each send that seeks to serve the request. One task may involve several requests; one request may have retries of AI calls or turn to another route. Those units are not interchangeable.

When consulting the OpenTelemetry HTTP conventions, the team must check which spans the instrumentation emits per send and for the parent operation, and also how it fills the http.request.resend_count attribute, including on redirects. The field must not be used as proof of billing.

The OpenTelemetry HTTP conventions recommend one span for each send attempt and allow one span for the parent operation when the instrumentation cannot emit one per attempt. These are different granularities. In the redirect example of the conventions, a 302 response precedes another send whose http.request.resend_count is 1. Before attributing cost to the send, the team must identify the granularity emitted and verify the applicable usage and billing conditions.

A timeout is not a receipt either. After a timeout, the team must verify the applicable usage and billing conditions. Until the determination, the amount may remain unknown; the error proves neither free service nor spend.

The LLM call trace helps to examine route, call and policy. The next question: what supports the charge, and how does it line up again with the other views after a failure?

What must an AI cost-per-attempt record preserve?

The record must let someone identify the attempt, understand the known usage and reconstruct the price applied at that moment. It must also survive the failure of the process that reads it. These are evaluation criteria, not the mandatory description of a single architecture.

An identifiable charge should point to the request and the attempt, with the state of the determination. A stable identifier helps distinguish a new entry from a re-presentation. The absence of confirmed usage must remain explicit: unknown cost is not zero cost.

Price is evidence too. To explain the bill, the record must preserve the model used, the provider, the billing unit, the currency, the effective date and the relevant contractual conditions. If the applicable rule changed after the call, recalculating the past with the current table can produce a different amount even though the original consumption did not change.

When evaluating the OpenTelemetry generative AI attributes, the team must check whether the instrumentation emits operation, model and tokens, and whether the attributes in use have been moved or deprecated. It must also compare the estimate with the billing evidence, without confusing the two.

The GenAI record marks gen_ai.usage.prompt_tokens as deprecated and points to gen_ai.usage.input_tokens as the replacement, moved to the GenAI conventions repository. The field name matters. The team must check the version and the effective emission of the instrumentation before using the count to reconstruct a historical estimate, which still depends on the applicable pricing rule.

Preserving an estimate does not turn it into a confirmed charge. The comparison with the provider usage data or invoice requires compatible scope, period and currency. If the external evidence does not detail the attempt, the divergence stays open at that level.

What happens when the report fails?

A failure in the report should not erase a charge already recorded nor settle it twice. The buyer must test how the system identifies pending work, resumes processing and protects each consumer against repetition. Budget and report can be in different states while recovery is under way.

One possible design starts at the attempt, captures the known usage and ties the charge to the price context. Then a durable record supports the settlement of the budget and the update of the report. The consumers can advance at different moments. The figure below represents a generic evaluation criterion, not a product implementation.

If the report update fails after settlement, the test must show the pending item and the resumption without a new debit for the same charge already settled. The reverse also deserves inspection: an updated report must not be confused with a completed settlement. Protection against duplication must be verified in each consumer; it does not demonstrate exactly-once delivery across the whole system.

An active reservation is not settled spend. The reservation sets capacity aside for an operation in progress; settlement records the determined amount. The admission policy considers settled spend, active reservations and pending exposure, without counting the same share twice and with safe update or coordination under concurrency. When the maximum cost or the usage of an attempt is unknown, a conservative reservation requires a justifiable limit; without one, the policy blocks admission or keeps the operation pending. Adjusting or releasing the reservation requires checking the state and the known usage, without erasing a charge still subject to reconciliation.

When consulting the PostgreSQL transactions, the team must check the scope of the atomicity and persistence guarantees and test reconciliation and deduplication across consumers. A database transaction, on its own, does not prove coordination between components.

The PostgreSQL 18 transactions tutorial describes an atomic operation: for the other transactions, the changes happen entirely or not at all. The tutorial describes persistence after the commit, but durability depends on the configuration and on the failure domain tested. With synchronous_commit=off, the server can confirm before the durable write to the WAL, and a crash can lose recently committed transactions. The buyer must check synchronous_commit, the storage guarantees and, where applicable, replication and failover. The boundary matters. Database acknowledgement does not prove durability under every configuration, coordination between consumers, resumption of the report or reconciliation with the external charge.

Can a per-request total be enough?

Yes, for aggregate tracking, as long as the total correctly includes the attempts within the measured scope. That view is useful to follow the spend of a set of requests. It does not replace per-attempt attribution when the decision requires explaining a charge or evaluating a route.

The objection to a detailed record is legitimate: there is a cost of storage, integration and maintenance. If the team only needs to follow the total for a service, requiring a per-attempt investigation for every decision can be disproportionate. The choice changes when the organization must answer why a budget was consumed, compare fallback policies or contest a difference with the provider, using the external billing data available.

Internal systems can agree with each other and still diverge from the invoice if they start from the same incomplete data. Reconciliation records differences and adjustments. It also records the items without a match.

What is missing to calculate cost per task?

The cost attributed to an individual task gathers its relevant costs, including those outside the gateway, regardless of success, rejection or abandonment. The link crosses successive requests without confusing attempt with task. That calculation does not require an accepted result; it requires an attribution rule.

The average per accepted task is another metric: the sum of the relevant costs of the declared cohort divided by the number of accepted tasks in the same cohort. Without accepted tasks, there is no computable average. The policy must declare how it treats the costs of rejected and abandoned tasks; omitting them without declaring it distorts the interpretation of the average. It must also define period, scope and attribution rule, and which result is accepted, by whom and when. The average is not the only valid metric.

The OpenTelemetry HTTP retry example shows one received request followed by three client sends, two with a 500 response and one with a 200 response. It is a trace, not a completed task. The spans illustrate the multiplicity of sends; they do not establish which result the application accepts, nor how much was charged, nor how the sends link to the business task.

Scope must be declared. The team must check whether calls outside the gateway appear in the records, through which sources and how they are attributed. If they are relevant and are not in the records, they need another source and attribution. The analyses of the real cost of the application beyond the price per token and of token price and cost per task widen the economic decision; here the point is the proof that supports the bill.

When the usage remains unknown, both calculations must show the pending share and must not present the total or the average as complete until the determination. Filling the gap with zero improves the appearance of the report and worsens the decision.

How does the buyer test the claim?

The test must follow a charge from the attempt through the internal views and the available provider evidence, so that the buyer can compare the records and check whether recovery preserves the charge. The dashboard is not enough. A controlled failure reveals the states after resumption.

1. Historical price reconstruction. The buyer must choose a charge whose usage and conditions are available, check model, unit, currency and effective date, and ask for the calculation to be reproduced without replacing the old rule with the current one.
2. Attempt inspection. For a request with a resend or a route change, the team must compare the total with the attempts recorded. The analysis separates confirmed cost, justified zero and unknown usage, and also checks what the instrumentation actually emits.
3. Report interruption. In a test environment, the team must prove the initial state, with the charge recorded and the budget already settled, and then trigger the report failure. The pending item must become identifiable. After the resumption, the team re-presents the same identity and verifies a single settlement and a recovered update of the report.
4. Repetition in each consumer. The team must re-present the identity to each consumer and trigger a failure between applying the effect and marking the identifier as processed. After recovery, it must prove a single effect and demonstrate atomicity between the two or equivalent protection, without requiring a specific architecture and without claiming exactly-once delivery end to end.
5. Concurrent reservations. The team must test simultaneous admissions, adjustment and release of reservations and usage still unknown, checking whether exposure remains covered, without duplication, according to the policy. The result must show how coordination prevents concurrent admissions above the ceiling under the conditions tested.
6. Comparison with the provider. The buyer must align period, currency and scope with the external data available and record differences and limits of detail. If there is not enough external evidence, per-attempt reconciliation remains pending.

The test requires an explanation that another person can verify.

Frequently Asked Questions

The doubts involve the cost of a retry, the trust placed in a delayed report and the way reservations enter the account, but the answer depends on the state of each charge and on the evidence available. The result displayed by the application is not enough to classify the charge.

Is every retry of an AI call billable?

One should assume neither that every retry is charged nor that it is free. The classification requires checking the provider usage and conditions for each attempt. Identifying the attempt allows a later audit. An error or a timeout, on its own, does not resolve that classification.

Does a delay in the report mean a lost charge?

Not necessarily. The charge may be recorded while the report waits for processing. The team must check the pending item, the resumption and the protection against duplication, and also identify charges that still lack sufficient confirmation. While the confirmation does not arrive, the amount must stay separate from the reconciled total.

Are a reservation and settled spend the same thing?

No. A reservation is budget capacity set aside for an operation; settled spend is the amount determined under the adopted rules. Adjusting the reservation does not remove the need to check the usage and the charge of that operation. The buyer must ask which of the two numbers appears in the report.

Is cost per request the same as cost per task?

Not necessarily. One task may involve several requests, attempts and costs outside the gateway. The cost of an individual task does not depend on acceptance; the average per accepted task requires a declared acceptance criterion and cohort. The calculation must include the relevant spend of rejected tasks when the accounting policy covers them.

References and Further Reading

The references separate telemetry conventions, transaction properties and cost decisions, while the two Nexforce readings deal with the call trace and the difference between token price and cost per task. The invoice requires its own verification.

• OpenTelemetry: conventions for HTTP spans.
• OpenTelemetry: generative AI attributes.
• PostgreSQL: transactions.

The examples cited are in these sections of the sources:

• OpenTelemetry: HTTP retry example.
• PostgreSQL 18: transactions tutorial.
• PostgreSQL 18: WAL and synchronous_commit configuration.

The internal readings complement the technical analysis and the budget decision:

• LLM call trace.
• Token price and cost per task.

What evidence must come before the limit?

The next step is to ask for a verifiable charge, not another chart. The team must explain the attempt, recover the historical price, test the resumption after the failure and compare the record with the available billing evidence. The condition matters.

A ceiling can only be guaranteed within the assumptions and limits actually demonstrated; outside them, it is control or estimate, not an absolute guarantee.

The Nexforce Router brings together routing, fallback, retries, ceilings per key or project and observability. Those capabilities help govern calls, but they do not by themselves demonstrate the four accounting proofs discussed here. For any implementation, the buyer must verify what is effectively recorded, how the states are reconciled and which costs fall outside that reach. A limit is a decision; the evidence says whether the decision deserves trust.