The question
What can this run spend?
Count every admitted paid path, including the attempts that may fail.
Illustrative model · Human review pending
Estimating the maximum cost of an agent run
Set a spending ceiling before an agent starts. Count every permitted paid step, its possible retries and a bounded tool allowance, then hold that amount until charges are reconciled.
The proposal
Reserve. Run. Reconcile.
Hold the conditional ceiling before dispatch. Replace holds with confirmed charges.
The evidence
A model you can inspect.
Equations and a reproducible example. Current production coverage is not established here.
01 / The question
A small request can become a larger bill.
A workflow is more than its successful first attempt. Two readers may run in parallel, a synthesis may retry, and a tool may charge even when the client never receives a result.
Our question is deliberately narrow: for a finite, defined workflow, can we reserve enough to cover every allowed paid attempt before it starts? We want a conditional upper bound, not a prediction of the average invoice.
A timeout tells us that waiting ended.
It does not, by itself, prove that the remote operation stopped. AWS describes this ambiguity and the risks of repeating side effects in its guidance on retries. [1] Whether a particular request is billable still depends on that provider's contract and receipt.
02 / The workflow
Make the paid paths visible.
Think of the system as a small graph. Every paid node needs an attempt ceiling and a cost ceiling. Parallel readers add to the budget; they do not share one call's allowance.
- 01 / Inventory
Define the work
Readers, synthesis, tools and all allowed retries.
- 02 / Reserve
Check the budget
Reserve the run's ceiling atomically, or decline to start.
- 03 / Dispatch
Use held capacity
Each paid attempt consumes its own allocated capacity.
- 04 / Reconcile
Keep the record
Settle confirmed charges. Keep uncertain attempts held.
For exclusive branches, take the larger branch ceiling and add any shared work separately. This is valid only if exclusivity is enforced. If both branches can run, add them. A loop without an enforced maximum has no finite bound in this model.
03 / The mathematics
Start with one attempt.
Then count every attempt.
For a token-priced call, give both input and output a maximum. Use rates in the same currency and the same unit basis. Include every other billable item inside the chosen scope.
Equation 01 / One attempt
ci = (Iipin,i + Oipout,i) / 106 + fi
Maximum input cost + maximum output cost + fixed charges per attempt.
- Ii, Oi
- Enforced input and output token ceilings for step i.
- pin,i, pout,i
- Verified prices per million tokens, in one currency.
- fi
- Other capped charges per attempt. Do not count these again in the tool allowance.
- ci
- A ceiling for every admitted attempt of that step, including retries.
Next count logical calls and extra attempts. Here ri means additional billable submissions: two retries means up to three total attempts.
Equation 02 / Whole workflow
Brun = ∑i ni(1 + ri)ci + Btools
Calls × attempts per call × ceiling per attempt, plus the workflow-wide tool allowance.
- ni
- Maximum number of logical calls of type i, including parallel branches.
- ri
- Maximum extra paid attempts per logical call across all retry layers.
- Btools
- A separate, enforced allowance for all tool charges across the entire run.
- Brun
- The amount reserved before starting. It is not expected spend.
Why this is an upper bound
For call k of step i, at most 1 + ri billable attempts occur, and each actual charge xika is no greater than ci. Their sum is therefore no greater than ni(1 + ri)ci. Summing over all paid steps and adding a tool total no greater than Btools gives actual in-scope cost ≤ Brun.
No independence or success probability is needed. The statement fails if a paid path is omitted, a ceiling is unenforced, or a charge exceeds the rate and quantity assumptions. If retries use a more expensive model or a larger context, ci must cover that alternative too, or each alternative must be bounded separately.
04 / Explore the model
What does retry capacity cost?
Use two readers and one synthesis as an example. Each reader attempt is capped at €0.04, the synthesis at €0.10, and all tools together at €0.08. These invented amounts make the arithmetic easy to inspect; they are not vendor rates, Converze prices or production limits.
| Paid step | Calls | Attempts / call | Ceiling / attempt | Subtotal |
|---|---|---|---|---|
| Readers | 2 | 3 | €0.04 | €0.24 |
| Synthesis | 1 | 3 | €0.10 | €0.30 |
| Tools | One allowance across the entire workflow | €0.08 | ||
| Conditional run ceiling | €0.62 | |||
Interactive / Entirely in your browser
Change the assumptions.
Keep the example's unit costs fixed. Explore how fan-out and retry capacity affect the ceiling.
Up to 3 total attempts per call.
A fictional amount available for this run, after other commitments.
Illustrative ceiling under these inputs
€0.62
Within the example budget · €0.13 remains.
One attempt per step: €0.26. Extra retry capacity: €0.36.
The model makes no requests, purchases or changes to a real budget. Reserving retry capacity does not mean every retry will be used.
The default calculation
3 × (2 × €0.04 + €0.10) + €0.08 = €0.62.
One attempt per step gives a €0.26 ceiling. The extra €0.36 is capacity for retries, not a prediction of an additional charge. The €0.08 tool allowance covers all attempts; if tools instead cost €0.08 per full pass, that different model would give €0.78.
| Extra attempts / call | Total attempts / call | Run ceiling |
|---|---|---|
| 0 | 1 | €0.26 |
| 1 | 2 | €0.44 |
| 2 | 3 | €0.62 |
| 3 | 4 | €0.80 |
| 4 | 5 | €0.98 |
05 / Missing receipts
Uncertain spend still occupies the budget.
A useful ledger separates settled charges S from outstanding reservations H. New work can start only when the following check and the reservation happen as one atomic operation.
Equation 03 / Admission
S + H + Brun ≤ Bapproved
Charges already settled + money still held + the new run's ceiling must fit within the approved budget.
Allocate attempts from the run's existing hold. Do not reserve them a second time. When a receipt confirms a charge x against an allocation h, replace that allocation with the charge: (S, H) becomes (S + x, H − h). When x ≤ h, only the unused difference h − x becomes available. A charge above h breaks the assumed ceiling and requires the overage handling described in Assumptions & tests.
- 01
Reserve the example run.
With €0.75 approved and nothing previously spent, hold €0.62. Reader A's first attempt times out. Its €0.04 allocation stays inside the hold.
Settled €0.00Held €0.62Available €0.13 - 02
The retry returns a €0.03 receipt.
Settle this retry's separate €0.04 allocation. Release €0.01. The first, uncertain attempt remains held.
Settled €0.03Held €0.58Available €0.14 - 03
The original attempt later costs €0.04.
Its receipt settles its own allocation. No extra capacity is released. Remaining holds cover work still pending or not yet started.
Settled €0.07Held €0.54Available €0.14
Deduplicate receipts and use explicit operation identities. Idempotency is a provider contract, not something a client can assume. [2] At the end, release unused, unstarted work. Keep dispatched but unresolved work held until reconciled. Stopping new calls cannot undo work already accepted.
The race that a formula cannot fix.
Two jobs can each read €0.75 available and each decide that €0.62 fits. Together they expose €1.24. The comparison and reservation must be indivisible, with persistent recovery after a crash.
06 / Three approaches
A forecast and a ceiling answer different questions.
| Approach | Useful for | What it misses |
|---|---|---|
| Average-cost forecast | Planning likely spend from observed usage and retry behaviour. | Averages do not bound an individual run. No measured distribution is supplied in this note. |
| One-attempt ceiling | Bounding a workflow that permits exactly one attempt per call. | Understates exposure if a retry, fallback or repeated tool charge is still allowed. |
| Bounded attempts + reservation | Admitting a finite set of possible charges before work starts. | Depends on complete scope, valid rates, enforced limits and a correct ledger. |
The third approach is more conservative. It can delay work that would have completed cheaply. That is an explicit trade-off: predictable exposure in exchange for holding capacity that may never be spent.
07 / Assumptions & tests
Show where the model can fail.
Rates are valid.
Pin the provider, model, pricing basis and effective date. Check all billable units. Taxes, currency conversion, storage and other charges require explicit allowances if they are in scope.
Quantities are enforced.
Input growth, output, fan-out and nested retries must fit the inventory. An unbounded fallback invalidates the calculation.
Uncertainty stays visible.
A missing receipt is not evidence of a zero charge. Do not free an uncertain hold just because a timer expired.
The ledger is durable.
Reservation and settlement need atomic updates, deduplication and recovery. For real currencies, use fixed-point units and round ceilings upward.
Checks required for an implementation
- Two simultaneous reservations cannot both consume the same available amount.
- A duplicate receipt changes the ledger only once.
- A timed-out request retains its allocation when a retry succeeds.
- A crash between dispatch and receipt recovery does not erase the reservation.
- Missing or invalid prices prevent new paid work.
- A confirmed charge above its allocation is recorded honestly and stops further admissions while the broken assumption is investigated.
The explorer checks arithmetic and admission decisions with fictional data. It does not execute these distributed-system tests or establish that a deployed service passes them.
08 / Sources & evidence
Separate the method from the proof of use.
Described
Conditional model, assumptions, proof sketch and worked example in this reading edition.
Reproducible
Fictional input data, integer-cent arithmetic and sensitivity cases available below.
Still open
A redacted, pinned implementation inventory, matching deployment evidence and independent technical and human review.
Engineering references
- Marc Brooker · Timeouts, retries, and backoff with jitter ↗
AWS Builders' Library. Background on ambiguous outcomes, retry amplification and bounded retry strategies. Checked 3 November 2026.
- Malcolm Featonby · Making retries safe with idempotent APIs ↗
AWS Builders' Library. Background on explicit operation identities, duplicate requests and late arrivals. Checked 3 November 2026.
These references support the engineering context. They do not verify this cost model's deployment or the billing behaviour of any LLM provider. The equations and example are an explanatory development of Converze's 28 October 2026 method draft; they are not an empirical study or a peer-reviewed result.
Revision and disclosure
Version 0.4 expands the earlier prose draft with explicit assumptions, three equations, a fictional example, a budget explorer and sources. It adds no customer observations and makes no claim of measured savings. Original method draft: 28 October 2026. This reading edition: 3 November 2026, prepared with AI assistance. Independent technical and named human review remain pending.
No operational thresholds, private prompts, credentials or customer records are included. The amounts in the explorer are invented for explanation and do not reveal production limits.
Continue the research
Evidence belongs to a version.
Why a review has to match the exact thing that ships.
Read the next note ↗Explore our services ↗Evidence and next check
The example inputs and derivation are available here. Production enforcement is unverified. The next check is to test the reservation and recovery rules against concurrent requests and missing receipts.