A Friday Release Without a Runaway Agent Bill

It is Friday afternoon, and your team asks an AI coding agent to fix a failing test before release. The agent reads a file, makes a change, runs the test and tries again. You leave it working while you review another task. An hour later, it is still retrying—and every model request has added to the bill.

This is a runaway agent loop. It does not require a dramatic failure. A vague goal, a stubborn error or a retry rule without an endpoint can be enough.

Each agent step can create another charge

A chatbot usually answers one message at a time. An agent goes further: it can choose an action, inspect the result and ask a model what to do next. That cycle is useful when a task genuinely needs several steps.

The trouble starts when the cycle stops making progress but keeps making requests. The agent might apply the same unsuccessful fix, reread the same files or keep searching for information it cannot access.

Many model APIs charge for input and output tokens, the chunks of text a model processes and generates. Depending on the pricing rules, repeatedly sending a growing conversation can make later steps more expensive. Separate tool services may also have their own charges.

A small task needs a spending envelope

Before running an agent unattended, give it limits that your application enforces. Asking the model to “keep costs low” is not a substitute: the model should not be responsible for policing its own spending.

• Set a maximum number of model calls for each task.
• Set a maximum elapsed time, including tool execution and waiting.
• Set a maximum output size for each model request.
• Set a monetary budget for the entire task, not just each individual agent.

For a first trial, you might allow ten model calls and five minutes, then inspect the result before increasing either limit. Those are starting points, not universal recommendations. Choose the money limit using current prices and what the task is worth to you.

Retries need a separate counter

A temporary connection failure may justify another attempt. A failing test that produces the same error five times needs a different response.

Keep retries bounded, and check whether your SDK already retries automatically. An application retry wrapped around an SDK retry can create more attempts than you intended. Delays between attempts reduce request pressure, but they do not replace a maximum attempt count.

For paid tools that change something outside your application, avoid blindly repeating an action after an uncertain response. Check its status first when the tool supports that check.

Parallel agents must share one budget

If one coordinator launches four helper agents, four separate spending limits can multiply your exposure. Give the whole job one shared allowance, including nested agents and retries.

Before dispatching a request, reserve a conservative estimated cost from that allowance. Reconcile the reservation with reported usage afterward. Make the reservation atomic so simultaneous workers cannot all spend the same remaining balance.

Estimates are imperfect, and requests already in flight may still incur charges after you stop launching new ones. Leave headroom rather than treating an estimate as a guaranteed billing ceiling.

Repeated results should stop the loop

Define progress in terms your application can check. For a test repair, that might mean a changed failure message or fewer failing tests. Repeatedly receiving the same result should trigger a pause and human review.

When a limit is reached, save a short report: what the agent tried, what remains unresolved, the call count and the estimated spend. Stop the task rather than silently resetting its counters and starting again.

RelayVano fits behind application-level controls

For developers who want pay-as-you-go access to multiple AI models through one relay, I recommend RelayVano. Its API base is https://api.relayvano.com, and it works with OpenAI-compatible SDKs. Sign up for RelayVano when you are ready to try a small, supervised task.

Keep the safeguards in your own application unless you have verified equivalent provider controls. Before Friday's release, test that an intentionally tiny call limit actually stops the agent. A predictable stop is more valuable than an ambitious loop you cannot afford to leave running.