Stars measure nothing: eleven agent orchestrators, tested

I installed and ran all eleven tools myself, over July and August. Star counts, licences, releases and commit dates came from the GitHub API on 3 August 2026. Company and funding figures are from published reporting. Everything else came off a running screen, and where something is an impression instead of a measurement, I say so.

For as long as most of us have been writing software, the answer to "where do you work" was an IDE. Whatever the language, one window held the whole project.

Here is mine, with everything still in place.

The first versions were plugins. You kept the IDE you had and installed the assistant into it.

Then the editors themselves were rebuilt around the assistant. Cursor is a fork of VS Code, the same editor most of the industry had standardised on, with the model moved to the centre of it. Developers switched, which almost nothing had achieved against VS Code, and it reached $500 million in annual revenue faster than any software company before it. The lesson the market took was that the assistant, not the editor, was the product.

JetBrains reached the same conclusion and went further. In March it released Air, which it doesn't call an IDE at all. It is an Agentic Development Environment, built around the agent rather than around a text editor, with room for several agents side by side. It runs on the remains of Fleet, the editor JetBrains had killed three months earlier after deciding it could not beat VS Code.

Then the CLIs. LLM vendors ship their own command-line tools, and new capabilities land there first. A plugin wraps what the vendor exposes and updates on its own schedule, so it trails. Developers moved to the terminal.

As more of the day went into the terminal, people laid the window out to suit it. Mine ended up an even split: editor on one side, agent on the other.

Every step moved the same way: more time with the model, less with the IDE.

Then I ran into the limit of that layout. One terminal runs one conversation against one working copy. Once a model is good enough to work on two modules at once, the scarce thing is no longer the model. It is that I have one of everything. Starting a second task meant stashing changes, cloning the repository again, or waiting for the first to finish.

So I went looking for a tool that assumed the model does the work: several agents at once, each in its own git worktree, and the diffs somewhere I could read them. Beside it, something light to open the project in. On anything new the ambition runs further: hand a chain of agents a task and get a finished feature back.

The field, and where I stand

There is a community-maintained list of tools that claim to do this, awesome-agent-orchestrators. It held 153 repositories when I catalogued it, and the shape of those 153 is worth knowing before you take a recommendation from anyone, including me.

Seventy-three percent were created in 2026 and only three predate 2025, so the median repository is about five months old. Eleven percent are already stale or retired: fourteen have gone quiet, three are archived.

I installed and ran eleven of them: the ones I already used, plus the ones that came up often enough to be worth an hour. That is not a sample, and my work is almost all brownfield. If you build greenfield you may well rank them in the opposite order.

One disclosure before the findings. Nearly every published comparison of these tools was written by someone selling one. Nimbalyst ranks itself fourth, AgentsRoom opens with "full disclosure: this is us," and the most careful research in the field comes from the CEO of an orchestration company, who says so at the top of every page. I don't sell an orchestrator, nobody here funds me, and I paid nothing for any of the eleven, including the one with a paid tier, which I've run for months on its free plan.

Two designs

They look like different products: an IDE, a kanban board, a company, a control center. Run them and the names differ more than the products do. What separates them is how a task gets from the sentence you type to the pull request you open, and there are only two answers.

These are the sequences I run, not the ones the tools advertise.

Type 1. One task, one worktree.

1. Create a worktree in the tool.
2. Write the spec.
3. The agent returns a plan. Read it before anything runs.
4. Let it run to the end, without approving each edit.
5. Read the diff.
6. Open a pull request.
7. Delete the worktree.

Steps 2 to 4 happen inside the coding CLI and look the same as they do in a terminal: plan mode, auto mode, shift+tab to cycle. The tool supplies steps 1, 5 and 7, and lets you run several of these at once. It is the layout from the last screenshot, multiplied.

This fits a task small enough to specify in full before it starts. For a big feature, split it into smaller specs, run each in its own worktree off one feature branch, then merge them back yourself. Nothing I saw in these tools does that step for you.

Type 2. Configure the chain, hand over the task.

1. Configure the sequence of agents. Once, not per task.
2. Write the spec and the context the chain will need.
3. The chain plans, executes and verifies without you.
4. Build, test and lint run as gates. They must pass before the work advances.
5. Review the draft. Accept it, or send it back.
6. It loops until the result meets the spec.
7. Open a pull request.

You act at step 2 and step 5. The rest runs on its own.

Two things have to be true before you start. The spec has to be complete, because the chain cannot stop and ask you a question. And the feature has to be describable up front, without first going off to investigate existing dependencies or external services.

Get either wrong and you find out late, because an incomplete spec does not fail fast: the chain runs to the end and bills you for the whole of it. Ivy Tendril produced sixteen merged pull requests for about $56 and 600,000 tokens across the fourteen merged plans that carried cost data, $1.58 to $9.52 a plan, one execution at $10.98 on its own. That is the cheap end of Type 2, and Dorothy and Agent Teams both consume more.

Where a mistake is expensive, healthcare or finance or anything with an auditor, watch the volume rather than the defect rate. The gates check each change harder than any Type 1 diff review does. What they cannot tell you is whether the work should exist at all, and the Type 2 tool I rate highest kept generating more of it. Someone still has to be able to say why each change is in the codebase.

Ranked by GitHub stars

The eleven, one at a time

Type 1

Superset. My daily driver, and the reason the layout in those screenshots survived as long as it did. New task, new worktree, delete it through the UI when you're done. Nothing complex, very quick start. The free tier has everything I need, which matters because it is the only tool I found still charging for itself: $20 a month for team features I don't use. The team ships updates daily. The UI could use more work: a few bugs, occasional glitches. If you don't need anything sophisticated, this is the one.

Elastic License 2.0 since 4 February 2026, when it left Apache-2.0. macOS and Linux, though Linux downloads run about one percent of macOS.

Agent Orchestrator. Very close to Superset, with a slightly better UI, and a real dashboard for session state. One thing doesn't work: you can add a project or a whole workspace, but a session can only be created on a project, and once a workspace is added you can't reach the projects inside it. Good idea, counterintuitive implementation. Apache-2.0, free, all three platforms, still pre-1.0.

Parallel Code. Quite similar to Superset and Agent Orchestrator. Simple, convenient UI, good for daily use. Projects on the left, a task each, and it counts merges rather than tokens. MIT, free, macOS and Linux, maintained by one person who has also run Super Productivity since 2017.

Emdash. A clean, basic tool for working with AI across many projects. Good place to start. It invents almost no vocabulary and runs the coding agent's own interface instead of replacing it. Apache-2.0, YC W26, and created in August 2025, which makes it old for this field.

Synara. Perfect UI, awful UX. The best-looking tool here and among the hardest to operate. Beautiful icons that carry meaning they never establish, hints written in terms the product doesn't define, a weird default config. It does have workspaces that group projects, which is useful, and which Agent Orchestrator promises and can't deliver.

I'd still give it another go after a period of adjustment. MIT, v0.6.5, openly early.

Vibe Kanban. One of the most popular tools in the field, and its cloud half is now switched off. The basic features are more or less the same as Superset; everything else is disabled. Open a cloud project and you get an export button and a link to the shutdown announcement.

Bloop shut down on 10 April: "the vast majority are free users and we couldn't find a business model that we could get excited about." The post said the project would live on, community maintained. It hasn't. There have been no commits since 25 April. The last two are a version bump and a README sunset banner, against 27,633 stars and 535 open issues. A competitor's blog currently tells readers that community pull requests still land. They don't.

The software still runs locally. The product didn't stop; the company did.

Which is why I have been thinking about reviving it. Support costs far less here than in the United States, and a project that cannot carry an American maintainer can carry a Ukrainian one. Thousands of daily users and 27,000 stars were not enough for Bloop. For one person in Ukraine they might be. I have thought about it. I haven't done it.

Type 2

Ivy Tendril. The most promising of them. More advanced than Superset, less complicated than Dorothy, and the flow is clear: create a plan, it becomes a job, the job produces a draft, you check the draft, apply the changes it suggests, review once more, then open a pull request. It took almost no time to work out how it should go.

It's also the only tool that gates work by program rather than asking you to squint at a diff. Build, test and lint must pass before anything advances, and the checks turn green next to the button that opens the pull request.

Then there's Recommendations, which proposes improvements after every execution. It looks useful, and it is. That's the trouble. Accept one and it creates another draft, another review, and more recommendations. Recommendations on recommendations. A couple of tickets can turn into a pile of conflicting pull requests; two of mine were merged twice. Use it carefully, and check the plan before it runs.

Licensed FSL-1.1-ALv2, which does not permit competing products, under a launch post titled "Introducing Ivy Tendril: Open Source Coding Orchestration."

Dorothy. The most features of anything here, and I was impressed enough to fork it and write its Linux port, since upstream is macOS only. Then you meet the rest of it: thirteen top-level sections, a Super Agent that delegates to other agents, nine preconfigured role templates, five MCP servers, and a 34,000-byte README documenting all of it. It is overcomplicated, and using tools like this needs real training, which could be a show stopper.

I ran it with one agent on one task and still hit that wall. The machinery is on screen whether you use it or not.

Agent Teams. Overloaded UI, and you work with a team rather than a project, like running an agency. The team dashboard takes more room than the team chat, so following prompts and results is harder than it should be. Setup starts by creating a team of four suggested agents named lead, developer, reviewer and so on.

This is the same anthropocentric framing Dorothy uses for its role templates and Paperclip builds its entire product on, and I don't like any of it. Agents don't behave like people. The wrong name sets the wrong expectation about what they can and can't do, and that gets you wrong or unexpected results.

I do understand why it spread. For non-technical vibe coders, a team of named colleagues is far easier to picture than a chain of configured prompts, and it's the dominant metaphor online for exactly that reason. It is still wrong. Licensed AGPL-3.0.

Paperclip. The most advanced tool here, and the heaviest on tokens. It models an entire company. A Chief of Staff decides what kind of engineers you need, hires them, assigns the work and reports upward to a board.

This is the metaphor at its furthest, and it's where it loses me completely. You are not hiring anyone. You are deciding which specialised agent handles which step of a development pipeline, and dressing that up as recruitment is childish.

It is the most-starred tool I tried, and it got there fast: 30,000 stars in three weeks from a pseudonymous maintainer, 75,473 today. Its Hacker News submission got three points and no comments.

The one I couldn't run

Buzz, from Block. Plenty of innovative ideas in it. But the onboarding asks for a cryptographic identity key, then insists you join or create a community, and creating one opens a browser handoff that never comes back. I gave up after several attempts to wire the web and desktop halves together. Apache-2.0, publicly launched 21 July, and openly pre-release.

Why almost nobody can charge for this

I checked pricing pages for the fifty coding orchestrators in that list. Three ever charged for the tool itself, and two of those are dead: 1code was archived in March, Vibe Kanban's paid tier went with Bloop in April. Superset is the one left, and its free tier is enough for a single developer, which is who uses these tools.

The reason is structural. An orchestrator owns nothing expensive. You bring your own key, the model vendor bills you directly, and the tool is a window onto a process you are already paying for. There is real work in that window (worktrees, diffs, queues, review state), but none of it costs the vendor anything per token, and none of it is hard enough on its own to carry a subscription. The one tool still charging does it by selling team features to teams.

Bloop put the rest of it plainly: they could not find a business model they could get excited about. That phrase carries the weight. A venture-funded team needs a venture-scale outcome, and the same thousands of daily users that bored one owner would make a living for someone with a lower cost base. The asset isn't broken. The return threshold was.

What I would tell you to do

Type 2 fits greenfield. Type 1 fits brownfield.

The difference is context, not capability. On a new codebase you are the context: the structure is whatever you decide. On a legacy system the context is years of accumulated dependencies and integrations, and no plan prompt carries it, so the chain plans confidently against a model of your system that's wrong. A Type 1 tool that misreads your codebase wastes one prompt and you catch it. A Type 2 tool carries the misreading through every stage and bills you for each one.

So: brownfield, use Type 1. I use Superset daily; Parallel Code and Agent Orchestrator are close enough that I'd take either; Emdash is the easiest place to start. Greenfield, Type 2 gets interesting, and Ivy Tendril is the best built of them.

Judge these tools on licence and portability, not on how healthy the vendor looks. At eleven percent attrition in a five-month-old field, "will this exist next year" has no answer. "Can I keep using it after the company dies" has one today. Vibe Kanban is the proof that this is the question. And read the licence yourself, because Ivy Tendril calls FSL "open source" and Superset was described as Apache-2.0 twelve weeks after it stopped being Apache-2.0.

The editor comes back

The agents edit inside worktrees, and the diffs get reviewed in the orchestrator. What's left for a local editor is orientation: read the tree, open a few files, check a README. That's a viewer's job, and a full IDE is a heavy way to do it. You pay for indexing and startup to do work that needs neither.

The orchestrators assume this. Superset offers to jump out to VS Code, Cursor, Windsurf, JetBrains or Xcode.

So I use Zed instead. Written in Rust, faster than VS Code, less memory. That's an impression from use, not a benchmark.

Then I looked at what Zed shipped this year. Created in February 2021, four and a half years before almost anything in this field. 87,944 stars, more than any orchestrator I tested. It reached 1.0, raised $44.5 million, ships an open protocol so agents from Anthropic and OpenAI run natively, and now runs parallel agents on different parts of a codebase at once.

And it charges for the AI. The editor is free; the paid tier sells hosted models. Every orchestrator I tried passes your key straight to the vendor and takes nothing from it. In a gold rush the reliable money is in shovels, and Zed is the only one here selling them.