Shift note: keep agent loops inside the spend limit

The agent was still working when the task had stopped making progress. It kept reading the same files, retrying a failing tool, and asking the model for another plan. Each step looked plausible in isolation. Together, they turned an ordinary job into an open-ended bill.

That is the failure pattern to design around this year. Useful agents need room to recover from mistakes, but every recovery path needs a boundary. The practices worth keeping are the ones that make spending visible, limit repeated work, and leave an operator with a reliable way to stop execution.

Give every job a budget before its first request. Set limits for estimated spend, model calls, elapsed time, and tool executions. These controls cover different failure modes: a short run can make expensive requests, while a cheap request can become costly through repetition. Stop when any limit is reached, and preserve enough state for someone to inspect or resume the job.

Keep the budget at the parent-job level. If an agent launches helpers, their requests must draw from the same allowance. Otherwise, a limit that looks reasonable for one worker can multiply across parallel branches. Concurrent requests also need reservations against the remaining budget, so several workers cannot each spend the same apparent balance.

Make retries consume a separate allowance. Retrying a transient connection failure can help. Repeating an invalid request without changing its inputs usually adds cost without improving the result. Classify failures before retrying, and make the retry decision explicit.

• Set a maximum number of attempts for each operation, including retries performed inside SDKs and tool wrappers.
• Use bounded backoff for temporary failures, and respect retry guidance returned by the service.
• Stop repeated permission, authentication, and validation failures until their underlying cause changes.
• Record why each retry happened so operators can distinguish recovery from a loop.

A timeout deserves particular care. The client may stop waiting after the upstream service has already started processing. An immediate retry can duplicate work and potentially add another charge. Use idempotency features where supported, check request status where available, and avoid assuming that a missing response means no work occurred.

Measure progress independently of the agent's narration. “I will try another approach” is not evidence that the task advanced. Track concrete changes: a test failure resolved, a required artifact produced, or new information obtained. Repeated tool calls with equivalent arguments, unchanged errors, and recurring plans are useful signals to pause a run.

Bound context growth as well. Replaying a growing transcript can increase input costs even when each response stays short. Cap tool output, remove duplicate material, and summarize older state while preserving requirements and unresolved errors. Choose a model appropriate to each step; for example, evaluate Claude Haiku 4.5 for routine classification before assigning every step to Claude Opus 5.5. Compare task completion and total run cost using your own workload.

Put enforcement where every request passes. Prompt instructions to “stay under budget” are useful context, but application code must enforce the boundary. Persist usage by job, reconcile estimates with reported usage, and account for in-flight requests. Alerts should arrive early enough to intervene. A stop control should prevent new requests and attempt to cancel active work where cancellation is supported; completed work may still be billable.

Relay365 fits teams that want a pay-as-you-go relay desk across multiple model families. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. Keep job budgets, retry controls, and usage reconciliation in your orchestration layer, and check the applicable pricing before routing a workload. Create a Relay365 account when you are ready to test that setup with a bounded pilot.

Before handing the workflow to the next shift, deliberately trigger a repeated tool failure and a budget exhaustion event. Verify that execution stops, the reason is recorded, and the operator can see which requests consumed the allowance.