Comparing branches side by side

Once you branch, you'll eventually hold two good answers to the same question. Comparing is how you choose between them without rereading both paths end to end and trusting your memory to catch the differences.

And it happens fast. You branch a 40-message thread to test a second approach, the second approach also works, and now it's Thursday and you owe someone a single answer.

Two branches, one diff

The two-way compare starts from the "Compare with" dialog. From whichever pane you're in, "Compare this pane with" sets it against the main thread or another branch, and GPTree renders the result as a diff rather than two columns of prose. Red marks content removed or only present in the other pane. Green marks what was added or only exists in this one. Everything the two paths share stays quiet.

The diff is a deliberate choice. Two full replies placed side by side look rigorous, but your eyes skim both and register neither. A diff does that reading for you and points at the exact spots where the branches disagree, which is nearly always a smaller patch than you'd guess. The disagreement is the decision; most of the rest is padding. (The quiet parts carry news too: they tell you the branches agree more than the argument in your head suggested.)

We think the two-way compare is the one you'll use most. It covers the everyday cases: one thread continued down two strategies, the same question handled by two models (Claude and GPT-5 arguing about your refactor, say), or a formal draft against a casual one.

It's also a quick sanity check on model choice. If you're wondering whether a premium model earns its extra credits on your kind of work, continue the same thread both ways and diff the results; the answer usually shows up within one screen.

Comparing Explore variants

The second kind of comparison belongs to Explore mode. When you send one prompt as several side-by-side variants, "Compare explore variants" puts the variant panes on a single board, because judging five sibling answers to one prompt is a different job than diffing two histories that split and grew apart.

That distinction is worth keeping. Variants are siblings born from the same prompt; branches are paths that diverged. Explore has its own article. And when you're past comparing and need to synthesize several branches into one output, that's the Merge Board, not compare.

What compare won't do

Compare doesn't pick the winner. That's a stance, not a gap: GPTree is built to support judgment, not replace it. The diff shows precisely where two answers part ways, and what to keep, merge, or continue from stays your call. (If you do want a model to make the call, Explore's Judge does exactly that for variants, with per-variant scores and a written rationale.)

One plan note, stated plainly: side-by-side compare is a Pro and Team feature. On the Free plan you can grow all the branches you want, but you can't put them next to each other.

Comparing tells you which content should win. Moving that content back into the thread where it belongs is merging, and that's the next article.