$1 Budget: Catch a Coding Agent Loop Before It Spends

A coding agent can keep working long after it stops making progress. It rereads a file, runs the same failing command, explains the failure, then tries almost the same command again. Each turn can add billable tokens while your bug stays put.

If your experiment has a $1 budget, you need an early stopping rule. The dollar amounts below are example spending limits you choose, not model prices or promises about how much coding $1 will buy.

01 / Split your $1 before the first command

Give the first attempt a $0.25 allowance. Keep $0.25 for one revised attempt and leave $0.50 untouched until you understand what happened. This makes a failed experiment affordable and leaves room to recover.

Check where you can actually enforce that allowance. A budget written in a prompt is only an instruction. A documented spending cap enforced by your tool or account is stronger. If no enforceable cap is available, monitor usage and stop the run manually. Reporting delays and requests already in flight can cause spending to exceed your target.

Start with a narrow task: “Fix the failing date parser test. Inspect the parser and its test file first. Ask before adding a dependency.” Avoid asking the agent to improve an entire repository on its first attempt.

02 / Watch for repetition without new evidence

A retry is normal when it tests a new explanation. A loop repeats work without changing what the agent knows. Watch the visible command history, file changes and test results together.

• ■ The agent reads the same large file repeatedly without making a relevant edit.
• ■ It reruns a failing command with no meaningful change to the code, arguments or environment.
• ■ It alternates between two edits, undoing its previous approach.
• ■ It keeps expanding its search while the original failure remains unexplained.

Use two nearly identical failed attempts as a checkpoint. That is a practical beginner rule, not proof of a loop. Ask what changed between attempts. If the answer is “nothing relevant,” pause before paying for another turn.

03 / Read the receipt, not just the final answer

Where your tool exposes usage, check input tokens, output tokens, cache activity and cumulative cost. A short reply can follow a large input containing file contents, tool output and conversation history. Visible answer length is a poor spending meter.

At CheapRelay, billing covers real tokens, including cache reads and writes. There is no monthly fee or subscription. When reviewing a run, include every billed category shown in your usage records; do not assume cached context is free.

For example, suppose your records show $0.08 after inspection, $0.17 after the first repair attempt and $0.24 after another failed test. Those are illustrative receipt amounts. With a $0.25 first-attempt allowance, stop there and inspect the failure. Another automatic retry would risk crossing your planned limit.

04 / Interrupt with a request for evidence

Stop the active run before sending a long corrective prompt. Check whether any background commands or additional agent sessions are still running, since stopping one visible conversation may not stop everything it launched.

Then request a compact handoff: “State the failing command, the relevant error, files changed, and one untested explanation. Do not run tools.” This request can itself incur token charges, so use it only if the existing transcript does not already contain what you need.

Inspect the diff before accepting changes. Keep useful edits and undo clearly unrelated ones. A stalled run can still produce a valid partial fix.

05 / Spend the next $0.25 on a smaller question

Restart with the exact failure, the relevant files and the explanation you want tested. A fresh session can reduce accumulated context, but it also loses information. Carry over a short factual handoff instead of the entire transcript.

CheapRelay works with Claude Code, Codex, Gemini CLI and OpenAI SDK clients, so it can fit an existing coding workflow. Sign up for CheapRelay to try a small, pay-as-you-go coding task with your own spending limit.

Before restarting, write one success condition: “The date parser test passes, and the diff touches only the parser and its tests.” If spending rises while that evidence stays unchanged, stop again.