Duty Log: Ten Minutes to Fence In Agent Spend

A coding agent repeats a failed tool call, retries the same request, and keeps buying another attempt. Each call looks reasonable; the accumulated bill does not. Before leaving an agent unattended, spend ten minutes putting a spending boundary around its execution loop. The goal is not perfect cost prediction. It is stopping work when the remaining budget cannot safely cover another step.

First two minutes: set a per-run spending envelope

Choose a small budget for one test run, such as $2, and record it alongside a unique run ID. Treat that amount as an application policy, not a promise that a provider will stop billing at exactly that figure. Alerts alone do not enforce a ceiling.

Give the run three additional limits: a maximum number of model requests, a wall-clock deadline, and a maximum number of tool executions. For an initial smoke test, you might choose eight requests, five minutes, and twelve tool executions. These are starting settings, not universal recommendations.

• Count every attempted model request, including retries and repair calls.
• Count delegated agents against the parent run's shared budget rather than giving each child a fresh allowance.
• Require explicit approval to increase a budget or resume a stopped run.

Minutes three and four: reserve before dispatch

Put a budget check immediately before every model request. Estimate the next request using the selected model's current rates, the input size, and an enforced output-token limit. Include other documented billable components where applicable. Do not rely on prices remembered from a previous deployment.

Reserve that estimated amount before dispatch, then reconcile it against reported usage afterward. If the estimate cannot fit within the remaining allowance, stop rather than sending the request. If pricing or usage is unavailable, fail closed or require a separately approved fallback.

Concurrent workers need atomic reservations. Without them, several workers can each see the same remaining dollar and all spend it. Keep reservations in shared storage with an atomic update. Leave headroom for estimation error and in-flight requests; an application-side estimate is not a provider-enforced billing cap.

Minutes five and six: break retries and repeated actions

Set a retry ceiling in both the SDK and the agent orchestrator. Otherwise, an outer retry can restart an inner sequence of retries, multiplying requests. Use bounded backoff for retryable failures, honor server guidance where provided, and stop retrying authentication errors or requests that cannot succeed unchanged.

Add a repetition detector to the tool loop. Compare normalized tool names, arguments, and relevant results. If the agent repeats the same unsuccessful action several times without new information, halt and ask for intervention. A larger context window does not fix a circular plan.

• Cap tool-result size so a large log or repository dump cannot silently inflate every subsequent request.
• Keep a bounded conversation history and deliberately summarize or discard stale material.
• Do not blindly retry side-effecting tools, because a timeout does not prove that an action failed.

Minutes seven and eight: expose spend and wire the stop

Log the run ID, model, request count, retry count, reported token usage, reserved cost, and reconciled cost. Keep estimates visibly separate from confirmed usage. Avoid storing credentials or sensitive prompts merely to explain a bill.

Provide a kill switch that blocks new dispatches across all workers. Attempt to cancel active requests where supported, but assume already accepted work may still be billed. Test the switch during an intentionally repetitive task, then verify that child agents cannot continue independently.

Final two minutes: test the actual relay path

Relay365 is a practical fit when you want pay-as-you-go access across model families through one relay desk. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. Its API base is https://api.api365relay.com; OpenAI clients append /v1. Keep your application-side limits in place rather than assuming a shared endpoint supplies them.

Create a Relay365 account when you are ready to run the bounded smoke test. Use one model, such as Gemini 2.5 Flash, and confirm its current pricing and supported request controls before dispatch. Check your local usage record against available billing information.

The shift is ready for handoff when an exhausted budget blocks the next request, repeated actions stop, and the kill switch closes every worker's dispatch gate. Leave the run unattended only after those checks pass.