The same one-line edit takes an agent 318 seconds, or 8.7

Give an agent a 100 KB HTML document and ask it to change one cell in one table. If it has to hand you back the whole page, that takes 318 seconds. If it can hand you back a description of the change, it takes 8.7 seconds. Same model, same server, same edit, 36× apart. The interesting part is not the ratio. It is that the two numbers scale differently, so the ratio is a function of how big your document is.

The measurement

We ran this on production on 7 July 2026. Per repetition: create a fresh doc seeded with a fixture, then make the identical visible change two ways — (A) re-emit the whole updated page and PUT it, (B) emit one patch operation and POST that. The clock starts before the model emits anything and stops when the write response comes back, so it brackets token generation plus one round trip plus the write. The full-replace arm genuinely re-typed the page each repetition rather than echoing it from disk, which is the point: that typing is the cost.

One small edit: seconds of agent wall-clockMedian of 3 runs against production. Lower is better.103.1 s7.9 s30 KB document318.1 s8.7 s100 KB documentre-emit the whole pagesend a patch
Medians of three runs. Raw repetitions, 30 KB: rewrite 105.8 / 102.1 / 103.1 s, patch 10.7 / 7.9 / 7.3 s. At 100 KB: rewrite 325.1 / 318.1 / 317.4 s, patch 8.7 / 10.2 / 7.7 s.

The result is the slope, not the ratio

Tripling the document tripled the rewrite (103 s to 318 s) and left the patch alone (7.9 s to 8.7 s). Patch cost tracks the size of the change. Rewrite cost tracks the size of the document. That is a difference in kind, and it means any single speedup figure is only true for the document size it was measured at.

Rewrite scales with the page. Patch does not.Two measured points each, joined for shape.103 s318 s~8 s30 KB100 KBdocument size →seconds per edit
The flat line is the interesting one. Roughly 8 seconds of it is fixed overhead — a 56-token patch generates in under a second — so the measured speedups understate the generation gap.

None of it is the network

A companion run measured the same two paths on the wire, with the model taken out of the loop entirely: 111.7 ms for full-replace against 125.7 ms for patch. Parity, and patch is marginally slower, because the server re-ingests the same resulting page either way. So the whole difference above is the model emitting tokens. If you are trying to make an agent cheaper and you are looking at your transport, you are looking at the wrong layer.

DocumentTokens to rewriteTokens to patchReduction
1.4 KB~342~467×
30 KB~8,486~56152×
100 KB~28,409~56507×

The failure we did not expect

Re-emitting the 100 KB page by hand did not just take five minutes. It came back wrong. The rewritten page arrived at 105–107 KB against a 103 KB seed, because the model duplicated table rows it was never asked to touch. We had been treating this as a latency experiment; it is also a correctness one. An interface that makes the agent restate the parts it is not changing gives it the opportunity to change them. A patch cannot corrupt what it does not mention.

What we would take from this

  1. Look at the interface before the model. The cost difference here is 36× on identical work with an identical model. No model swap available today moves a number like that.
  2. Ask what your agent's cost scales with. If it scales with the size of the artifact rather than the size of the change, every success makes the next edit more expensive — the document grows, and the bill grows with it.
  3. Distrust any single speedup number, including these. Ours are 13× and 36×, and both are true only at the size measured. The slope is the durable claim; the ratio is a snapshot.
  4. Count the silent corruption, not only the clock. The rewrite path damaged content nobody asked it to touch, and that is the kind of failure a human review pass has to catch afterwards.
Method, and the parts that cut against us. Two runs, both against production on 7 July 2026, both recorded in our repo. The wall-clock figures are N=3 on a single machine, and both arms include model reasoning overhead, so they are not a clean isolation of typing. Tokens were approximated at 3.7 bytes per token because tiktoken was unavailable offline; the real figure for dense HTML is nearer 4–4.3, which means the token reductions above are slightly understated. The ~8 s patch floor is almost entirely fixed harness and turn overhead rather than generation, so the speedups are conservative for the same reason. The payload table is a direct measurement of bytes the model must emit divided by that ratio, not a token count from a live model run. The patch arm's operations were hardcoded to one fixture's element ids, so reproducing at other sizes needs those ids recomputed. And all of it should be re-run when the model changes, because the price ratio between reasoning and typing moves underneath the result.

Second in a short series. We are a two-person project trying to get a developer tool in front of people, and we keep finding that the received wisdom in this area is either unmeasured or measured once and copied forever. When we check something and the answer is useful, we write it up like this — including when the answer is that we were wrong.