AI-Assisted Git Merge Conflict Resolution Cost: 3-Way Merges with LLMs

Why 3-Way Merges Are Expensive

A git 3-way merge conflict has four inputs the LLM must reason over: the common ancestor (base), your branch's version (ours), the incoming branch's version (theirs), and the target file after prior conflicts. On top of that, the model usually needs surrounding context — function scope, related files, and sometimes commit messages that explain why the divergence exists.

That means the raw token math for one conflict is not "here is a diff, resolve it." It is closer to: base file section + ours file section + theirs file section + neighbouring code + optional commit context. Depending on the size of the affected function, one conflict is 2K-15K input tokens.

Cost by Conflict Shape

Not all conflicts are equal:

• Trivial: whitespace, adjacent-line, import-order, comment. Both sides did the same thing differently.
• Small structural: both branches renamed the same variable to different names, or added competing but compatible logic.
• Overlapping refactors: both branches restructured the same function differently. Requires semantic understanding of intent.
• Cross-file: the conflict in file A implies related changes in file B (renamed exports, changed signatures). Requires reading beyond the conflict marker.

Per-Conflict Cost, by Model

For a routine feature branch merge with 10 trivial and 3 small-structural conflicts, Sonnet 5 costs about $0.25 total. For a rebase after a large refactor with 20 cross-file conflicts, expect $8-$40 depending on model.

Where LLM Merge Resolution Fails

• Semantic conflicts with no textual conflict. Two branches both compile and pass conflict-free, but the merged code breaks at runtime because they made incompatible assumptions. The model will not spot these without running tests.
• Intent ambiguity. When both branches have plausible interpretations and only the author knows which was intended, the model picks the wrong one silently.
• Generated code. Two branches regenerated the same protobuf or GraphQL schema differently. The merged output must be regenerated from source, not stitched from conflict halves.
• Long histories. Rebases with 30+ commits each touching the same file compound into unresolvable messes; the model will attempt a resolution that ignores intermediate state.

Recommended Automation Cutoffs

1. Auto-resolve trivial conflicts. Haiku with a strict schema output. Commit with an "auto-resolved" tag so reviewers know.
2. Suggest, do not commit, for small-structural. Sonnet 5 proposes; human accepts or rejects in a diff view.
3. Never auto-resolve overlapping refactors or cross-file conflicts. Use the LLM as an assistant showing three candidate resolutions; human picks one.
4. Run tests after every resolution. A merge that passes conflict resolution but fails the test suite must be rolled back.

Where the Real Value Sits

The dollar cost per conflict is trivial. The engineering-time saving is not:

• A senior engineer resolving 20 trivial conflicts by hand takes 15-30 minutes. LLM auto-resolve turns that into 30 seconds of review.
• An engineer diving into a cross-file conflict without context can burn 45 minutes reading history. An LLM that summarizes intent from commit messages saves most of that time.
• Rebases that used to be abandoned ("just merge instead") become tractable.

Bottom Line

Full merge-conflict automation is a mistake. Selective automation with clear cutoffs is one of the highest ROI uses of an LLM in day-to-day engineering. Budget $1-$5 per non-trivial branch merge and treat it as a routine build-system cost.