Claude Code cost loops start as helpful retrying

The easiest Claude Code cost problem to miss is not the price of one run.

It is the run that almost works, tries again, changes a little more, asks for more context, calls another tool, rewrites the test, and slowly turns a narrow job into a small fog machine. Nobody set out to waste money. The agent was being helpful. That is what makes the loop awkward.

A bad retry loop burns four things at once: tokens, wall-clock time, reviewer attention, and trust in the workflow. The invoice from the model provider is only the cleanest part of the cost.

A retry is not automatically progress

I like Claude Code most when it works through a problem with evidence. It reads the failing test, makes a small change, runs the check, notices the next failure, and narrows the patch.

That is a good loop.

The expensive version looks similar from a distance. The agent keeps moving, but each attempt teaches the team less. It edits files that were not in the original scope. It swaps one failing command for another. It starts explaining why the test is flaky instead of proving the fix. It asks for broader access because the current path is not working.

At that point the question is no longer “How many tokens did this use?” The better question is: “What did the last attempt teach us that the previous attempt did not?”

If the answer is vague, stop the run.

Give the task a budget before it starts

Most teams already budget human work without calling it that. A senior engineer might say, “Spend an hour on this, then bring it back.” Claude Code needs the same kind of boundary.

For production work, I would give the run a small budget up front:

Goal: fix the failing parser test only.
Write scope: parser and parser tests.
Time box: 20 minutes.
Tool budget: local test command only.
Retry budget: two attempts after the first failure.
Stop if: the fix needs a shared contract change, a migration, or broader file access.
Evidence required: commands run, checks passed or failed, reason for each retry, rollback note.

This is not ceremony. It is a way to keep a useful assistant from becoming an expensive guesser.

A budget also protects the reviewer. If the run stayed inside a clear limit, review starts from a calmer place. If it broke the budget, the reviewer knows the main issue before reading every line of the diff.

Count reviewer attention as part of the cost

Token spend is visible. Review spend is easier to hide.

A Claude Code run that leaves a messy diff can look cheap in the API bill and expensive in the team calendar. Someone has to read the surprise files, reconstruct the prompt, check which commands actually ran, and decide whether the patch is clever or just lucky.

I saw this pattern long before coding agents, especially in financial-services systems where weak change boundaries turn small fixes into long reviews. Agents make the same failure mode faster. They do not make it harmless.

The review cost goes up when the run record is weak:

• “I fixed the issue” instead of the exact failure and command
• “updated tests” instead of naming which behavior changed
• “minor refactor” without saying why it was needed
• “all relevant checks pass” without listing skipped checks
• “low risk” without a rollback note

That kind of handoff pushes cost onto the next human. It may still ship, but it teaches the team to trust motion instead of evidence.

Require a reason for every retry

A simple retry log changes the mood of the workflow.

Attempt 1 failed: parser still accepts empty suffix. Test command: npm test -- parser.
Attempt 2 change: added explicit suffix guard in parseReference.
Attempt 2 failed: legacy import fixture expects blank suffix.
Decision: stop. This is a contract question, not a parser-only fix.

That is a healthy stop. The agent learned that the task boundary was wrong. The next move belongs to a human, not to another blind attempt.

Compare that with the common bad loop:

The implementation has been updated and tests should now pass.

That tells the reviewer almost nothing. Which test? Which assumption changed? Did the agent discover a product decision, or did it just keep patching around the problem?

Retries should earn themselves. The standard I use is blunt: another attempt is allowed only if the previous attempt produced new evidence.

Stop on drift, not only on failure

Teams often stop agents when commands fail repeatedly. That is useful, but it is not enough.

Stop when the run drifts:

• the agent wants to edit outside the named scope
• the fix depends on a product or security decision
• the agent asks for a broader MCP tool than the task justified
• the diff grows while the evidence stays thin
• the explanation gets more confident while the checks stay weak
• the rollback path becomes unclear

Drift is where cost loops become dangerous. The run may still produce green tests, but the price is a wider change than anyone agreed to review.

This is why permissions and cost controls belong together. A narrow tool boundary keeps the agent from buying its way out of ambiguity with more access. If the task needs more access, fine, but make that a human decision with a note attached.

Use a cost loop template

Here is the small template I would put into a Claude Code team workflow:

Task budget:
Allowed files:
Allowed commands/tools:
Retry limit:
Stop conditions:
Attempt log:
What changed after each attempt:
Evidence gained:
Checks still missing:
Reviewer decision needed:
Rollback:

The important line is “evidence gained.” It forces the run to explain why the next attempt is not just another spin of the wheel.

For teams adopting Claude Code, this is also a good management signal. If agent runs often hit the retry limit, the problem may not be the model. It may be unclear tasks, missing tests, vague ownership, or MCP tools that make it too easy to wander.

That is useful information. Annoying, but useful.

The goal is not cheaper agents. It is better judgment.

I do not want teams to become scared of using Claude Code. The boring truth is that some retry loops are worth it. A good agent can chew through a nasty edge case faster than a tired developer after a long week.

But production engineering needs a way to tell the difference between useful persistence and costly wandering.

Set a budget. Require retry evidence. Stop on drift. Make the human approve a wider run.

That is how Claude Code stays a tool for engineering judgment instead of a slot machine with syntax highlighting.

For the compact pre-flight version, use the Claude Code production checklist. For the fuller operating model around permissions, review packets, evals, observability, and rollback, see Claude Code: From Vibe Coding to Production.