# Attach one budget to the whole task

Give every model call and tool attempt the same task identity, then reserve capacity before dispatch. This makes cost controls work across retries and concurrent workers.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Define the resources being limited

Choose the units that can be enforced reliably: model calls, input size, maximum output, tool attempts and elapsed time. Add estimated currency cost where useful, with a versioned price basis and a clear distinction from final billing.

Create a budget record when the task begins. Store its owner, limits, consumed amounts and outstanding reservations. The model may describe the work it wants to do, but it should not edit those limits directly.

Decide whether failed and denied attempts consume each limit. They often should count toward attempt limits because they still create load, even if they do not produce a charge or business effect.

## Reserve the next operation atomically

Before dispatching work, create a reservation tied to an operation identifier. Reject it if the available capacity is insufficient. Ensure the check and allocation happen under the storage system's concurrency guarantees.

```json
{
  "taskId": "task-example-72",
  "reservationId": "reservation-example-9",
  "operationId": "model-call-example-4",
  "reservedOutputTokens": 1200,
  "state": "reserved"
}
```

The example shows one resource. A real task may reserve several units, and the provider's accounting may distinguish token categories or other charges. Model those explicitly rather than assuming one universal token price.

## Settle from recorded usage

After the call completes, record actual usage and release any unused reservation according to the chosen accounting rule. Make settlement idempotent so a repeated callback cannot consume or refund capacity twice.

For a timeout, do not assume the provider incurred no usage. Mark the reservation unresolved and reconcile using available usage or operation records. Define a conservative policy for capacity while the result remains unknown.

Keep a ledger of reservations and settlements rather than only a mutable total. The ledger helps explain discrepancies and recover after interrupted updates.

## Carry the budget through recovery

A restarted worker should load the existing task budget and operation records. It should not create a fresh allowance merely because the process or conversation session changed.

Test concurrent reservations, duplicate settlements and a crash after dispatch. Confirm the total authorised work remains within the enforced limits and that uncertain reservations are visible.

Finally, provide a deterministic budget-exhausted response path. The application should be able to report saved progress without needing another expensive model call that the task can no longer afford. This makes the limit a usable product state rather than an unexplained failure.

## Sources

- [PostgreSQL: transaction isolation](https://www.postgresql.org/docs/17/transaction-iso.html)
- [AWS Builders' Library: idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)