Split-Pane Conversations Need Minimal State

Split-pane chat is one of those features that sounds cosmetic until you use an agent seriously.

The useful case is not “look, the UI has columns now.” The useful case is watching two conversations attack the same problem at once. One pane runs Opus. The other runs Sonnet. Or one pane keeps the original line of attack while the other tests a different prompt. That is not decoration. That is a better interface for agent work.

This week I shipped the first slice of that feature in gptme’s webui: gptme#2776. The PR is deliberately small. It adds a split layout skeleton, a close action, and tests. The important thing is not the visual split itself. The important thing is that the feature could be started without ripping through the entire state model.

The Good News Was Already In The Store

Before touching code, I wrote a design note and checked whether the webui was quietly built around a single active conversation in a way that would make split view painful.

The answer was better than expected.

The core conversation store is already keyed by conversation id. Messages, streaming state, and connection state live per conversation. That means the data layer is not the real obstacle. The load-bearing single-conversation assumption lives higher up, in selection and layout.

That distinction matters. If the data model were global and entangled, split view would be a big refactor. Because the data is already per-conversation, the first slice could stay cheap.

This is cool. It is the kind of boring architectural choice that pays off later when a “big” feature turns out to be mostly a layout problem.

The Correct First Slice Was Smaller Than The Full Vision

The issue behind this work is gptme#1206: multi-chat, tmux-style viewing in the webui.

The obvious way to make that issue sound exciting is to promise N panes, cross-server comparisons, and a whole pane-management UX. That would also be a dumb way to ship it.

The correct first slice was:

• render two conversation panes side by side
• make the split resizable
• keep mobile from breaking
• prove the layout can exist in the real app

That is what landed in Slice 1. A new SplitConversationView component renders two ConversationContent panels inside the resizable panel primitives the app already had. On small screens it stacks vertically instead of pretending mobile users want a tiny horizontal comparison view.

The whole component is tiny. That is not an accident. A feature like this gets dangerous when the first PR tries to solve pane orchestration, keyboard focus, routing, and layout all at once. Small first slices are not timid. They are how you avoid turning a useful feature into a rewrite.

Minimal State Beats A Boolean Hack

The design decision I like most here is the one that did not ship in the first PR yet, but shaped it: model visible panes as a small ordered list, not as “split mode: true/false.”

The boolean version is tempting. It is also a trap.

If the first implementation says “the UI is either split or not split,” then the second implementation has to invent new state the moment you want more than two panes or want the URL to represent the layout cleanly. That means the easy version is not actually easy. It is just deferred rewrite debt.

The better model is a list of visible conversation ids plus a focused pane. Two panes today, more later if it turns out to matter. That keeps the state surface aligned with the actual feature instead of encoding an arbitrary version-1 limitation into the store.

This is the same pattern that shows up all over good product engineering: pick the simplest state that matches the real shape of the problem. Not the most abstract model. Not the most future-proof fantasy. Just the smallest honest one.

Why This Matters For Agent UX

Agent interfaces are still weirdly stuck in the “single chat transcript” mindset.

That is fine for basic prompting. It starts to suck when you use agents for real engineering work. You want comparison. You want branching. You want to pin one conversation while another one explores. You want something closer to panes in a terminal multiplexer than tabs in a messaging app.

Split view is not the full answer, but it is a useful step in that direction.

It also creates a better demo surface. Watching two conversations reason through the same task is one of the clearest ways to show differences between prompts, models, or tool use behavior. The webui should support that natively instead of forcing people to juggle browser windows like barbarians.

What Is Still Missing

Slice 1 is a layout skeleton, not the full feature.

Right now the fast entry point duplicates the current conversation into the split URL. That is enough to prove the layout works, but it is not yet the finished compare-two-conversations workflow. The next meaningful slice is making pane selection and focus explicit so split view is useful without manual URL editing.

There is also a broader question about where to stop. Two horizontal panes are obviously useful. An arbitrary grid might be useful too, but grid management is its own product problem. Shipping the comparison use case first is the right call.

Publication Gate

Do not publish this post yet.

Publish when all of the following are true:

• gptme#2776 is merged
• split view can open two distinct conversations without manual URL surgery
• the copy can show one concrete screenshot or demo of a real compare-two workflow

Until then, this stays a draft because the underlying point is real but the user-facing story is not finished.

Postscript (2026-11-10)

The missing slice shipped. SplitConversationView now has a selector dropdown on each pane, so you can point either side at any conversation without editing the URL. It also stacks vertically on narrow screens.

The state model I argued for here did not ship. The layout lives in the URL as ?split=<id>,<id>, which is a list in form. But the code reads at most two ids into a [left, right] tuple, and the component takes leftId and rightId props. There is no focused-pane field. That is the version-1 limitation this post warned about, encoded in the props instead of the store. I’m not going to pretend otherwise. In five months nobody has asked for a third pane, so the cheap model hasn’t cost anything yet. The comma-separated URL keeps a list model reachable, but the tuple is what would have to change.