# Stop an over-budget run with a recoverable status

Prevent new work, account for operations already accepted and preserve the useful result. Cancelling the conversation alone may leave costs and effects running in the background.

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

## Identify the task and outstanding work

Load the task budget, reservation ledger and current operation states. Determine whether the limit was reached through legitimate workload, repeated failure or an accounting defect.

Check model calls, queued tools and external jobs that are still active. A stopped web request does not necessarily cancel those operations. The operator needs to know which work can still incur usage or change business state.

Use the supported task-stop mechanism so new reservations are denied consistently across workers. Do not rely on removing the next model prompt while background jobs remain free to dispatch.

## Preserve and reconcile in-flight operations

For completed work, save the result and settle recorded usage. For uncertain calls, retain the reservation or apply the documented reconciliation policy. Do not assume a timeout means zero cost or no effect.

If an external mutation may have succeeded, resolve it through its operation identifier before any restart. Cost containment must not create duplicate business actions by losing execution history.

Keep accounting corrections separate from task authority. Releasing an unused reservation should not automatically authorise a previously denied operation.

## Decide whether continuation is justified

Inspect the repeated failure mechanism before extending the allowance. Missing evidence, invalid credentials or an unsupported output contract will not improve simply because more budget is available.

If the remaining work is legitimate, have an authorised actor approve the extension through the normal control. Record the reason, revised limit and scope. The model should not grant itself additional capacity.

Where continuation is not useful, provide a manual or limited-result path that includes completed work and the unresolved issue. Avoid making the user start from nothing when the application has already produced a valid partial result.

## Close the run and explain the spend

Verify no unowned reservations or queued operations remain. Record final usage with any unresolved billing estimate clearly labelled.

Tell the user what completed and what stopped in task terms. Internal token counts may be useful in diagnostics, but the product should explain the practical limit and next step.

Add the failure mechanism to monitoring or tests. An over-budget incident should lead to a clearer task contract, tighter loop control or better accounting rather than a permanent increase in every user's allowance.

## Sources

- [AWS Builders' Library: idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
- [AWS: budgets and notification timing](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)