Arbor

You will notice this one in the first ten minutes, because it is native. Built in Rust on GPUI, it does not carry a browser around with it, and on a laptop with four repositories open that is the difference between a tool you leave running and one you quit. The deciding trait is that it feels like an application.

It is the wrong pick if you want somebody else to host and operate it, because this runs on your hardware. Pick it if you work locally and care about responsiveness. Pick AgentsMesh if the work has to live somewhere central.

One daemon carries everything. The desktop app, the web interface and the command line all read the same background process, which is elegant until it stops. Nothing in the row describes what happens to an in-flight session when that process dies, whether state survives a restart, or how a client behaves while it is gone.

The compensating design is real. Because there is one process rather than four, the surfaces cannot disagree about what a session is doing, which removes the class of bug where two views show different truths. That property is worth the risk it creates.

1. The unit of work is an issue, and a working tree is created for it, which means context is scoped by the thing being fixed rather than by whichever files were open. That is a principled choice: the boundary of the task and the boundary of the checkout coincide. 2. Diffs and pull-request context sit in the same view as the terminal that produced them.

2. Verification therefore happens where the work happened, without an export step, which removes the most common place for a reviewer to lose the thread. No benchmark is published, and none is claimed, so nothing here invites comparison to a leaderboard.

809 stars, a personal namespace, and a documentation site on GitHub Pages. There is no company here, which means there is nothing to fund and nothing to fail, and also nobody to answer the phone. The asset is craft, and craft attracts contributors more reliably than it attracts revenue.

Moat: none in the commercial sense, though polished tooling is harder to clone than a dashboard. Likely path: a maintainer-led project that either finds a sponsor or plateaus. Likely acquirer: an editor vendor buying the person rather than the code. Position: use it, and watch the commit cadence.

Zero per seat across sixty desks, and an application that installs on macOS, Linux and Windows, which is unusual enough to note because it means no group gets excluded. What it does not have is an administrative surface: no SSO, no SCIM, no audit log, no central configuration.

It does not run in CI, so it never becomes a measured step in delivery and the throughput claim stays anecdotal. Onboarding is short for anyone who already uses worktrees and longer for the rest. Approved with conditions: managed installation, and model keys issued by us rather than typed by developers.

MIT, brew install, and MCP in both directions, which is the combination I keep asking for. It consumes my servers and exposes one of its own, so the thing managing my worktrees is itself addressable by another agent. Ollama is among the providers, so the model can be one running on my box.

Nothing here needs a runtime installed beside it, which is the other half of ownership. If the maintainer walks away the licence lets me carry it, and the code is small enough that carrying it is not a fantasy.