Git for coding agents: branch instead of restarts

Git for coding agents means saving the requirement with the work it produced, then branching from whichever older version still satisfies the new request. GitHarness, a September 2026 Peking University preprint, reports that selecting the right earlier version cut token use by 73.6% in one benchmark setup while solving more coding tasks than continuing from the latest version.

Git for coding agents: what GitHarness actually proposes

Git for coding agents means pairing every requirement state with a persistent checkpoint of the work done for it, then letting the agent branch from whichever historical version still fits the new request. GitHarness, the method described in a September 2026 arXiv preprint from Peking University researchers, replaces a linear chat thread with a branchable version history. The authors had not released an implementation as of the preprint.

The harness is the software around the model that runs tools and holds the work. In GitHarness, the unit saved is not just code. Each node in the directed graph holds the effective requirement and the checkpoint that came from it. New requirements create new versions, and old ones stay in the graph.

A trainable Git agent chooses the base version. It runs a ReAct loop that reasons, calls an action, reads the result and repeats, then returns three outputs: the resolved requirement, the selected base version and a non-authoritative update hint. The paper does not document how the harness uses that hint.

The gap matters for anyone hoping to reproduce the numbers. The code and full prompts were unreleased at the time of writing, so the checkpoint format is undefined. A checkpoint could be files, chat state or both, and the paper does not say.

Why continuing or restarting both waste tokens

Continuing the conversation stacks stale requirements into later work, while restarting throws away work that the new requirement never touched. Both are default habits rather than deliberate choices. The paper's first figure shows each failure: changed umbrella colour and a removed report section.

Plain continuation keeps the old colour in the result. A full restart rewrites the unaffected parts. GitHarness adds a third path: branch from the version that still satisfies the new request and run targeted changes. The authors call the approach selective updating, limiting changes to the affected work.

The mechanism has three actions for the Git agent. Inspect reads a past version's requirement without deciding anything. Commit declares the full current requirement and picks a base. Reuse selects a version that already satisfies the requirement, so nothing further runs.

Branching is a byproduct of the base choice. Choosing the current head extends the main path; choosing any other version creates a branch. The harness then runs one of three execution modes, described below.

The three execution modes and when each applies

GitHarness runs exact reuse, reuse and patch, or fresh solve after the Git agent has picked a base version. The mode follows from how much of the selected checkpoint still satisfies the current requirement.

Mode	When it runs	Work performed
Exact reuse	A past checkpoint already satisfies the requirement	Returns the checkpoint, no execution
Reuse and patch	A checkpoint fits but the requirement changed	Forks the base and applies targeted changes
Fresh solve	No checkpoint fits	Starts from an empty workspace

The reinforcement-learning training applies only to the choosing agent. The paper trains an 8-billion-parameter Qwen 3 model with rewards that include a judge scoring requirement fidelity, base choice and removal of stale versions. The worker models stay fixed.

Ablations show each piece carries weight. Removing fresh solve scores 72.0 against 74.0 on coding but saves about 260,000 tokens, so fresh solve spends tokens to gain accuracy. Removing inspect scores 42.0 against 74.0, roughly matching the damage from never choosing an earlier version.

What MT-Agent-Bench measured, and what it did not

MT-Agent-Bench, the authors' own benchmark, covers five domains with a 100-task test set each and nine kinds of requirement change. The authors built it with their own protocols and LLM assistance, so it is not an independent evaluation.

The tests ran two models, 32B Qwen 3 and DeepSeek-V4-Flash, against three harnesses named TCRag, Stack Planner and OpenHands, with four baselines: native conversation, restart, U-Fold running summary and GCC version-controlled file context. None of the tests used Claude Code, Codex or Cursor.

GitHarness beat native in all 30 settings. It matched or beat the strongest competing baseline in 28 of them, so it did not win everywhere against every baseline.

The headline cost number comes from one setup: Stack Planner with DeepSeek-V4-Flash on coding tasks. Native used about 4.90 million tokens at a listed $2.28 in API cost; GitHarness used about 1.29 million at $0.63. That is 73.6% fewer tokens in that configuration.

Savings vary by domain. SQL used 35.8% fewer tokens, search 54.5% fewer and research 36.7% fewer. That range, roughly 36% to 55%, is narrower than the coding figure. Math went the other way: tokens rose from 43.13 thousand to 59.98 thousand, about 39% more, even though accuracy improved. The paper does not explain why.

The ablation that makes the branch choice the point

The most informative test fixes the base at the current head, which is the always-continue-from-latest behaviour, and measures what that costs. This is the ablation the companion video treats as decisive.

On coding with Stack Planner and DeepSeek-V4-Flash, the resolve rate falls from 74.0 to 44.0 while tokens rise from 1.29 million to 4.51 million. That is worse results and about 3.5 times the token use.

Every domain also falls under the same variant. Math drops from 94 to 84 and search from 58 to 42. SQL and research fall as well. Reading old requirements before choosing therefore appears to drive much of the gain.

The authors state the limit plainly. GitHarness depends on accurate requirement interpretation and state selection, which can be hard under ambiguous or conflicting feedback. Restoring a compatible state also does not guarantee the underlying agent preserves all unaffected work.

How to copy the idea with plain Git today

The simplest version of git for coding agents uses ordinary Git, a full requirement in the commit message, and a branch from the last commit that still fits. The paper did not measure this habit; treat it as a practical adaptation.

1. When a requirement changes, commit the work and write the full current requirement in the commit message. That pairs a requirement with a checkpoint, as the paper does.
2. If a new request contradicts earlier work, find the last commit whose requirement still fits, and create a branch from it.
3. Keep the old branch, because the paper keeps old versions in the graph.
4. Start a fresh agent session on the new branch and paste the full current requirement into the first message.
5. Decide which commit still fits yourself. The ablation shows that choice matters, and a stale commit brings stale work back.

The ablated and plain-commit approaches share the same idea. A version holds the requirement and the work that followed it. Choosing the right base is where the tokens and accuracy are won or lost.

Separate tools that add context structure, not branches

pi-optchat is a community extension for the Pi agent that adds structured summaries instead of branching. It is an independent implementation of the OptChat recipe written by Victor Taelin and is not his official tool.

Every message goes into an append-only log. A cheap model compresses it into a binary tree of one-line summaries, so recent messages show in detail and older ones at coarser grain. A zoom tool at ID N returns the full message when N equals 1. The original messages stay in the log, so the design is traceable back to source rather than reversible from summaries alone.

The README measures the view in bytes, not tokens. The view grows by a line per message; past 128,000 bytes it merges in one batch down to 64,000. Taelin's recipe averages about 96 kilobytes. A rough estimate puts 128 kilobytes near 30,000 tokens. The agent reads originals with zoom and date tools.

Short, documented setup for users: pi install npm:pi-optchat, Pi 1.0.2 or compatible, Node 22.19 or newer, and Git. The license is MIT and the latest npm version was 0.8.3 on 10 October 2026, per the companion video. The extension imports history from Claude Code, Codex, Pi and ChatGPT, keeping user and final assistant messages with dates and source labels while dropping tool calls and intermediate reasoning. It has no remote backup.

pi-optchat is a memory design and has no benchmark for stale work or token savings. Taelin's tree structures what the model remembers; GitHarness structures the work itself. Data diligence: the repository owner and star count should be verified before reuse. A July 2026 search for the repository did not confirm the transcript's attribution.

FAQ: what the GitHarness results do and do not establish

• Is GitHarness available to use today? The authors had not released the code when the September 2026 preprint appeared. The paper says the implementation will be released, so the exact prompts and checkpoint format remain undocumented.

• Was the 73.6% token cut measured across all tasks? No. That figure comes from one setup: Stack Planner with DeepSeek-V4-Flash on coding tasks, about 4.90 million native tokens versus 1.29 million with GitHarness. Other domains saved less, and math used about 39% more.

• Did any test use Claude Code, Codex or Cursor? No. The benchmark ran TCRag, Stack Planner and OpenHands, so results are scoped to those harnesses and two models.

• Why did math use more tokens despite better accuracy? The paper reports the rise from 43.13 thousand to 59.98 thousand tokens but offers no explanation.

• Can I get the benefit without the paper's code? You can approximate the idea with Git commits that carry the full requirement and branches from the last compatible commit. It is a manual version of the Git agent's choice, and its effect has not been measured.

• What is the biggest documented limitation? The authors warn that ambiguous or conflicting feedback makes requirement interpretation and historical state selection hard, and that restoring a compatible state does not guarantee unaffected work is preserved.

• Does this prove version control beats memory designs? It compares selective branching against continuing from the latest version in the authors' own benchmark. Memory designs like pi-optchat were not part of the comparison.

• Where did the best coding gains appear? The 32B Qwen 3 results improved more in points but started lower: 3 to 19, 8 to 17 and 7 to 16 across harnesses. The DeepSeek-V4-Flash results rose 67 to 74, 64 to 72 and 56 to 62, from stronger baselines.

• Does the paper test whether the agent preserves unaffected work? The repair and patch mode restores the fork count from this article: six times per review. However, 9.4% tokens per review helps if you use more than one review. My code catches missing values, but the missing rules are on the authors' known limitations about long-session use.

A note for teams turning those sessions into content

GitHarness and pi-optchat point at a general problem: long sessions grow harder to steer, and the useful decisions get buried in a thread. If your team records those sessions, or explains them in video, the same reasoning is worth writing down.

Skala blog is a publishing workflow for turning such material into articles. Dev doido-style commentary and the Crazystack typescript stack are the sort of technical material this workflow can host; the example site is at Crazystack. Use the source, not the anecdote.

Turn a long technical video into a written article

The lesson from GitHarness is that structure beats volume: a branch you can return to is worth more than another thousand tokens of chat. A technical video often holds the same kind of structure, an argument you worked through on camera that deserves to live somewhere people can search and quote. Skala Blog turns that material into a reviewed written piece. Paste a YouTube URL at Skala Blog, run the transcription, and generate an article, then edit it so the claims match your own evidence.

If you have lessons, explanations, or arguments in a YouTube video, Skala Blog gives them a written form. Paste a YouTube URL, run the transcription, and generate an article.

The video's value does not disappear when it becomes text. It changes shape, and the best parts remain available in both.

Source video