Pane

The deciding trait is that a pane is a worktree. You open one per feature, git creates the branch and the checkout for you, and deleting the pane takes the worktree with it, so the usual mess of half-abandoned branches never accumulates. If you have three agents going at once, that housekeeping is most of what makes it survivable.

You are still paying for whichever CLIs you run inside it, and this adds nothing to what they can do. Pick it if you run agents in parallel and lose track of the branches. Pick a single terminal and one agent if you do not.

Worktrees isolate files and nothing else. Several agents running at once against the same project still share one machine, one port range, one package cache and one set of build outputs, and the row documents no container around any of them. Two panes running a dev server is the first collision, and it is not the interesting one.

The honest part is that it says what it is: a terminal manager for agents that already exist, with no claim to sandboxing them. What it does right is the diff viewer sitting next to the agent, so reviewing what a pane did is one tab away rather than another tool.

1. The integration contract is the terminal itself: any agent that runs in one runs here, with no adapter per vendor and no capability negotiation. That is a deliberate lowest common denominator, and it is why the supported list is open-ended rather than a table someone has to maintain. 2. The cost of that choice is symmetrical. Nothing inside a pane can be inspected structurally, because the interface is a stream of characters.

2. No evaluation exists and none is owed. The claim is compatibility, and compatibility is demonstrated by the absence of an integration step.

A solo repository with 442 stars and no paid surface: the maker is buying distribution first and has not yet said what comes after. That is a defensible sequence in developer tools, and it only works if the second step arrives while anyone is still watching.

Moat: workflow habit, which is weaker than it sounds because the thing underneath is git and git is portable. Likely path: a paid hosted variant, or a slow fade as the vendors ship their own multi-session views. Likely acquirer: a coding-agent vendor that wants a desktop shell. Position: adopt the workflow, not the dependency.

Remote Pane is the part that decides this. The workspace runs on a machine we host and engineers drive it from a desktop app or a phone browser, which means source code reachable from a handset over whatever network it is on. That is a conversation with security before it is a conversation with finance.

Licence cost is zero across sixty seats and the real cost is the CLIs inside it, which we already pay for. There is no directory integration, no audit trail and nothing that runs in a pipeline. Approved with conditions: the remote host on our own network only, and no phone access outside it.

AGPL-3.0, and the decision I respect most is the one they did not make: MCP is deliberately not re-integrated. The agents inside a pane keep their own server connections, so there is no second config file and nothing here to get out of sync with what I already configured. Refusing to wrap something is rarer than wrapping it well.

Because it runs whatever terminal agent I point it at, a locally served model is a question for that agent's config and not this one. Install is a shell script or an npx invocation, both of which I can read before running.