One terminal is not enough anymore

A year ago, a coding agent was something you watched. You typed a request, followed every step, and stepped in when it went sideways. One terminal was plenty, because one agent was all you could supervise.

That has changed. Agents now finish real tasks on their own: they fix bugs with a failing test, refactor modules a type checker can verify, update documentation, chase down flaky CI. And the moment an agent can finish without you, the obvious question is: why only one?

#The tab problem

Most people answer that question with more terminal tabs. Claude Code in one, Codex in another, a third for the docs. It works for about an hour. Then the problems arrive:

• Collisions. Two agents edit the same file in the same working copy. One overwrites the other, or both produce a diff that neither understands.
• Blind spots. One agent has been waiting for an approval for twenty minutes, buried in a background tab.
• No way back. An agent renames forty files you didn’t ask it to touch. Your last commit was an hour ago.
• Silent spending. A loop runs all afternoon and you find out from the bill.
• No evidence. An agent says the tests pass. Did they? Which ones? Before or after it edited them?

None of this is the agent’s fault. It is missing infrastructure.

#What a workspace for agents needs

PaneScale is our answer, and it rests on four ideas.

#1. Isolation by default

Every agent that changes code should work on its own branch in its own directory. Git has had the right tool for years — worktrees — but setting them up by hand for every task is friction nobody keeps up with. In PaneScale it is a toggle on the pane: Isolated worktree. Closing the pane asks whether to keep, merge or discard the lane.

#2. Evidence over claims

An agent’s summary is a claim. A test run is evidence. Wherever PaneScale reports a result — an autopilot report, a task run, a workflow run — the numbers come from commands it ran itself and recorded. When the autopilot marks a task ready, it is because the task passed your checks with no regressions, not because a model liked its explanation.

#3. Cheap mistakes

Mistakes are fine if they are cheap. Before an agent changes your workspace on your behalf, PaneScale takes a byte-exact checkpoint. Rewinding is one click — and it refuses to overwrite anything you changed by hand in the meantime.

#4. Limits that hold

A budget that only turns a number red is not a budget. PaneScale measures usage from the agents’ own event streams and stops runs that cross the daily limit you set. Loops are paused before they become expensive.

#What it is not

PaneScale is not another agent. It doesn’t replace Claude Code, Codex or Gemini CLI, and it doesn’t resell model access. Your subscriptions stay with their providers. PaneScale is the room the agents work in: the grid, the lanes, the checks and the guardrails.

It is also not a cloud service. Your code, chats and runs stay on your machine. Agents talk to their providers directly, the way they always did.

#Where to start

If you have never run two agents at once, start small: two panes, two lanes, two tasks that don’t touch the same files. Watch how often you need to step in — it is usually less than you expect. Then put a bug with a good test into the Overnight Autopilot, and let the checks decide.

The rest of this blog is about the details: how checks and baselines decide what is ready, why we never estimate tokens, how checkpoints avoid touching your branch, and what makes a task finishable overnight.