# Review the cost of one unsuccessful task

Failed tasks expose missing accounting, uncontrolled retries and weak stopping states. Trace one from its first request through its final resolution.

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

## Pick a failure with repeated work

Use a task that encounters persistent validation failure or a downstream timeout. Find its task identifier and list every model call, tool attempt, evaluator call and reservation.

Compare the trace with the cost record. Look for calls created by fallback or repair paths that were not attached to the task. A dashboard can understate expenditure when only the main success path records usage.

Check whether the reported amount is estimated or settled. The reviewer should be able to identify the price basis and any usage still unresolved.

## Inspect the admission check

Find where the application decides that another operation may begin. Confirm the remaining capacity check and reservation are atomic under concurrent workers.

Test duplicate settlement and a crash after dispatch. The ledger should not charge twice, release twice or create a fresh allowance on restart.

Review per-call limits as well as the task budget. A single unbounded output or tool fan-out can exceed the intended resource envelope before the next task-level check runs.

## Examine the stopping behaviour

When the limit is reached, verify new work stops while accepted operations remain accounted for. The user should receive saved progress and a clear unresolved state.

Check whether an extension requires the correct authority and whether it is scoped to the same task. The agent should not change its own limit or obtain a fresh budget by renaming the task.

Inspect permanent errors separately from transient ones. Retrying missing evidence or an invalid schema indefinitely is a control defect, not a capacity problem.

## Reconcile the complete outcome

Include any human review or manual recovery needed to finish the task. Compare the final cost with the useful result, including cases that never complete.

Record missing correlations, accounting assumptions and the failure mechanism behind repeated work. A cost review is complete when the team can explain where the resources went and which control contains the same failure next time, rather than only showing that monthly spend is below an alert threshold.

## Sources

- [AWS: budgets and notification timing](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)
- [PostgreSQL: transaction isolation](https://www.postgresql.org/docs/17/transaction-iso.html)