When Coding Agents Retry the Same Fix: What Repair History Changes

When a coding agent keeps re-attempting the same failing patch, the cheapest fix is usually not a stronger model. It is context management, the pattern behind HAFixAgent, a history-aware repair agent described in a recent arXiv preprint: persist a compact record of what was already tried, inject it into the agent’s context before the retry loop starts, and cap the loop with explicit step, cost, or timeout guards. One scope note up front: the paper’s history is repository snapshots and blame data for the buggy code, not a log of the agent’s own attempts, so mapping the pattern onto failed patches, error traces and ruled-out approaches is this article’s inference, argued below. The pattern lines up with independent measurements showing that harness and context changes alone can swing a model’s results by double digits.

The practical consequence is a shift in where you spend money. If retry loops fail because each attempt starts context-blind rather than because the model is weak, then a model upgrade pays for capability you may not need while leaving the actual defect in place. The tradeoff is real, though: added context is not free. Measured overheads from a separate study put the price of extra agent-side context at roughly 13% more tokens and 38% more wall-clock time (delegation-contracts study), and one tooling experiment found that richer context can cost more while performing worse. This article maps the mechanism, prices it, and ends with a checklist for diagnosing a retry loop that will not converge.

The stuck retry loop: why each attempt starts blind

The failure mode is familiar to anyone who has watched an agent harness grind on a bug. Attempt one produces a plausible patch. The test suite rejects it. Attempt two tweaks the same patch in the same wrong direction, because the agent no longer has access to what attempt one actually did or why it failed. By attempt five the session has burned an hour of tokens circling one idea, and the engineer supervising it has learned nothing except that the loop does not converge.

Two things are usually missing. First, no durable artifact carries forward between attempts: the diff that failed, the compiler or test output that rejected it, and a note on what hypothesis the patch embodied. Second, no hard termination condition distinguishes “making progress” from “rephrasing the same mistake.” A handbook on Claude Code operations frames this as a harness-level problem rather than a model-level one: the tool’s “capability envelope now exceeds what one practitioner can supervise by attention alone, and its failure modes are systemic rather than local: an unreviewed hook, an over-scoped connector, a stale completion condition, an autonomous routine inheriting every credential on an account.” A stale completion condition is exactly what lets a retry loop spin: the agent believes it is done, or believes it should continue, on grounds nobody re-examined.

What HAFixAgent persists between attempts

HAFixAgent is a program-repair agent built around the observation that history is underused context. Its authors describe it as treating “repository history from previous snapshots as an important source of context that augments the current code snapshot,” operating “within a compact, guarded loop over a small set of standard bash tools (e.g., grep, sed, find)” so that gains can be attributed to the history rather than to sophisticated tool exploration (HAFixAgent preprint).

The mechanism has three parts worth separating:

Preparation, not retrieval. A History Extractor module assembles the relevant history before the agent runs. The paper is explicit that “the historical context is not an interactive tool, but is instead modularized and prepared by the History Extractor and injected directly into the agent’s context before the execution loop begins.” The agent never has to decide to go looking for history; it arrives already summarized.

A simple in-loop toolset. Because history is injected up front, the loop’s tools stay limited to read, edit, and test operations over bash primitives. “In practice, the loop alternates between reading around fault locations, applying edits, compiling, and testing until all tests pass.”

Guards that end the loop. “Termination occurs when the agent emits a completion signal after passing tests, or when a guard (step, cost, or timeout) is reached.” The retry budget is a first-class parameter, not an afterthought.

On the same underlying LLM, the authors report that HAFixAgent beats RepairAgent by 56.6% and BIRCH-feedback by 47.1% (preprint results). Both figures are author-reported from a single preprint with no independent replication in the sources reviewed here, and the paper’s own summary is careful about what they measure: “On the same LLM, HAFixAgent beats RepairAgent (+56.6%) and BIRCH-feedback (+47.1%), but so does non-history, so this gap measures the agent framework, not history. History’s effect is isolated by the history-vs-non-history comparison.” On that isolated comparison, the best history heuristic’s improvement over non-history “ranges from modest on the strongest model (+4.4% on Defects4J and +1.1% on BugsInPy) to large on the weaker models (up to +64.3%).” On the strongest model, no individual history configuration significantly beats non-history; the significant result is the hybrid, the union of the three history heuristics (McNemar’s test, p<0.001).

There is also a scope limit that matters for practitioners. HAFixAgent’s “history” is repository history: prior snapshots and blame information for the buggy code, evaluated on Defects4J (854 Java bugs) and BugsInPy (501 Python bugs) (preprint). It is not the agent’s own log of failed attempts. Mapping the design onto attempt-level artifacts (this patch failed, this trace rejected it, this approach was already tried) follows the same mechanism, prepared context injected before a guarded loop, but it is an inference from the design, not a result the paper measures. The availability of even the paper’s kind of history varies sharply by ecosystem: the authors report 71.1% of Defects4J bugs and 87.4% of BugsInPy bugs as blameable (preprint), and the history profiles differ enough between benchmarks (99.5% of blameable Defects4J bugs map to a single blame commit versus 58.4% in BugsInPy, per the same paper) that they caution “history-aware techniques may need adaptation per ecosystem.”

Inject before the loop, not during it

The pre-loop injection point is the piece most likely to be skipped in a homegrown harness, though nothing in the reviewed sources ranks it above toolset choice or termination guards. The paper presents it as a design rationale rather than a proven ordering: a “key design choice” that “decouples history retrieval from agent actions” and lets the toolset stay simple. The intuitive alternative is to give the agent a tool, a “search my history” or “query past attempts” function, and let it pull context when it wants. The counter-evidence against richer in-loop context is direct.

A measurement study of language-server tooling for coding agents tested exactly this question on single-file edits drawn from six real bugfix commits: “Grep-only leads (pass@1 0.83); adding (C, 0.58) or forcing (D, 0.75) the LSP does not help, and the LSP again carries a token premium.” Read that again: giving the agent access to a language server, a genuinely richer source of code intelligence, dropped pass@1 from 0.83 to 0.58 while costing more tokens. In the study’s localization experiments with Opus 4.8, the LSP-only arm was also about 6% more expensive in tokens-to-success than grep-only (localization results). Six commits is a small sample, so treat the exact numbers as preliminary, but the direction is consistent: context the agent must actively fetch mid-loop costs money and can actively hurt.

The plausible mechanism is attention and distraction. Every interactive retrieval tool adds decision points where the agent can go wrong, and every retrieved chunk competes for the context window. Pre-loop injection converts “should I look this up?” into “here is what you need to know,” which is a much easier problem for the model. This also explains why HAFixAgent’s authors kept the loop tools to grep, sed, and find: the design deliberately removes ambiguity so the history, not the tooling, does the work.

The bill for extra context

Persisting and re-feeding history is not free, and the honest budget line comes from an independent source. A study measuring reviewability in coding-agent work added structured contracts to agent runs and measured the overhead precisely: agent tokens rose 13%, wall-clock time rose 38%, and tool invocations rose 23%, all p ≤ 0.001 (measured costs). In the study’s words, “That overhead bought evidence, not correctness.” The token increase was from 20,087 to 22,690 per run (same study).

Two cautions apply before you extrapolate. First, those numbers come from contracts, not from repair history specifically, so treat the 13% (contracts study) as the order of magnitude for “adding a prepared context artifact to each run,” not as a quote for your exact design. Second, the study’s own framing is a warning: overhead can buy evidence without buying correctness. If your injected history is bloated or stale, you pay the overhead and get nothing back.

That is the argument for keeping the persisted record compact and modular: failed patches as diffs, not full transcripts; error traces trimmed to the failing assertion or compiler error; a one-line note per approach ruled out. Volume matters because real repair campaigns generate failure signal faster than any context window can hold. One agent-driven compiler testing campaign (Claude Code Opus 4.8 on a MacBook M4 Pro) processed 8,200 programs in a 30-minute detect phase, with 82% (6,760) triggering a defect (detect-phase results). Nobody is feeding that many defect reports into a prompt. The job of the history module is to summarize and select, which is exactly what HAFixAgent’s History Extractor does for repository snapshots.

What should survive the summarization? An empirical study of how LLMs read bug reports analyzed 319 real-world Python and Java bugs from SWE-bench Verified and Multi-SWE-bench, comparing how model attention distributes across bug-report sections and how those patterns differ between successful and unsuccessful repairs. Its findings give the filter directly: “successful repairs are characterized by diffused attention across multiple diagnostic components such as bug descriptions, stacktraces, and test cases, while failures often exhibit over-localized attention toward metadata such as version information.” For a repair-history record, that argues for persisting the diagnostic components (description, failing assertion, test output) and cutting the metadata boilerplate the model will only skim.

Harness or model: where the next dollar goes

The strongest independent support for the “fix the context first” recommendation comes from harness-sensitivity measurements cited in a paper on Claude Code’s design space: “holding the model fixed and changing only the surrounding harness shifts a single model’s score on long-horizon tasks by up to 18 points, with Claude Code and OpenClaw among the harnesses tested (Ding et al., 2026).” The same paper cites results (Compagna, 2026) that harness choice alone moves a top model’s functional and security pass rates by ten points or more.

The design-space paper’s own framing is the supported way to read this: “frontier models converge in practical capability for coding tasks: the quality of the surrounding operational harness becomes the principal differentiator,” and investing in deterministic infrastructure such as context management “may yield greater reliability gains than adding planning scaffolding around increasingly capable models” (design-space paper). That does not prove repair history is the right harness change for your loop, only that the harness is where the differentiation is happening. A stronger model inherits the same context-blind retry loop and will often just fail more fluently.

Here is how the decision axes line up against the evidence:

A checklist for a retry loop that will not converge

When you find an agent stuck re-attempting one fix, diagnose in this order:

1. Is anything persisted between attempts? If attempt N cannot see attempt N−1’s diff and rejection output, that is the bug in your harness. Add the artifact first.
2. Is the history injected or interactive? A retrieval tool the agent must choose to call is a liability. Move the prepared record into the initial context.
3. Do the guards exist and fire? Verify the step cap, cost cap, and timeout actually terminate the loop. Per the handbook’s warning about stale completion conditions, test this deliberately rather than assuming the defaults work.
4. Is the record compact? Full transcripts and untrimmed stack traces pay the added-context premium (order of magnitude: roughly 13% more tokens in the contracts study, measured for contracts rather than transcripts) without buying attention. Diff, failing assertion, one-line hypothesis.
5. Is the toolset minimal? If the agent has rich in-loop tooling (language servers, semantic search), compare against a grep-only baseline on a handful of real bugs from your own repo before assuming the tooling helps.
6. Is the failure systemic? If the loop fails the same way across many bugs, suspect the harness (hooks, completion conditions, scoping) rather than the model.
7. Only then consider the model. If history is injected, guards fire, tools are minimal, and the loop still fails, you have a clean baseline against which a model upgrade is a fair test.

Verdict and limits

Persist a compact repair history, failed patches, error traces, approaches already tried, and inject it into context before the retry loop starts, behind explicit step, cost, and timeout guards and a simple toolset. Try this before paying for a stronger model, and budget roughly 13% more tokens for the added context (contracts study).

The limits deserve equal weight. Every performance claim for HAFixAgent itself (+56.6%, +47.1%) is author-reported from a single preprint, its own text notes non-history methods also improved, and nothing in the reviewed sources replicates it independently. Its history is repository snapshots and blame data on curated Java and Python benchmarks, not an agent’s attempt log, so the mapping to your harness is an inference from a plausible mechanism, not a measured result. The cost figures come from a contracts study and an LSP study, adjacent to but not identical to feeding repair history. And the LSP result cuts both ways as a warning: added context can cost more and perform worse, so measure your own retry loop before and after the change rather than trusting the pattern to transfer.

Frequently Asked Questions

How much does adding structured context to agent runs cost in tokens and time?

agent tokens rose 13%, wall-clock time rose 38%, and tool invocations rose 23%, all p ≤ 0.001 (measured costs). In the study’s words, “That overhead bought evidence, not correctness.” The token increase was from 20,087 to 22,690 per run (same study).