Why I Built perchd for the Agentic Era

Agentic coding gave me eight branches at once. It couldn't give me a second pair of eyes. So I built the tool for that, and left out the feature everyone expected.

You don’t write one branch at a time anymore.

You open six git worktrees, point a coding agent at each one, Claude Code here, Cursor there, Codex on the risky spike, and they all start typing at once. Six agents, six branches, real progress on all of them while you drink your coffee.

Then you want to actually look at one.

And that’s where it falls apart. The auth agent’s Next.js app wants port 3000. So does the one on main. The Vite spike wants 5173, the Python service wants 8000, and you’ve forgotten which worktree runs which command. So you cd into a directory, guess at whether it’s npm run dev or make dev, kill whatever was already holding the port, wait, start the new one, and squint at the URL. Then two minutes later you want to see a different branch and you do the whole dance again.

I did that dance about forty times a day. I started calling it port roulette.

Here’s the thing about port roulette: the entire industry has decided the solution is to run more servers, more smoothly.

Everyone’s answer is to scale up

Go read the guides on parallel AI agents right now. Every one of them hits the same wall, two agents both want port 3000, and every one of them solves it the same way: give each worktree its own port. Hash the branch name into 3001, 3002, 3003. Drop a .env.local in each tree to override the port. Stand up a reverse proxy so auth.localhost and payments.localhost both resolve. Some tools will spin up all eight dev servers at once and hand you a dashboard.

It’s clever. It works. And I think it’s solving the wrong problem.

Because when you scale up to eight running servers, you’ve quietly assumed the bottleneck is the servers. That if only they could all run at once without colliding, you’d be unblocked.

But that was never the bottleneck. I can start eight servers. What I can’t do is look at eight servers.

Agent concurrency is not preview concurrency

This is the line the whole thing turns on. Agents are cheap and parallel. I can run eight. I could run twenty. My attention is neither.

I have one pair of eyes and one working memory. When I review what an agent built, I load that one context into my head, the auth flow, what it was supposed to do, what looks off, and I follow it. I cannot hold two of those at once, let alone eight. The dashboard with eight live previews isn’t eight times more useful. Seven of those panes are burning CPU on my machine to show me something I’m not looking at.

So the port collision was never really the problem. It was a symptom of pointing the tooling at the wrong number. Eight is the agent count. The number that matters for review is one.

So I built perchd

perchd is a small command-line tool. I published it to npm a couple of weeks ago. The whole idea fits in one sentence: it keeps exactly one dev server alive, the worktree you’re actually looking at, and makes switching which one that is a single command.

You run perchd, pick a branch from a list, and it stops whatever was running, waits for that port to actually free up, figures out how the branch you picked wants to be started, Next, Vite, FastAPI, a Makefile, whatever, and brings it up on its native port. No cd. No remembering the command. Then perchd dev feature/auth is a drop-in for npm run dev that works on any branch, always on the same port.

The reason it can always use the native port, always localhost:3000, is the single-active rule. Only one server runs, so nothing ever collides. No hashing. No proxy. No .env rewriting. Your bookmarks never move. That one constraint, one server at a time, is what pays for all of it.

The feature I refused to build

The most requested feature is the one I keep saying no to. Run them all at once. Add the proxy. Give me the eight-pane dashboard.

I built the tool specifically to not do that.

It would have been more work and a worse product. The moment you allow eight simultaneous servers, you’re back to allocating ports, rewriting environments, running a background daemon to supervise it all, and reasoning about which of eight processes leaked which child. perchd has none of that. There’s no daemon. It does its bookkeeping lazily the next time you run it. When it stops a server it signals the whole process group, so Turbopack and esbuild children die with their parent instead of orphaning on a port. All of that stayed simple because I refused the feature that would have made it complex.

Saying no wasn’t the compromise. It was the design.

The part that isn’t about a dev tool

You can forget perchd exists and still keep this: it is very easy to build for the constraint that looks impressive instead of the one that’s actually binding.

Eight running servers looks impressive. A proxy with named subdomains looks impressive. More is the direction everything pulls, more agents, more parallelism, more throughput. And the whole time, the thing that’s actually rate-limiting the work sits quietly off to the side, unglamorous and unscaled. In the agentic era that thing is your judgment, your attention, the human review loop that every agent’s output still has to pass through. You can’t buy more of it, and no amount of infrastructure makes it faster.

I’m not claiming I got this perfectly right. Maybe in a year the review loop gets agents of its own and single-active looks quaint. But right now, sizing the tool to my eyes instead of my agent count is the best call I’ve made in months of working this way.

So the question I’d leave you with isn’t about dev servers.

What are you scaling up because it looks like progress, when the real bottleneck is somewhere you haven’t looked?