Most token-saving tools focus on input tokens, but output tokens are usually priced higher, and edit-heavy agent sessions waste a lot of them on a specific pattern: to safely edit a file, the agent has to output the old code block plus the new code block, just so the harness can match and swap it in. That's safe (content-based matching means line drift doesn't cause a bad edit), but it means half the tokens going out are just the agent restating content it already read.

Plain line-range edits ("replace lines 50-60") avoid the resend but aren't safe, the moment any prior edit shifts the file, the range is stale and the agent edits the wrong lines.

My proposed fix keeps content-based safety without the resend:

1. On file read, return numbered lines + a blob id for that exact snapshot. 2. On edit, the agent sends only the blob id, a line range from that snapshot, and the new content. No old code required. 3. The system finds that range in the stored blob (not the live file), applies the change there, and three-way merges it into the current file (git's merge machinery handles this well).

Since the anchor is an immutable snapshot rather than the live file, the agent is replaying a known edit against a known point-in-time, and letting the merge reconcile it with whatever the file looks like now. Net effect: only new content is emitted as output tokens, instead of new + old.

Caveat: I built a CLI proof of concept, and it works on small files, but now I found most agent harnesses truncate bash tool output around 16KB, so round-tripping file reads through a bash channel breaks down on anything bigger. That's a limitation of doing this externally, implemented natively inside a harness (where reads/edits don't have to go through a size-capped channel), it shouldn't apply.

Repo (mechanics reference, not production-ready): https://github.com/Brajesh2022/VCS-edit-tools

My attempt to fix it failed because of the truncation limitations. I hope any harness builder who sees this post will apply it to a harness.