Claude Code is a terminal program, and the terminal is the right place for one agent and the wrong place for four. A survey of the GUI front ends people move to, what each adds over a plain terminal, what a canvas gives you that a tab list does not, and the cases where the terminal is still better.
the short version
Claude Code has no official GUI: it is a terminal program, and the front ends people use instead are of four kinds. A multiplexer config, an editor panel, a list or board of sessions, or a canvas where sessions are objects in space. The terminal is the right place for one agent and stops being the right place somewhere around the third or fourth, which is the only reason any of the others exist.
Below: what specifically breaks between one agent and four, the four categories and what each is for, and what a canvas costs. Every fact about a named tool comes from our comparison page, which carries the date it was checked and says "not documented" where a thing could not be confirmed.
the terminal is genuinely good, and that is not a concession
Start here, because a post that skips this part is selling something. Claude Code being a terminal program is a design decision and it is a good one.
A TTY program composes with everything you already have. You can pipe into it and pipe out of it. You can run it over ssh on a box with no display attached, which is not a rare case: plenty of real work happens on a remote machine because that is where the data or the production-shaped environment lives. You can put it under tmux and detach, close the laptop, and pick the session up from a different room. It inherits your shell, so it inherits your aliases, your environment, your ssh agent, your keys and your proxy settings. A GUI has to reimplement or import all of that, and most of them do it badly.
It is also cheap. A terminal pane is a pty and some bytes. It does not carry a browser engine around and it starts in the time it takes to fork. If you are the sort of person who notices that an editor is using more memory than the compiler, that difference is not aesthetic, it is the reason you picked the tools you picked.
And for one agent it is close to ideal. There is one thing happening, it is happening in front of you, and the whole state of the world is the visible scrollback. You do not need a dashboard to tell you what your single agent is doing. You are looking at it.
what actually breaks between one agent and four
None of the multi-agent failure mode is about performance. Four Claude Code processes are not slow, they are four processes. What degrades is your ability to know what is going on, and it degrades in specific ways.
You cannot see who is blocked
This is the one people underestimate until they have lost an afternoon to it. An agent that has finished, an agent deep in a long tool call, and an agent sitting on a permission prompt for eleven minutes look almost identical from outside. The only way to tell them apart is to go and look at each in turn, and that polling loop is a cost you pay every few minutes for as long as the fleet is running.
The maths is unkind. Time lost to an agent sitting blocked and unnoticed grows with both the number of agents and the length of your polling interval, and the interval grows because checking four panes is annoying. The exact moment parallelism should be paying off is the moment you stop looking.
Scrollback is the only history, and it scrolls
In a terminal, the record of what an agent did is the text above the cursor. It has a length limit, it is gone if the pane dies, and it is interleaved with build output and test noise. "What did the migration agent decide about the nullable column, an hour ago?" is a question with no good answer. You scroll, or you re-ask the agent and hope its context still holds it.
Spatial memory is doing all the work of a UI
Watch anyone running several agents in panes and listen to how they talk about them. "The one in the bottom left is the migration." That sentence is a user interface. Position is the only label those sessions have, and it is being held in a human head.
It works up to a point, and the point is small. Four panes on one screen is fine. The moment you go to tabs, the spatial memory is destroyed, because a tab has no position: it has an ordinal, and ordinals shift when you close one. This is why people who run agents in tmux end up with a layout they refuse to change, and why the layout stops being about the work and starts being about not losing track.
There is no combined figure for anything, especially spend
One agent in a terminal gives you no running total. Four agents give you four times no running total. Burn rate is exactly the variable a person watching four panes cannot estimate, because it is the product of four things they are not measuring. We wrote separately about why the arithmetic is harder than it looks; the multi-agent version is simpler and worse, in that you have no number at all.
Everything is four times
Spawning four agents in four worktrees is four sets of the same commands. Four git worktree add invocations, four directory changes, four launches, four times remembering which branch you called what. None of it is hard and all of it is friction, and friction is what stops people doing the isolation step at all, which is how two agents end up editing the same file in one directory. Our walkthrough of running Claude Code, Codex and Grok together spells out the whole sequence, and the length of it is the point.
the four shapes of front end people move to
These are categories, not a ranked list, and the right one depends entirely on the shape of your work rather than on which is most sophisticated. Named tools below are described from our comparison page only, with its qualifications carried over intact.
1. A terminal multiplexer with a config
tmux, or your terminal emulator's own panes, plus a script that lays the session out the way you want it. This is not a GUI and should not pretend to be, but it is the honest baseline the others have to beat, and plenty of people never leave it. Durable sessions, no cost, works over ssh, and a config file is the only thing to maintain.
What it does not give you is any of the four things above. It arranges panes. It does not know that one of them is waiting on you. Claude Squad sits at the sophisticated end of this category: a terminal program that manages several agents at once in isolated worktrees, without leaving the terminal. It is free, AGPL-3.0, and runs over SSH on a machine with no display at all, which for a lot of people is the entire requirement and the reason a desktop app is a downgrade. Its spend metering is not documented.
2. Editor-embedded panels
Claude Code ships extensions for VS Code and JetBrains, which put the agent in a panel beside the code it is editing. This is the right answer for a specific and very common case: one agent, working on the thing you are also working on, where you want its diffs to land in the editor you are already reading them in.
It is not an orchestration answer, and the reason is structural. An editor window is organised around a file tree and the panel is a side car on it, so three agents doing unrelated work in separate worktrees do not fit: the editor wants one project open and the agents want several. Editor panels are for the agent that works alongside your editing, not the fleet that works while you do something else.
3. List and board front ends
The most common desktop shape. Each agent session is a row in a list or a card on a board, you click one to see its terminal and its diff, and the tool creates isolation for you when the session starts.
Conductor is a macOS app that runs several coding agents in parallel, each in its own git-worktree-backed workspace with its own branch, terminal and diff. It drives Claude Code, Codex, Cursor and OpenCode, it is free for local parallel agents, and its spend metering is not documented. Vibe Kanban is the board version: a kanban board for planning work and dispatching it to coding agents, each task in its own isolated workspace with a branch, a terminal and a dev server. It is Apache-2.0, it runs anywhere Node runs, and it drives more agent CLIs than anything else we compared. It is also unmaintained, which is worth knowing before you spend an evening on it. It is still worth naming because a backlog you groom and dispatch from is a better model for queued work than a canvas of live terminals, if your work arrives as tickets.
Crystal is a desktop app for running several Claude Code and Codex sessions at once in parallel git worktrees, built for trying an approach more than one way and comparing the results. It is MIT, it runs on Intel Macs and on Linux, and it has been discontinued in favour of Nimbalyst, its successor: a visual workspace holding markdown, diagrams, mockups and a browser preview beside a kanban of agent sessions, free, MIT, and on all three desktop platforms. Sculptor isolates differently, running parallel Claude Code agents in Docker containers with a full copy of the repository each, and syncing whichever agent you are watching into your own editor live. Containers are stronger isolation than worktrees, which is a real answer to a real fear. Its spend metering is not documented either.
The list shape buys you somewhere for blocked sessions to be marked, which is the biggest problem in the previous section solved. It costs you that a list shows one session at a time, and the relationship between sessions, which one depends on which, has nowhere to live.
4. Canvas front ends
Sessions become objects positioned in two dimensions, and the layout itself is state that persists. Nimbalyst is the closest thing on our comparison page to this: a visual workspace where sessions sit alongside documents and diagrams. Skribbl, ours, is the other, and it is the section below.
what a canvas buys, and what it costs
Three things, and they are narrow enough to be worth stating precisely rather than selling.
Position is memory. The spatial reasoning you were already doing in your head, "the one in the bottom left is the migration", becomes a property of the document instead of a property of you. It survives a restart and it does not shift when you close a neighbour. That is the failure mode from the previous section, fixed by giving the layout somewhere to live.
One glance shows you who is blocked. With every session on one plane, an agent waiting on a permission prompt can be marked where you will see it without navigating to it. The polling loop goes away, and that is worth more than anything else on this list.
Drawn connections are visible authority. If a line between two agents is what permits one to command the other, the diagram of your setup and the permission model are the same object rather than two things that drift apart over a week. You revoke by erasing. There is no permissions screen to audit, because the board is the permissions screen.
Now the costs, which are real. It is another window: a desktop app to install, keep open and alt-tab to, on top of the editor and terminal you already have. Ours is macOS only and Apple Silicon only, which rules out a real number of people immediately. It is not free, and several of the tools above are, which is the sharpest argument against it. And if you run one agent at a time, a canvas buys you nothing. Every benefit here begins at the third or fourth concurrent session; below that you are paying for a solution to a problem you do not have.
when to stay in the terminal
There are cases where the answer to "which Claude Code GUI should I use" is "none", and they are common enough to list plainly.
Remote boxes. If the work happens on a machine you reach over ssh, a desktop app on your laptop is not in the right place. A terminal program is, and so is anything built on one. This is not a limitation that gets designed away, it is what "desktop app" means.
One agent. Said three times in this post because it is the most common honest answer. One session is fully visible in the pane you are looking at. There is nothing for a UI to add.
CI, and anything scripted. An agent invoked from a pipeline, a git hook or a cron job needs to be a process with an exit code, not a window. Scriptability is the thing a GUI is worst at and a CLI is best at, and it is why the CLI will stay the primary interface however good the front ends get.
Constrained or unfamiliar machines. A shared box, a container, a colleague's laptop for twenty minutes. Installing a desktop app to run one agent is a poor trade.
ours, and what it does not do
Skribbl is ours, so treat this section as what it is. It is a macOS desktop app that puts real terminals on an infinite canvas. Each agent is a node running a real shell, so anything you can do in a terminal still works. Sessions survive restarts. You can spawn a group of agents in one action, each in its own git worktree. Authority is drawn: a line from one agent to another is what lets the first command the second, and erasing it revokes that. A meter in the top bar shows combined spend while the agents are running.
What it does not do, and this list is longer than the one above. It is not an editor: no completions, no inline edit, no language server, no extensions. It ships no model and no subscription, so it is a cost on top of whatever you already pay. It is macOS on Apple Silicon only, one build, so Intel Macs, Windows and Linux are all excluded. It is closed source, so you are taking our word for what it does to your repository, where several tools above are MIT or Apache-2.0 and readable. It is local only, with no answer to cloud workspaces, multiplayer, or agents that keep running when the laptop shuts. The spend meter reads Claude Code today and not the other agents it can run. And it does not decide your decomposition for you: which agents exist, and what each is working on, is still your problem.
If you want parallel agents and you want it to cost nothing, our comparison page names the tools that are free and says where each beats us, in more detail than this post has room for, with the date it was checked attached to every claim.