Published 2026-04-21.
Time to read: 2 minutes.
llm collection.
LLM users interact with a harness (just a fancy name for a GUI client.) The harness accepts user interaction, communicates with the LLM, then performs whatever instructions the LLM sends to it. Scary, huh? This is a security nightmare. Such is life in 2026.
Harnesses communicate with the LLM using a defined protocol. Each LLM vendor has their own protocol, although there are many similarities.
When modifying a text document, LLMs and harnesses can opt to modify the protocol they communicate text changes with. Because protocols are implemented by algorithms, one could equally well say that harnesses use an adaptive algorithm to communicate text changes to LLMs. Both harnesses and LLMs can request or require specific edit formats.
Standard edit formats are whole, diff, and diff-fenced.
whole
The whole edit format transmits the complete document. While it
is the most reliable, it is significantly slower than the other options,
while also being the most expensive edit format.
diff
When diff is specified as the edit format for an LLM, it refers
to the Unified diff format (also known as unidiff). When LLMs
use this edit format, they return only the changes to the document, not the
entire document.
Unidiff headers (like @@ -10,5 +10,6 @@) contain line numbers.
LLMs are
notoriously unreliable at counting and tracking exact line positions, making
the diff edit format less reliable.
- Pros: Fast and token-efficient because it only transmits the edits.
- Cons: Higher failure rate if the LLM provides an original block that doesn't perfectly match your local file's text.
- Best for large files and complex refactors where you want to save time and tokens.
diff-fenced
Most LLM coding tools, including the Claude Code CLI, primarily use the diff-fenced edit format.
The diff-fenced format is technically entirely different from the
diff format. The most important difference is that the
diff edit format uses line numbers, but diff-fenched
edit format does not. Instead, the filename and search/replace blocks are
within standard Markdown code fences (triple backticks). While a standard
diff uses line numbers, diff-fenced
instead uses a Markdown structure.
Because diff-fenced edit format lacks line numbers, the SEARCH
block must be a 100% perfect match, including every space, tab, and newline.
If the LLM hallucinates even a single character, the search fails and the edit
cannot be applied.
Large files often contain repetitive patterns. Increasing the length of the SEARCH block linearly increases the probability of a character-level mismatch due to hallucination. Since the LLM must reproduce the existing code identically, longer context blocks actually decrease the reliability of the edit.
When a unique match is not found (usually because the LLM hallucinated a
character in the SEARCH block), most coding tools switch to the slower and
more expensive whole edit format for that file.
