[Feature]: Split and tile view modes, with a toggle, for supervising many agents at once

[clark-mackey]

Area

apps/desktop

Problem or use case

I use T3 Code as a control panel for multi-agent work: many short-lived threads running in parallel across worktrees, each opened, supervised, and closed within a day. For that workflow the one-thread-at-a-time main view is the bottleneck. I can run several threads in the background, but I can only watch one, so I end up switching in the sidebar to check on the others.

This builds on the existing split-view request, #6746 (#6746), which asks for viewing multiple chats side by side. Tabs for threads are requested in #17878. This request adds a second view mode, a tile view for supervising many agents, plus a way to switch between the views.

Proposed solution

Two view modes for the thread area, with a toggle to switch between them:

1. Split view. Two or more threads side by side in resizable panes, like the split screen in recent Claude Code. Good for a few related threads (plan, implement, review) that you read closely.
2. Tile view. A grid of live thread tiles, like herdr. Each tile shows the thread's status, latest output, and any pending approval or question. Good for supervising many agents at a glance and jumping into the one that needs attention.
3. Toggle. A control and keybinding to switch between the current single-thread view, split view, and tile view without losing which threads are open.

The terminal already supports split panes and drag-to-resize, so some of that layout work may be reusable for threads.

Why this fits how T3 Code is used

These views don't conflict with the philosophy of closing worktrees and threads. They are for the opposite case from long-lived sessions on a few main projects: many short-lived threads that you open, supervise, and close. Closing a thread would simply remove its pane or tile.

Alternatives considered

• Terminal splits running claude, opencode, or codex CLIs. This works, but the sessions live outside T3 Code's threads, so they lose provider selection, history, and PR linking.
• Switching threads with thread.next and thread.previous. This still shows only one thread at a time.
• Running herdr next to T3 Code. It works, but then T3 Code isn't the control panel.

The screenshots under Proposed solution show the two reference layouts: the split view (three threads side by side, from the Claude desktop app) and the tile view (six live agent sessions in a grid, from herdr). Pane contents are blurred for privacy.

[BonJenn]

I built a working version of this in a fork and would like to contribute it if the direction fits. Up to six threads in an auto grid (1–3 across, then 2x2, then 3 across), opened from a sidebar context menu or by drag-and-drop. The focused pane drives the route and sidebar highlight, and single-pane behavior is unchanged. It also has draggable dividers with snapping, drag-to-swap, and persisted layout. It stays single-pane below the md breakpoint.

It's not tested in the Electron app beyond a quick launch, nor on mobile. Would maintainers be open to this? If so, I'd split it into smaller PRs (layout/state first, then resizing, then swapping) and attach screenshots. Code: https://github.com/BonJenn/t3code/tree/feat/split-panes

[lgarbayo]

+1, and one more use case that I think makes this a natural fit: comparing models side by side.

T3 Code already lets you Shift-click several models in a new thread's model picker and send the same prompt to all of them, each in its own thread and worktree. But there's no way to actually compare the results, because you can only look at one thread at a time and have to switch back and forth in the sidebar. A split view would close that loop: send to Claude + Codex (or two Claude accounts), then read both answers next to each other.

The same applies to multiple provider instances: I run two Claude accounts (work and personal) as separate instances, and being able to keep one thread from each on screen would help.

Current workaround on Linux (Manjaro/GNOME): desktop app in one half of the screen, the web UI (t3) in a browser window in the other half. It works, but it means two clients, two windows to manage, and no shared focus/keybindings.

@BonJenn's fork looks like exactly what I'd want — happy to test it on Linux desktop if that helps move it forward.