A task starts as a small investigation. By morning, several helpers have repeated the same checks, a retry loop is still running, and the bill has grown faster than the useful result. The team had a budget reminder and no component that could refuse the next paid action.

Choose limits at the point that authorizes consumption, and test how the task stops. A prompt asking an agent to be economical is instruction. A counter that prevents another request is a control. The buying question is where the control applies and which other spending paths remain reachable.

A firsthand report of a session creating a separate metered API runner shows the path problem. The report is one user's account and gives no frequency estimate.

Use several limits for different failures#

A task can consume little model spend while taking too long, occupying scarce compute, or creating repeated external actions. Set a duration limit, an attempt limit, a concurrency limit, and a spending limit.

A repeated failure should exhaust its own retry allowance before it consumes the whole task budget. Give each helper an assigned share of the parent's allowance, since giving every child the full budget multiplies the exposure.

Limit	Failure it addresses	Question to test
Task spending	Excess paid consumption	Can the next request be refused?
Attempts per operation	Repeating the same failure	Does changing wording reset the count?
Elapsed duration	Work that never finishes	What survives when time expires?
Concurrent helpers	Fan-out beyond capacity	Is the cap shared across children?
External actions	Duplicate business effects	Is an uncertain result checked before retry?

Reserve room to stop safely#

Take a hypothetical $20 research task that launches four helpers. Assigning $5 to each leaves nothing for synthesis, recording the partial result, or checking whether a write succeeded.

Reserve room for synthesis and recovery before splitting the budget among helpers.

One plan reserves $4 for the parent and recovery and shares the remaining $16 among helpers. The implementation must account for concurrent requests and charges not yet reported, or several helpers each spend the same remaining amount.

Decide what happens at the limit. For research, the fallback is a partial brief with missing questions listed. For a transaction, it is a reconciliation step followed by a human handoff.

Test the route around the limit#

List the model credentials, paid tools, shells, browser sessions, and network paths available to the task. A gateway limit covers traffic through that gateway and does not govern an unrelated provider key read from a file.

Use a non-production test to attempt a second spending path after the first reaches its limit. Policy decides the right behavior: refuse the alternative, require explicit authorization, or use a separately approved allowance. Test the actual result, since the agent's promise to stop proves nothing.

Provider budgets, account limits, and alerts change over time. Check the account's current documented behavior and test with a small controlled amount. An alert is not a hard stop, and displayed budgets differ in enforcement.

Keep the stop decision visible#

Operators need to know whether a task completed, stopped at a limit, or failed for another reason. An unfinished task must not appear as a successful delivery because the agent wrote a confident summary before the counter expired.

Record the limit reached, work already completed, known external effects, and next safe action. Raising the ceiling repeatedly without examining why the task is stuck turns the control into a ritual.

The guide to stopping an agent covers the wider operation. Use pause instructions for the operator action and agent spend to inspect recorded model spend. Test the specific execution path before relying on any of these as a spending stop.

A good spending limit produces a controlled unfinished result and saves state, so the next operator does not pay for the same investigation again.