Sudo Code

The deciding trait is that it stays inline. It does not clear your screen, take over the terminal or draw a panel over your work; it prints into the scrollback you already have and it pipes into whatever comes next. If you live in tmux over ssh, that one decision is worth more than any feature list.

Nobody else in your team will care, and that is fine, because it is not aimed at them. Pick it if your terminal is your editor and you want an agent that behaves like a command. Pick a desktop tool if you want a window with buttons.

The headline ambition is scaling from one agent to a hundred, and the row describes no machinery for it. Roles, definitions of done and reviewers are things you write into a prompt, not things a runtime schedules, and nothing here mentions a queue, a supervisor or a way to stop the tenth agent when the ninth has already fixed the bug.

At one agent it is solid. At three the absence of git integration starts to matter, because every agent is editing the same checkout and there is nothing recording who touched what. Ambition is fine. This one is currently a document.

1. The tool prints the file and the line range it is reading rather than a summary of it, which makes the retrieval step auditable in the only way that counts: the reader can check what was actually in the window. Most agents report their intentions and conceal their inputs. 2. That choice costs screen space and buys reproducibility, which is the correct side of that trade for a research-minded user.

2. No benchmark accompanies any of this. The design claim is about interaction, and interaction claims are the ones nobody knows how to measure.

There is no revenue anywhere in this picture and no attempt at one: a small vendor, 395 stars, and a tool that deliberately serves the narrowest and most opinionated slice of the market. That slice does not buy software, which the maker presumably knows.

Moat: taste, which is real and unsellable. Likely path: it stays exactly what it is for as long as its author enjoys writing it, and that is a genuinely stable outcome for a tool with no infrastructure to pay for. Likely acquirer: none, because there is nothing to buy. Position: adopt freely, expect nothing, and you will not be disappointed.

This is a tool for my three strongest engineers and it will do nothing for the other fifty-seven. It is aimed at people who already work in a terminal all day, and the throughput gain for an average engineer, who does not, is close to zero. That is the whole procurement question and the licence being free does not change it.

There is no unattended mode, so it never becomes a step anyone can measure, and no console, no audit and no vendor. Onboarding a mid-level developer means teaching a way of working, not a tool. Approved with conditions: individuals who ask for it, and nobody else.

MIT, and it speaks ACP, which means another client can drive it and I am not locked into whichever front end the author prefers. Four providers are supported directly, so switching is a config change rather than a migration, and none of them is privileged in the design.

What is not here is a local endpoint or an MCP client, and those are the two boxes I would most like ticked. The install is a shell script I can read first, and the source is Rust I can build without a toolchain hunt. I would fork it to add a provider before I would file an issue about one.