Physics of Coding Agents: Part 1, Fit, Not Format at the Edit Interface

1. Introduction

On large-file refactors, GPT-5.6-luna’s first edit is accepted in 99% of runs when it points at the lines to change and in 58% when it quotes them, yet both ways solve 94.4% of the tasks.1 This paper explains why such a gap stays hidden, and what it costs. A coding agent changes code by sending edit calls to its harness, which checks each call and applies it to the file. Suppose the agent must change lines 119–125 of a long file. It can quote those seven lines back to its harness, which replaces the text it finds, or it can point at them by number, and the harness replaces those lines without looking at them. The quotation costs output and is rejected if it does not match the file. The pointer is cheap, but a range that is off by one line changes the wrong code without any error. Existing harnesses take different sides. Claude Code’s edit tool and Anthropic’s text-editor tool take an exact quotation of the old text [1,2]. OpenAI’s apply_patch locates changes by context lines and explicitly avoids line numbers [3,4], while SWE-agent’s original interface replaced a numbered line range [5]. The choice fixes how much of the target the model must restate and what the harness can check before it writes (Figure 1). It is part of the agent’s execution mechanism, not a serialization detail.

The choice is not neutral for the model either. People refer to code both ways (a reviewer quotes the offending line or cites it by number), and so does the internet text that models are pretrained on (Section 2.1). Post-training adds a second source, since developers train models on trajectories generated in their own harnesses. OpenAI publishes a diff format “on which the model has been extensively trained” [3], Anthropic “publishes the schema and trains Claude on it” [6], and a harness vendor reports that an unfamiliar format “costs extra reasoning tokens and produces more mistakes” [7]. According to a recent survey, an agent is a policy coupled at run time to a harness, $\mathrm{Agent}={\pi }_{\theta }\oplus \mathcal{H}$ [8]. Developers’ own reports indicate that the formats in the harnesses and text a model is trained on can become part of how the model acts [9,10]. From both sources a model becomes fluent in two ways of addressing code, pointing at it and quoting it, and forms a habit, the form it reaches for when it may choose. A model may be more practiced in one of these ways of referring than in the other. Asked to refer in a way it has rarely practiced, it pays as a person would, by restating, retrying and correcting itself, and the harness bills every attempt. Natural text shapes fluency that every model shares, whereas post-training on one harness adds fluency in that harness’s format alone. The edit interface is where fluency and habit meet the harness, and we ask one question:

When a model edits code through a harness, do the cost of an edit and whether a wrong one is caught depend on the model, the interface, or the pair?

• Our answer is fit, not format: no edit format is best on its own. The format sets the price of each attempt and whether a wrong one is caught; how fluently the model writes it sets how many attempts it needs. Fit covers both, and the cost of a misfit hides in the agent loop.

Task success, the usual yardstick, misses most of this. An agent keeps editing until the model judges the task done, so a rejected edit usually becomes a retry rather than a failure, and a silently wrong one may never be noticed. Instead, the differences between interfaces show up in the first action, in the cost of retries, and in which errors are seen at all.

The evidence comes from a fixed harness in which only the edit interface varies, across six models, three code-editing benchmarks and over 4700 runs, with action-level replay of first edits. We find:

1.

Success hides misfit; cost reveals it. The gap that opens this paper is typical. The loop retries rejected edits, so the difference goes into cost instead. A run whose first edit is rejected costs up to 1.8 times as much, and on the refactors GPT-5.6-luna solves 1.64 times as many tasks per output token with line ranges as with search/replace (Section 4). Interfaces should be compared by first-action acceptance and tasks solved per output token, not by success alone.

2.

Evidence makes errors visible: quoting is checkable, pointing is cheap but silent. The longer a quotation, the more often it fails to match, but the restatement lets the harness check what the model asks it to change. Line ranges save that output, and save more the longer the span, but a wrong range is applied without any error. About one in five large first line-range edits is accepted and leaves code that no longer parses, and most of these would parse if one boundary moved by a line. Edits that land in the wrong place but still parse are not even included in this count (Section 5 and Section 8).

3.

Fit, not format, and habit is not fluency. Whether first edits are accepted depends on the pairing of model and interface (a significant model × interface interaction), even between search/replace and line ranges, which differ only in whether they point or quote. Each of the three interfaces is the best-accepted one for at least one model. Given a choice, DeepSeek-V4-Flash reaches most often for the form it writes worst, GPT-5.6-luna picks the patch format its developer trains on more than twice as often as line ranges, which it writes best, and some favor the tool listed first (Section 6).

• Read together, the results describe a division of labor that follows from fit. The model states its intent in the forms it writes fluently (Result 3). The harness does the bookkeeping of checking the target, reconciling small offsets and copying code, which is exact and nearly free for a harness but costly and error-prone in the model’s output (Results 1 and 2).

We then build verified selection from pointing and quoting together (Figure 1 call syntax in Figure 2d,e). The model points with line numbers and quotes only the first and last line of the span. The harness checks those boundaries, where silent errors concentrate, absorbs consistent small offsets, and copies already-read lines that the model references with a @@ref marker. On the refactors, over two runs and compared with bare line ranges, it cuts broken first edits by 63% for GPT-5.6-luna and 92% for MiMo-v2.5-Pro; compared with search/replace, it solves 1.43–1.77 times as many tasks per output token. On Microsoft’s RefactorBench, where one edit call often changes several files, it cuts broken first edits from 11 to 2. Its quoted boundaries also expose what a bare pointer misses, since 16% of first edits give line numbers that contradict their own quotes and a third of these would have parsed as bare ranges, invisible to any parse check. For Claude Sonnet 5, whose developer documents training it on string replacement, verified selection is accepted at least as often as that trained format, although no model was trained on verified selection (Section 8).

2. Fluency and Fit

2.1. Fluent in Two Ways of Addressing

We call an edit position-addressed when its target is named by coordinates in a file the model has read (a line range), and content-addressed when the target is named by reproducing its text (an exact quotation, or patch context that must match). For brevity, we say that a position-addressed edit points and a content-addressed edit quotes. The distinction concerns the edit call, not how the model found the code. In both cases the model has usually read the file first.

Both forms are common in the internet text that models are pretrained on. Position references pervade developer artifacts. Compiler diagnostics conventionally begin with sourcefile:lineno: [11], Python tracebacks report the line of each frame [12], and code hosts link to single lines and line ranges [13]. Content references are the substance of version-control history. Commit diffs identify changes by context lines and are used at scale to train code models [14]. Text also shows why pointing is cheap. Once something is in view, writers refer to it (“the function above”, “lines 120–150”) instead of restating it. Pointing draws on that fluency and costs few tokens, while quoting draws on the fluency in diffs and makes an edit checkable.

Post-training adds a second source of data, the trajectories that a model generates while using a harness, which carry that harness’s edit format. The model developers whose documentation we could verify train on their own edit formats. OpenAI models are trained on a patch format that quotes context lines [3], and Anthropic models on exact string replacement [2,6]. Open-weight developers train in specific scaffolds too (the code-agent RL scaffold of MiMo-V2-Flash exposes a str_replace tool [15]), and models trained on one scaffold’s trajectories transfer poorly to others [9,10]. The format itself is learned. Supervised fine-tuning raises a base model’s share of correctly formatted search/replace edits from 12% to 96% [16], and harnesses that serve many models configure the edit format per model [7,17]. We call what a model has learned about each form of address its priors, in the Bayesian sense, and keep two of their effects apart. A model’s habit is the form it reaches for when it may choose, and its fluency is how reliably it writes each form. Both are behavioral and measured at the interface. The two sources differ in reach. Natural text gives every model some fluency in both forms, while post-training on a harness adds fluency in that harness’s format, which models trained elsewhere lack. Because developers’ harnesses and data mixes differ, this account predicts that an interface’s fit should depend on the model.

2.2. Edit Calls and the Harness Check

An edit call is a triple

$$a=(\alpha ,\epsilon ,y),$$

(1)

an address $\alpha$, target evidence $\epsilon$, and replacement text y. Before writing, the harness checks the call against the current file, and what it can check depends on the interface. In search/replace, $\epsilon$ is the old text and $\alpha$ is derived from it (the unique match). In patch, $\epsilon$ is the context and $\alpha$ is again derived. In line-range, $\alpha$ is a line range and $\epsilon$ is empty, so the check can verify only the file revision and the bounds of the range. A rejection is feedback the model can act on. An accepted edit whose span is not the intended one changes the file without any feedback, so the error stays hidden until something else reveals it.

A harness can tell that an address misses its intended target only if it has evidence of that target, and in a single edit call that evidence is $\epsilon$. Omitting it from the call removes its cost, not the need for it.

We call an edit accepted when the check passes, and silently wrong when it is accepted but changes the wrong code, which the check cannot see. An interface fits a model when it asks only for forms the model writes fluently and leaves the rest to the harness. If models and interfaces combined additively, an interface would help or hurt every model alike. A model × interface interaction in acceptance is therefore the signature of fit as a property of the pair, which Result 3 tests.

2.3. What Misfit Costs in the Loop

The output an edit call requires grows with the text it restates, which is the new code plus the evidence. Moving a block shows how far apart the interfaces can be. search/replace writes it twice (quoted to delete it and again to insert it), line-range writes it once, and an interface that can reference already-read lines writes only a one-line marker.

If the agent retries until an edit is accepted, and each attempt costs its output plus one pass over the current context, the expected cost of an accepted edit is the cost of one attempt divided by the acceptance rate. How many accepted edits are wrong depends on what the check can see. The price of an attempt and what the check can see are the system side of fit; the acceptance rate is its model side. The results follow this split. The loop turns a low acceptance rate into cost (Result 1), the evidence an interface asks for trades output against silent errors (Result 2), how often each form goes through depends on the model (Result 3), and one design can address all three at once (Result 4).

• Evidence as a checksum.

Target evidence works like a checksum on the address. A line range carries none. A full quotation repeats the whole target, the most expensive form of redundancy. Quoting only the two boundary lines places a small checksum where pointing errors occur, at the edges of the range (Section 5). A revision hash plays the same role for a stale view of the file.

• Reading is cheap, but writing and re-reading add up.

Transformer inference processes the input in a parallel, compute-bound prefill and generates output one token at a time in a sequential, memory-bandwidth-bound decode [18]. An agent’s context is append-only, so serving systems reuse the key–value (KV) cache of the shared prefix across calls [19], and providers bill cached input for current models at a tenth of the uncached price or less [20,21]. Under perfect prefix caching, a run therefore pays full price only for what is newly read and what is written (Equation (A1), Appendix A). Per token, writing is the expensive part. Per step, the re-read prefix can dominate. In Claude Code and Codex sessions, a typical model call re-reads about a hundred thousand cached tokens to write about two hundred, and cached reads dominate total API cost [22]. Every retry pays one such re-read.

3. Setup

• Harness.

All runs use S-Code (https://github.com/sai-foundation/s-code), an open-source terminal coding-agent harness. The agent has three read-only tools (list_files, search_text, and read_file, which returns numbered lines and a file revision) and one edit tool, so that every correction it makes passes through the edit interface under study. Every write must carry the current revision. A run ends when the model stops or reaches fixed limits on model calls, tool calls and tokens (Appendix A). Only the edit interface varies within a comparison. The system prompt, read tools, limits, and tasks are fixed, and prompt and schema hashes are logged for each run.

• Interfaces.

search/replace takes old_text and new_text, and the old text must occur exactly once. patch takes a patch in the style of Codex’s apply_patch [4], with add and update operations and context that matches exactly once. line-range takes start_line, end_line and new_text, with numbers referring to the file as last read. Every arm also permits a whole-file write, which is recorded but not counted as a targeted edit. search/replace and line-range share the same call structure and instructions and differ only in the fields that address the target, so comparing them isolates pointing against quoting. For Result 3, menu conditions offer all three forms, either as argument shapes of one tool or as three named tools, with and without advice on when to use each.

• Models and benchmarks.

The main study uses GPT-5.6-luna, GLM-5.3, DeepSeek-V4-Flash, MiMo-v2.5-Pro and Qwen3.8-Flash, each through one pinned provider with its documented sampling settings (Table A1). CanItEdit [23] gives a file, an instruction and hidden tests. Its files are short and most edits replace a few lines. We use the 82 tasks that run without third-party libraries. The Aider refactoring benchmark [24] (the refactors, for short) has 89 refactoring tasks in long real-world files, scored on the syntax tree. All five models run the three interfaces on CanItEdit, which measures fit. On the refactors, where costs and silent errors grow with edit size, two models with opposite fits run every interface and every ablation, and search/replace, line-range and verified selection a second time. On CanItEdit, line ranges are accepted most often for GPT-5.6-luna and search/replace for MiMo-v2.5-Pro. Runs that fail because of the provider or the harness rather than the model are excluded (Appendix A), and every paired comparison uses the tasks with a valid run in every arm. Claude Sonnet 5 joined later on CanItEdit with search/replace and line-range only (Appendix A). The method evaluation (Result 4) adds verified selection and its ablations for GPT-5.6-luna and MiMo-v2.5-Pro on both benchmarks, and verified selection for Claude Sonnet 5 on CanItEdit. To test verified selection on edits that span more files and make more complex changes, we add RefactorBench [25], Microsoft’s benchmark of multi-file refactorings in nine open-source Python repositories. We run all four arms with GPT-5.6-luna on its 84 tasks that need no file deletion (Appendix E).

• Outcomes.

We measure outcomes at three levels, the acceptance of the first targeted edit (the first edit, for short), recovery through later edits or whole-file writes, and final task success. To measure visibility we distinguish rejected calls from accepted calls after which the file no longer parses. High acceptance is good only when the accepted edits are right, so we read acceptance together with silent error. An interface that accepts every edit but applies some to the wrong lines is not a better fit. All three benchmarks are in Python, and we parse with Python’s own parser. We call an accepted edit after which the file no longer parses broken. Breakage is the part of silent error that leaves a syntactic trace. It bounds silent error from below, since an edit that changes the wrong lines but still parses is not counted. The verified selection arms, whose calls quote the lines they point at, expose such edits when numbers and quotes disagree (Section 8). For every first targeted call in the main study whose address can be interpreted, we replay the action on the original file, measure the replaced region in token-equivalents (characters divided by four), and parse the result (Appendix A). Efficiency is tasks solved per output token (reasoning included) and per dollar, always within a model. Because a provider’s cache hit rate varies with the date of a run, we report dollars both as billed and under perfect prefix caching (Equation (A1)). Output-token efficiency is our primary cost measure because it does not depend on caching.

• Statistics.

We report Wilson 95% intervals for proportions, Cochran’s Q across three paired arms, and exact McNemar tests between two. Efficiency ratios use paired-task bootstrap intervals, and an asterisk marks intervals that exclude $1\times$. Edit-level regressions resample whole tasks.

4. Result 1: Success Hides Misfit, Cost Reveals It

Where did the difference in the opening example go? Because the model, not the harness, decides when an edit task is done, a poor fit need not change the outcome. It changes what the loop spends to reach it, since every rejected attempt is paid for and then repeated.

Table 1 and Figure 3 separate the first action from the final outcome. First-edit acceptance varies widely across interfaces, while task success on CanItEdit differs by 4 to 7 percentage points within a model, never significantly. GPT-5.6-luna’s first patch is accepted in only 23% of CanItEdit runs, yet with patches it solves 78% of the tasks.

The agent loop explains the gap. A rejected edit returns an error the model can act on. The model reads the error, re-reads the file if needed, and tries again or falls back to a whole-file write. Recovery thus keeps task success close across interfaces, but not cost. On matched tasks, runs whose first targeted edit is rejected cost 1.2–1.8 times as much as runs whose first targeted edit is accepted (Figure 4c).

The large-file refactors give the clearest case. Moving from CanItEdit’s short files to the refactors’ long ones, acceptance of GPT-5.6-luna’s first search/replace edit falls from .93 to .58 while that of its first line-range edit stays at .99 (Figure 3a). All three interfaces solve the same share of tasks for GPT-5.6-luna, but its first line-range call is about half as long as its first search/replace call. With line ranges it solves 1.64 times as many tasks per output token over two runs (Table 3; first run in Figure 4a). Where a model’s first calls often fail, retries dominate instead. On the refactors, MiMo-v2.5-Pro writes about twice as much output with patches as with search/replace and solves fewer tasks, at 0.45 times the efficiency. An interface that writes less is cheaper only if the model can use it.

• Where the money goes.

Our benchmarks’ contexts are short, so under perfect prefix caching output is 33–69% of a run’s cost. In long real sessions the balance shifts toward re-reading [22], which makes each avoided retry worth more (Appendix C).

Result 1 (Figure 3 and Figure 4). Success hides misfit; cost reveals it: the agent loop turns failed edits into retries, so interfaces differ in what a task costs, not in whether it is solved.

Why does one interface cost more than another to get right? The next section looks at what each form makes the model write, and what that buys.

5. Result 2: Evidence Makes Errors Visible

This section turns to the system side of fit, asking what each form costs to write and whether the harness can catch a wrong one. Quoting puts the evidence for a check in the model’s output, while pointing leaves the harness nothing to check.

• Quoting costs output and doubles as verification.

Across the search/replace edits of the main study, doubling the length of the quoted old text raises the odds of a no-match rejection by about a quarter, conditional on new-text and file length, whereas doubling the new text does not (Appendix B). Longer quotations do make ambiguous matches rarer (Figure 5). The asymmetry points to an exact-reproduction burden specific to the target, not a general penalty for writing more. The same quotation is what lets the harness refuse a mismatched edit before it changes the file. Restating the target is an explicit verification, paid for in output.

• Pointing is cheap and silent.

For edits replacing fewer than 200 token-equivalents, which dominate the sample, about 95% of both line-range and search/replace calls apply and leave a file that parses, so the compact address costs nothing in clean application. For larger regions the failure modes separate (Figure 6). search/replace rejects about one large edit in eight and silently breaks about one in fifty. line-range is rejected only about 1% of the time, but about one large edit in five applies and breaks the file. Most broken first line-range edits would parse if one boundary moved by a single line, exactly the kind of error a quoted boundary line detects.

• One silent error.

In a RefactorBench run, GPT-5.6-luna adds a parameter in four files with one line-range call. In celery/apps/multi.py it replaces lines 44–51, but its new text ends one line early and drops the closing parenthesis on line 51. The call is accepted, the file no longer parses, and the model is not told. Had the call quoted its last line, I=’%I’,, the quote would not have matched line 51, and verified selection would have refused the edit and reported that the quoted line is line 50.

• Line numbers stay usable when the view is fresh.

Line numbers go stale once the file changes, but the model keeps its view current. After GPT-5.6-luna’s first successful refactor edit, it re-reads the file before almost every later line-range edit, and none is rejected for a stale revision.

Result 2 (Figure 5 and Figure 6). Evidence makes errors visible: quoting pays output for edits the harness can check, while pointing saves output but fails silently, mostly with a boundary one line off.

This trade-off is the same for every model, yet the form that wins is not.

6. Result 3: Fit, Not Format

This is the model side of fit. We test whether acceptance depends on the pairing of model and interface, and whether the form a model reaches for is the form it writes best.

• Acceptance depends on the pair.

We regress first-edit acceptance on model, interface and task effects for the five models that ran all three interfaces on CanItEdit. Adding the model × interface interaction explains far more of the variation than the additive model ($p<{10}^{-40}$; test statistics in Appendix B), so how reliably a model writes an interface’s form depends on the pair. It holds for search/replace and line-range alone as well ($p=.003$), two interfaces that differ only in whether they point or quote. For task success the interaction is not significant ($p=.24$), since fit matters at the level of actions and the agent loop absorbs it before the outcome (Result 1).

• No interface is best for every model.

Acceptance rankings differ between models (Table 1). Line ranges have the highest first-edit acceptance for GPT-5.6-luna and DeepSeek-V4-Flash, search/replace for GLM-5.3 and MiMo-v2.5-Pro, and patch for Qwen3.8-Flash. The gaps are large. On 62 CanItEdit tasks, GPT-5.6-luna’s first line-range call is accepted and its first patch is not, and never the reverse. For Claude Sonnet 5, whose developer documents training it on string replacement, first edits are accepted at least as often with line ranges (1.00 against .92, $p=.03$). This is consistent with a training format being only one source of fluency, and with numbered reads making pointing easy to write.

• Habit is not fluency.

When one tool accepts all three forms, what a model reaches for first shows its habit, and that habit does not always match its fluency in this harness. GPT-5.6-luna, whose developer documents training on a patch format [3], picks patch more than twice as often as line ranges (35% against 16% of such runs; search/replace takes the other 49%). Yet with patch alone its first patch is accepted in 23% of runs, and with line-range alone its first line range in 99%. DeepSeek-V4-Flash goes further and reaches most often for the form it writes worst, while GLM-5.3 and MiMo-v2.5-Pro lean toward search/replace, which is also their best-accepted form. A model’s choice of interface thus reflects its habit, not a judgment of fit. This argues for one good default rather than a menu.

• Packaging and position matter.

When the three forms are offered together (Figure 7), no menu condition differs significantly in task success from the best single interface, but packaging changes first actions. Offering three named tools instead of one tool with three argument shapes raises GPT-5.6-luna’s first-edit acceptance by 16 points ($p=.004$), because it then picks line ranges more often and patches less often. The tool listed first is more likely to be called first by GPT-5.6-luna and Qwen but not by MiMo-v2.5-Pro (Figure 7), a position bias also reported for tool selection in general [26]. Advice on when to use each form tends to raise first-edit acceptance and to lower output efficiency.

Result 3 (Table 1, Figure 7). Fit, not format; habit is not fluency: acceptance depends on the model and the interface together, and the form a model reaches for need not be the form it writes best.

Can one interface be cheap to write, checkable by the harness, and written well by every model? The next section builds one.

7. Designing for Shared Fluency: Verified Selection

Verified selection answers by asking only for the two forms every model is fluent in, the ones natural text shapes. Rather than betting on the fluency that one developer’s post-training adds, it points with line numbers, as diagnostics, tracebacks and line links do, and quotes only the first and last line of the span, as diffs do. The model states its intent with an address and two lines of evidence, and the harness does the bookkeeping of checking, aligning and copying. Four design principles follow, one for each part of an edit’s cost and risk.

• P1: point with numbers, verify with boundaries.

The model addresses the span by start_line and end_line, which draws on the fluency in pointing and keeps the restated evidence small. It also quotes the first and last line of the span as read (first_line, last_line), which draws on the fluency in quoting at the boundaries, where Result 2 locates the silent errors. The check accepts an edit only if both quotations match the file at the stated boundaries. This restores evidence at a cost of two lines per edit and turns a boundary error from silent into visible, lowering the silent-error rate.

• P2: absorb small offsets when the evidence agrees.

A strict check rejects many edits whose range is off by one line even though both quoted boundaries agree on where it should be, lowering acceptance. Verified selection therefore looks for the two quoted lines within a few lines of the stated boundaries and moves the range only when both boundaries agree on the move. A shift in which only one boundary would move across code is refused, and the refusal reports where the quoted text actually is. Every applied move is reported to the model as a note (exact rules in Appendix D).

• P3: reference instead of retyping.

A line of new_text consisting of @@refA-B@@ stands for the original lines A–B, in the numbering the model read, and @@refpath:A-B@@ takes them from another file of the same call, so code can move between files without being retyped. The referenced lines must lie inside a range the call verifies, and the harness copies them before applying any edit (rules in Appendix D). For a move, this shrinks what the model writes from the whole block to one marker line (Figure 2e).

• P4: one snapshot, no drift.

All ranges in a call refer to the file as read and are placed before any edit is applied. Edits are then applied from the bottom up, so an insertion does not shift the line numbers of edits not yet applied [14].

The model-visible changes from line-range are two string fields, a description of @@ref in the schema, and a paragraph of instructions with one move example.

8. Result 4: Evaluating Verified Selection

This section tests the three properties asked for above. We ask whether verified selection stays cheap to write, whether it catches the errors that bare pointing lets through, and how models with opposite fits write it.

Table 2 and Figure 8 report verified selection and its ablations on the refactors for GPT-5.6-luna and MiMo-v2.5-Pro, on the tasks where every arm has a valid run. Column P1 is the boundary check alone, P1+P2 adds alignment, and verified selection adds @@ref (P3). Table 2 reports the first run of each arm. Table 3 repeats the search/replace, line-range and verified selection arms with the same builds and settings, and the white diamonds in Figure 8 mark the second run.

Table 3. Two runs of the headline arms on the refactors, on tasks valid in every arm of both runs (GPT-5.6-luna 82, MiMo-v2.5-Pro 85). Pooled combines both runs. “Per output token” is tasks solved per output token relative to search/replace, with a bootstrap that resamples tasks together with both of their runs. Paired comparisons count, for each task, which arm did better over its two runs (tasks where the arms tie are left out) and use a sign test across tasks. A run without a targeted edit counts as not accepted. *: 95% interval excludes $1\times$.

	Run 1	Run 2	Pooled
GPT-5.6-luna (82 tasks)
First edit accepted, search/replace → verified selection	.60 → .83	.67 → .90	33 vs. 10 tasks, $p<.001$
Broken first edits, line-range → verified selection	11 → 5	8 → 2	15 vs. 4 tasks, $p=.019$
Task success, line-range → verified selection	.939 → .963	.939 → .963	6 vs. 2 tasks
Per output token, line-range vs. search/replace	1.74	1.54	1.64 [1.39, 1.94] *
Per output token, verified selection vs. search/replace	1.81	1.72	1.77 [1.48, 2.10] *
MiMo-v2.5-Pro (85 tasks)
First edit accepted, search/replace → verified selection	.76 → .67	.79 → .66	20 vs. 30 tasks
Broken first edits, line-range → verified selection	34 → 5	37 → 1	48 vs. 2 tasks, $p<.001$
Task success, line-range → verified selection	.859 → .929	.812 → .941	20 vs. 4 tasks, $p=.002$
Per output token, line-range vs. search/replace	1.09	1.19	1.14 [0.90, 1.46]
Per output token, verified selection vs. search/replace	1.39	1.47	1.43 [1.10, 1.93] *

Table 3. Two runs of the headline arms on the refactors, on tasks valid in every arm of both runs (GPT-5.6-luna 82, MiMo-v2.5-Pro 85). Pooled combines both runs. “Per output token” is tasks solved per output token relative to search/replace, with a bootstrap that resamples tasks together with both of their runs. Paired comparisons count, for each task, which arm did better over its two runs (tasks where the arms tie are left out) and use a sign test across tasks. A run without a targeted edit counts as not accepted. *: 95% interval excludes $1\times$.

	Run 1	Run 2	Pooled
GPT-5.6-luna (82 tasks)
First edit accepted, search/replace → verified selection	.60 → .83	.67 → .90	33 vs. 10 tasks, $p<.001$
Broken first edits, line-range → verified selection	11 → 5	8 → 2	15 vs. 4 tasks, $p=.019$
Task success, line-range → verified selection	.939 → .963	.939 → .963	6 vs. 2 tasks
Per output token, line-range vs. search/replace	1.74	1.54	1.64 [1.39, 1.94] *
Per output token, verified selection vs. search/replace	1.81	1.72	1.77 [1.48, 2.10] *
MiMo-v2.5-Pro (85 tasks)
First edit accepted, search/replace → verified selection	.76 → .67	.79 → .66	20 vs. 30 tasks
Broken first edits, line-range → verified selection	34 → 5	37 → 1	48 vs. 2 tasks, $p<.001$
Task success, line-range → verified selection	.859 → .929	.812 → .941	20 vs. 4 tasks, $p=.002$
Per output token, line-range vs. search/replace	1.09	1.19	1.14 [0.90, 1.46]
Per output token, verified selection vs. search/replace	1.39	1.47	1.43 [1.10, 1.93] *

• Against search/replace: first edits go through.

For GPT-5.6-luna, verified selection gets the first edit through far more often than search/replace (83% against 60% of runs, $p=.001$), and it is the most efficient interface for this model, at 1.77 times the tasks per output token over two runs (Table 3). MiMo-v2.5-Pro shows the other side of the trade-off. Its first edit is accepted less often than with search/replace in both runs, yet both runs are cheaper, at 1.43 times the tasks per output token (pooled) and equal or better success.

• Against line ranges: silent failures become visible.

Most first edits with bare line ranges are accepted, and many of them break the file. Over two runs, verified selection cuts broken first edits from 19 to 7 for GPT-5.6-luna and from 71 to 6 for MiMo-v2.5-Pro (Table 3). For MiMo-v2.5-Pro, whose bare ranges break about half of the first edits they apply, this also raises task success ($p=.002$). The quoted boundaries also show how often a pointer misses. In the boundary-checked arms, 16% of first edits on the refactors and 8% on CanItEdit give line numbers that contradict their own quotes. A syntax check after each edit, as in SWE-agent’s line-range command [5], would catch only the misses that break the file. That is about two thirds on the refactors and fewer than half on CanItEdit. The boundary check aligns or refuses all of them, needs no parser for the language, and tells the model where the quoted line actually is. For GPT-5.6-luna, whose bare line ranges were already mostly clean, verified selection costs no efficiency.

• Ablation.

Read across the columns, Table 2 separates the two sources of gain. Pointing instead of quoting reduces what the model writes (line-range against search/replace), and verified selection adds verification without adding output (verified selection against line-range). Each component addresses one part of an edit’s cost or risk. The boundary check alone removes most broken edits but also refuses many recoverable ones, lowering first-edit acceptance and efficiency, most sharply for MiMo-v2.5-Pro. Alignment recovers both without readmitting broken edits. @@ref then shortens the output where the model uses it. GPT-5.6-luna references lines in two thirds of its runs and becomes 1.16 times as efficient per output token as with alignment alone, while MiMo-v2.5-Pro rarely uses it.

• Small edits.

On CanItEdit, where most edits touch a few short lines, verified selection changes efficiency little, and @@ref is not used. Little is restated in small edits, so there is little to save. For GPT-5.6-luna, task success with verified selection is higher than with search/replace in both of two runs ($p=.02$) at similar efficiency.

• Claude Sonnet 5.

Claude’s developer documents training it on exact string replacement [2,6], while verified selection did not exist before this study. On CanItEdit, Claude edits in place on its first try in 78 of 80 runs with verified selection against 70 of 80 with search/replace ($p=.02$). With search/replace, the other ten runs either have their edit rejected (6) or rewrite the whole file instead (4), so its first targeted edit is accepted in 70 of 76 runs, the .92 of Table 1. With verified selection, every run edits in place, and no applied first edit breaks the file in either arm. Verified selection solves 1.25 times as many tasks per output token as search/replace, at similar task success. An interface no model was trained on is thus accepted at least as often as the one this model was trained on.

• Edits across files.

RefactorBench refactors span files, and nearly every accepted first line-range edit changes more than one file in a single call. The pattern of the large-file refactors holds (Table 4). Task success is again flat while first-edit acceptance varies widely. Bare line ranges break 11 accepted first edits and verified selection 2 ($p=.012$), and the quoting interfaces break none. Verified selection sometimes moves code between files with @@ref, and its efficiency gain over search/replace concentrates on the 34 tasks that move code (1.25 times per output token), while on renames and signature changes bare line ranges are the most efficient interface.

Result 4 (Table 2, Table 3 and Table 4). Pointing checked at its boundaries keeps most of the efficiency of pointing and removes most of its silent errors, for three models and for edits that span files.

9. Discussion: Designing Edit Interfaces

Our findings suggest two practices for edit interfaces.

• Measure the loop, not only the outcome.

An agent stops when the model judges its work done, so an interface defect rarely shows as a failed task. It shows as the tokens spent getting there. Reporting first-action acceptance and tasks solved per output token alongside success, within each model, is what exposes it, in line with calls for cost-controlled agent evaluation [27,28]. Dollar comparisons should state their caching assumption, because providers billed as cached a much smaller share of input than an append-only context allows.

• Divide the edit call.

Which form a model writes reliably differs between models (Section 6), and left to choose, models follow their habit even where it serves them poorly, so a menu of formats is no substitute for a good default. A harness that serves many models can provision each with its own format [7,17], or offer one interface in the forms they all write fluently. The first route chases each model’s best acceptance. The second draws on the fluency that natural data shapes and every model shares, rather than on what one developer’s post-training adds. It gives up some acceptance for some models (MiMo-v2.5-Pro’s first edit goes through less often with verified selection than with search/replace) in exchange for errors that are visible rather than silent, trading part of the model side of fit for the system side. Either way, a model’s output is the most expensive and least exact part of an edit, so the interface should ask the model only for its intent (a pointer and the least evidence that makes the pointer checkable) and leave the rest to the harness. Numbering the file, checking boundaries, shifting a range and copying code are exact and almost free for a harness. Doing them there moves work out of output tokens, which are decoded one at a time, into steps that read what is already in the context, which the KV cache makes cheap [19]. Revision hashes already follow this pattern for stale views, and boundary checks extend it to miscounted positions.

10. Related Work

• Edit representations.

Aider compared search/replace blocks and unified diffs and introduced the refactoring benchmark used here [24,29]. CanItEdit and EDIT-Bench evaluate instructed edits [23,30], and RefactorBench multi-file refactoring [25]. Diff-XYZ evaluates generating and applying diffs outside an agent loop [31]. Cheng et al. replace offset-based diffs with block-level rewrites of syntactic units (BlockDiff, FuncDiff) and train models to choose between a diff and the full file (AdaEdit) [32]. SWE-Edit moves editing into a separate editor subagent trained to choose between find-and-replace and whole-file rewriting [33]. A comparison of five edit tools in one agent covers 23 SWE-bench Pro tasks [34], and practitioner harnesses keep adding variants, such as search blocks with line-number hints [35] and line references tagged with content hashes [36]. Lee et al. measure the cost of structured output, the “format tax” [37]. OctoPack studied line-number diffs as a training target [14]. These works ask which representation of a change, or which trained choice among them, gives the best final result. We vary only how an edit call names its target, and measure what final results hide, namely first-action acceptance, the cost of the loop’s recovery, and whether an error is seen at all. Verified selection needs no training. It changes what the harness checks.

• Agent–computer interfaces and harnesses.

SWE-agent showed that interface design changes agent performance and used a line-range edit command that rejects edits introducing syntax errors [5]. Surveys treat the harness as part of the agent [8,38], and DCAS narrows the gap between training and deployment scaffolds by fine-tuning on planning-aware trajectories [10]. We measure fit at one component, the edit interface, and improve it in the harness rather than in training.

• Cost and serving of agents.

Cost-controlled evaluation [27,28] motivates our efficiency measures. Serving research exploits the append-only structure of agent contexts through prefix caching and KV reuse [19,39,40]. Recent work characterizes coding-agent traces and the effect of caching on agent cost [22,41]. We tie these costs to an interface decision in the harness.

11. Conclusions

An edit interface decides how much of the target a model must restate, and therefore what the agent loop pays and what the harness can verify. Task success hides misfit, and the loop pays for it in retries. Quoting buys checkable edits with output, while pointing saves output and fails silently. How reliably a model writes each form depends on the pair, and a model’s habit is not its fluency. Verified selection asks only for the two forms every model is fluent in and keeps most of both benefits on large edits and across files. The lesson for edit interfaces is fit, not format.

• Limitations.

We count a silent error only when it leaves a trace, that is, when the file no longer parses or when line numbers contradict the quotes of a call that quotes its boundaries. Misplaced edits that still parse are therefore undercounted for bare line ranges. We measure fluency and habit, not their origin; their link to pretraining text and to post-training harness trajectories rests on documentation. The large-file results come from two models, with the three headline interfaces run twice, and the multi-file results from one model in one run. The properties of the interfaces carry over to new models. A line range carries no evidence a harness could check, and a quotation costs more output and fails more often as it grows. How often each form is written correctly depends on the model and has to be measured for each.