Free Tokens Don't Justify Blind Retries: Stop-Loss Rules for AI Coding Agents

When an AI coding agent can retry for free, many developers assume retries have no cost. But this article makes a case worth taking seriously: what's free is the bill, not the evidence. A retry is still a decision you make yourself, and cheap tokens don't erase a recurring error.

The Core Claim: Retries Require New Evidence, Not Cheap Credits

The argument is straightforward — don't retry an agent just because the call is free. Free credits change your spending, not the evidence in front of you. Evidence is the only legitimate reason a second call should exist.

This argument isn't grounded in any model benchmark, and it doesn't rank vendors or hosting services. Instead, it starts from failure classes — the idea that whether to retry should depend on what kind of error you're facing, not how many credits you have left. The author even encourages readers to tally their own logs before deciding whether to agree.

Failure classes are an engineering practice of bucketing errors by root cause, originating from fault management frameworks in telecommunications and distributed systems. The core insight is that the same surface symptom (e.g., "task failed") can stem from radically different root causes, each requiring a completely different fix path. Handling errors by category — rather than improvising case by case — transforms debugging from "trial and error" into "following a map." In the context of AI coding agents, failure classification matters because it requires the operator to make an explicit assertion about the nature of the current failure before initiating the next network call. That assertion is itself a metacognitive check, preventing anxiety-driven retries from substituting for actual thinking.

Why "Just Retry" Is False Comfort

Recent technical discourse keeps circling around retry and swap. The article advises treating those headlines as unreliable signals, not facts.

The deeper logic is this: better reasoning cannot unlock a local lock. Missing files and wrong paths remain on your own machine. A remote model cannot conjure up a file you never uploaded. No matter how capable the model, it cannot save you from a problem that is fundamentally a local environment issue.

Pay-per-token pricing used to do something for you — it forced a pause before spending again, long enough to actually read the error message. Free credits remove that pause. That pause was doing classification work for you: it forced you to name the failure in clear terms. Without naming it, you end up resending the same prompt over and over.

Excuses That Don't Justify a Call

The author lists several common but unconvincing reasons to retry, suggesting you write the excuse down — then discard the call:

• The last response looked "roughly right";
• The log is too long, so summarizing again seems reasonable;
• Credits are plentiful, wasting one doesn't matter.

What these excuses have in common: not one of them points to a new fact. A retry with no new facts is noise — and when metering goes to zero, the cost of generating noise drops, which is precisely the danger.

Classify the Failure Before Going Online

The article provides a practical failure classification table. The recommendation is to read the failure locally, assign it to a category, and only then decide whether you've "earned" that network call:

Class	What You See	Retry?	Reason
Local lock	Dependency or file is locked	No	Another call won't release it
Missing input	Empty diff or file doesn't exist	No	Fix the fixture first, then call
Tool mismatch	Command not in PATH	No	Fix the host before rewriting
Flaky check	Passes on local re-run	Once	Log the flake and cap retries
Wrong file edited	Edit falls outside task scope	No	Narrow the path list first
New compiler fact	New error after a real edit	Yes	The error text is new evidence

The author emphasizes that this table is a starting proposal, not a record from production traffic — it needs to be modified line by line against your own repository. The only class that genuinely warrants a retry is the last one: a brand-new error text, meaning the evidence has actually changed.

Harden the Rules with a Referee Script

The article provides a local "retry referee" example. The core is a classify function that returns one of three verdicts — stop, once, or allow — based on failure class, whether evidence has changed, and the number of attempts made.

The logic is clean: local classes (lock, missing input, tool mismatch, wrong file edited) always stop; flaky classes allow one local re-run; only new_compiler_fact with genuinely changed evidence and attempts under the limit gets allow. For unknown classes, the referee must stop — unknown is not a reason to invent a new class, but a signal to manually add a classification row and re-verify.

Paired with the referee is a thin shell gate script, retry_gate.sh, which reads the class you've already written down and rejects the network call outright (exit code 2) when the verdict is stop. The author repeatedly notes: these scripts are sketches, not finished products. Until they actually run against your codebase, they should be marked "unexecuted." Printing "permitted" is not the same as passing an integration test.

Only Spend Free Credits After Getting the Green Light

The article openly discloses that it is part of the product outreach for MonkeyCode, an open-source coding agent project. The outreach brief mentions free model access, free server options, and roughly ten million tokens of free quota. But the author repeatedly cautions readers: treat the project's current documentation as authoritative — don't plan a quarter's usage around a number copied from this article. Free access can change at any time; don't treat "free" as a durable, dependable feature.

The author offers a pragmatic sequence:

1. Classify the failure on your own machine first;
2. Refuse the call when the class is a local problem;
3. Only send a bounded prompt when the evidence has changed;
4. Re-run the same local checks after applying a patch;
5. Stop after two remote attempts, even if tokens remain.

Two remote attempts is a hard cap. Remaining tokens are not a reason to make a third call.

When the Referee Approves, Keep the Prompt Tight

Even when the referee allows a call, the prompt should be trimmed: send only the new error, the relevant paths, and the recent diff — not the entire repository just because the call is free. The prompt template in the article includes the failure class, attempt count, changed evidence, involved paths, new compiler text, and explicit constraints (only edit the involved paths, don't add retry loops, stop after one patch).

One sentence captures the key insight: abundance is not context. Context means the one fact that changed since last time. If you can't point to a single new line, you shouldn't send.

Context window is the maximum amount of text a large language model can process in a single call, typically measured in tokens. A token is the smallest unit after tokenization — roughly 1–2 tokens per Chinese character, roughly 1–1.5 tokens per English word. A larger context window lets you include more code, logs, and instructions in one call, but that doesn't mean more is better. Model attention dilutes over long contexts; critical information can drown in redundant content, actually degrading output quality. When the article says "abundance is not context," it points exactly at this: free credits or a large token pool tempt you to send everything, but an effective prompt is surgical — it contains only the one new fact that changed since the last call.

Scope and Who Should Skip This Workflow

The author doesn't dodge the limitations: this workflow doesn't measure model quality, doesn't compare hosting services, prices, or latency, and doesn't prove the free tier will last. The scripts only know the class you pass in — a wrong classification produces a "confidently wrong stop." You still have to read the logs yourself. Network blips and partial writes require you to add your own classification rows, and you should never paste secrets or customer logs into the examples.

Who should skip this workflow:

• When the edit is a typo you can see at a glance — human eyes are enough, no referee needed;
• If you don't plan to maintain the classification table — an abandoned table becomes theater within a week;
• If company policy prohibits third-party agent servers — free options are still remote services; read the terms before sending source code;
• If you need auditable data for decisions — this article provides rules, not research, and should not be cited as a performance finding.

The article closes with a simple self-check: label your last five failures using the table above, run the referee against those labels, and only call the free model when the verdict is allow. The point is unambiguous — stop-loss rules matter most precisely when retrying feels free. A free server cannot override your workspace. A large token pool cannot override a missing file. Yet another rewrite cannot override a held lock.

Background: The Referee Pattern

The referee pattern used here is essentially a decision-table-driven gatekeeper design, common in scenarios where business rules need to be decoupled from execution logic. The classify function acts as a rules engine: inputs are a structured description of the failure (class, whether evidence changed, attempts so far); outputs are a verdict value in a finite state machine (stop / once / allow). Isolating the judgment logic into a standalone function rather than inlining it in a pipeline script has two engineering benefits: first, the rules can be tested and version-controlled independently; second, the default branch of "unknown class always stops" prevents the system from silently approving all calls once the classification table goes stale. retry_gate.sh is the execution boundary for this rules engine — its exit code 2 can be captured by a CI pipeline or Makefile, hardcoding the "allow network call" decision into the build process rather than relying on the operator's manual judgment each time.