Dirac

The deciding trait is that it does not stop. You hand it an objective and it keeps generating and sequencing its own work toward that objective, pausing when it needs you rather than when the turn ends. You can also talk to it mid-run without killing the session, which is what makes a long run survivable.

Whether you want any of that depends entirely on how well specified the objective was. A vague goal running for six hours produces six hours of confident wrong work. Pick it if you can write the objective properly. Pick Aider if you would rather see each edit before it lands.

The dealbreaker is duration without containment. Nothing runs the agent inside an image with its own filesystem, so a multi-day objective executes shell commands directly against the machine holding your credentials, your other checkouts and your browser profile. Configurable permissions help. They are a policy, not a wall.

The second problem follows from the first: the longer a run goes, the less anyone recalls what they authorised at the beginning. What it does right is the worktree. Work can be confined to its own branch with documented integration and cleanup, which contains the damage to the repository even when nothing contains the process.

1. This is the correct fix for a well-documented failure. An agent addressing a file by line offsets corrupts it whenever the file has moved since it was read, and the corruption is silent, which is the worst property a bug can have. Hashing the anchor converts it into a rejected operation, and a rejection is something a caller can handle.

2. Syntax-tree inspection sits beside it, so structural questions are answered by a parse rather than a regular expression. 3. Neither choice arrives with a measurement, and no benchmark of any kind is published here. Defensible from first principles, which is the weakest available form of evidence.

The interesting number is the age. Something this young carrying this much stated ambition sits in the phase where the roadmap is whatever the authors find interesting, and that phase ends the day somebody has to charge for something. Nothing published suggests the answer has been decided yet.

Moat: none so far, and the obvious candidate is a control plane nobody has built. Pricing power: untested. Likely path is a paid cloud tier bolted onto a free client, or a quiet acquihire by a larger vendor that wants the team more than the code. Position: use it, do not standardise on it, revisit when a price appears.

The utility model is the line that got my attention. Compaction, handoffs and first-pass permission decisions run on a cheaper model than the one doing the work, which is an answer to the meter designed on purpose rather than discovered later. Multiply an all-day session by sixty engineers and that split is the gap between a budget and a surprise.

Everything else is absent. No identity integration, no usage record, no central policy, and nothing that becomes a step in delivery, so I can neither control it nor report on it. Not yet: it does not become a standard here until somebody can tell me who ran what.

The tool-building command is the part I have not seen anywhere else. Instead of shipping a plugin API and a manual, it compiles, validates and smoke-tests a new typed tool while the session is still open, which turns extending the thing into a conversation rather than a pull request. I am suspicious of that and I want it regardless.

The licence is permissive and the endpoint field accepts anything speaking the common API format, so the weights stay mine. What is absent is protocol support: it does not speak MCP, so every server I already run stays unreachable and every tool has to be built inside this one instead.