Spotting Runaway AI Agent Loops Early: Spend Spikes as an Alarm

An AI coding agent stuck in a loop is quiet. It does not crash. It keeps reading files, running tests, editing the same function and re-running the tests, and every iteration costs tokens. By the time you come back from lunch, a ten-minute task has turned into a long, expensive session with nothing to show for it.

The cheapest signal that something is wrong is not in the terminal output. It is the spend curve. This post covers what runaway loops look like, why they happen, and a simple way to catch them before they matter.

What a runaway loop looks like

Common patterns with Claude Code, Codex CLI, Cursor agent mode and similar tools:

• Fix-test-fail cycles. The agent edits code, a test fails, it edits again, the same test fails in a slightly different way. Ten rounds later the diff is bigger and nothing passes.
• Re-reading the world. The agent repeatedly greps or reads large files because it lost track of context after compaction.
• Tool error retries. A command fails (missing dependency, wrong path, a permission prompt) and the agent keeps trying variations.
• Scope creep. The agent "notices" related issues and starts refactoring things you never asked about.

Each of these looks like progress in the log. They look very different on a cost graph.

Why spend is a better alarm than output

Normal work is bursty: a big read at the start, some edits, a test run, done. Spend rises and then flattens. A loop has a steady slope that does not flatten, because the agent keeps re-sending a large context every turn. Context size grows as the session goes on, so each loop iteration tends to cost more than the last.

Watching the terminal, you see plausible messages. Watching spend, you see a line that keeps climbing at the same rate for twenty minutes. That second view is easier to judge at a glance.

Set your own thresholds

There is no universal number. Calibrate from your own history:

1. Look at a week of normal sessions. Note what a typical small task costs and what a big one costs.
2. Set a soft alarm at around 2x your typical big task. That is "go look."
3. Set a hard stop at an amount you would be annoyed to lose on a single session.

For a solo developer this might be a few dollars soft and somewhat more hard. For a team running agents in CI it should be enforced in code.

Practical guardrails

Cap turns or time. Many agent tools let you limit iterations or run headless with a max-turns setting. Use it for unattended runs.

Make the task smaller. Loops are far more common on vague tasks. "Make the tests pass" invites thrashing. "Fix the null check in parseConfig so config.test.ts passes" does not.

Fix the environment first. Many retry loops come from a broken setup: missing env vars, wrong Node version, a flaky test. If the agent fails a command twice, the problem is usually not the agent.

Commit checkpoints. Ask the agent to commit after each passing step, or use git worktrees. If a loop starts, you reset to the last good state instead of untangling a giant diff.

Clear context deliberately. Long sessions accumulate context. Starting fresh with a short summary is often cheaper and smarter than letting a session drag on.

A simple routine

• Start the task and note current spend.
• Glance at spend every 10–15 minutes, or when you get a notification.
• If the slope has not flattened and the agent has not committed anything useful, interrupt.
• Ask it to summarize what it tried and what is blocking. Often the summary reveals the real problem in one line.
• Restart with a narrower prompt, or fix the blocker yourself.

The key habit is having the number visible without opening a dashboard. If you have to log into a billing page to check, you will not check.

I use TokenBar, a Mac menu bar app that tracks Claude Code, Codex, Cursor and related AI usage so today's burn is always one glance away. It is $15 lifetime and built on the MIT-licensed CodexBar project. Disclosure: I built TokenBar (Aura Technologies). It will not make decisions for you, but it puts the number in view while you still have time to act on it.

What to do after a loop

Treat it as a cheap postmortem:

• What was the prompt? Was it vague?
• What did the agent get stuck on? Environment, test flakiness, missing context?
• Could a rule prevent it? Add a line to CLAUDE.md or AGENTS.md, such as "If a command fails twice with the same error, stop and ask."

That last rule alone prevents a surprising number of loops. Agents follow explicit stop conditions well; they just are not given many.

Bottom line

Runaway loops are not a reason to stop using agents. They are a reason to watch the one metric that captures every failure mode at once. Output can look fine while the agent spins. Spend does not lie about how much work is being repeated.