Shift Log: Agent Loops Need a Spending Stop

The agent was supposed to repair one failing test. Instead, it kept revising the same patch, rereading the repository, and retrying a tool that never recovered. Each action looked reasonable in isolation. Together, they created an open-ended bill.

The duty-desk question is not whether agents sometimes loop. It is which controls actually stop billable work when they do. Here is the head-to-head assessment, with a verdict for each operating decision.

Budget alerts notify; enforced ceilings interrupt

An alert can tell an engineer that spending has crossed a threshold. It cannot make that engineer available, and it does not necessarily stop requests already queued or running. Alerts are useful for visibility, but they are not a spending boundary.

An enforced ceiling belongs in the request path. Before each model call, the application checks whether the run has enough remaining budget. If it cannot reserve a conservative allowance for that call, it declines to dispatch it.

Reservations must account for concurrent workers. Otherwise, several workers can each see the same remaining balance and collectively overspend it. Reconcile reservations against reported usage afterward, while recognizing that reporting and billing may not be instantaneous.

Verdict: Use enforced ceilings as the primary control and alerts as the escalation channel. Treat estimates as estimates, not an exact billing guarantee.

Step limits count activity; cost budgets price it

A maximum of twenty agent steps sounds bounded. But a step that sends a large repository excerpt is not equivalent to a short classification request. Model choice, context size, output length, and separately billed tools can change the cost substantially.

A cost budget reflects those differences, provided the application uses current pricing and accounts for applicable charges. A step limit still matters because it catches repetitive behavior even when each individual call is inexpensive.

• Set a maximum number of model calls and tool actions per run.
• Limit input growth and requested output tokens before dispatch.
• Apply a run-level spending allowance and a wall-clock deadline.
• Require approval before expanding any exhausted allowance.

Verdict: Combine step limits with cost budgets. Neither is a substitute for the other, and switching to a cheaper model does not repair a loop.

Automatic retries recover faults; shared retry budgets prevent storms

A retry can recover from a temporary failure. Unlimited retries can turn an outage into a spending incident, especially when retries exist in the SDK, orchestration layer, and tool adapter simultaneously.

Use bounded retries with backoff and jitter for eligible transient failures. Do not retry authentication errors, invalid requests, or a deterministic tool failure without changing the underlying condition. Count retries against the same run budget as ordinary calls.

Also cap concurrency and propagate cancellation to child workers. A parent agent that stops while its delegated tasks continue running has not actually stopped the incident.

Verdict: Prefer one coordinated retry policy over stacked defaults. Record each retry reason so repeated failure becomes visible before another attempt is authorized.

Direct accounts separate providers; a relay simplifies routing

Direct provider accounts can suit teams that want separate billing relationships and provider-specific controls. The operational tradeoff is maintaining multiple integrations, credentials, and spending views.

Relay365 fits teams that want pay-as-you-go access to many model families through a shared relay. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. The API base is https://api.api365relay.com; OpenAI clients add /v1.

For a workload evaluating Claude Haiku 4.5 alongside Gemini 2.5 Flash, that routing convenience can reduce integration work. It does not establish which model is cheapest for the task, nor should a shared endpoint be assumed to provide hard run-level caps.

Verdict: Choose routing for operational fit, then enforce spending policy independently. If that shared access matches your workflow, create a Relay365 account and begin with a tightly bounded test run.

Close the shift with a tested stop condition

Before unattended execution, simulate a repeating tool failure, exhausted budget, and concurrent child tasks. Verify that new work stops, pending work is cancelled where possible, and the ledger records outstanding reservations. The final verdict is simple: a runaway loop should encounter an enforced boundary, not merely an unread notification.