Plandex

Plandex was built for the large multi-file change, the kind where a chat agent loses the thread halfway through, and its configurable autonomy lets you decide how far it goes before it asks. The trait that decides it is who runs it: you do, on your own machine, with your own keys, because nothing hosted remains, and the tool assumes you are comfortable being your own ops team.

Pick it if you enjoy self-hosting and have a refactor big enough to justify the setup. Pick OpenCode if you want a maintained terminal agent today, and Aider if what you actually want is careful diffs with less machinery around them.

Start with the install. The documented curl one-liner fetches from plandex.ai, and that domain no longer resolves, so a new user fails before the first prompt, and the README does not warn them. Everything after that depends on cloning the repository and building from source, which the reader of a one-liner was trying to avoid.

The consequence is that the documentation describes a product that no longer exists in the form described, and every other instruction inherits that doubt. What it does right: command execution comes with rollback, so a shell step the agent gets wrong can be unwound rather than repaired by hand.

Plandex separates proposal from application. 1. Edits accumulate in a sandbox as a cumulative diff rather than landing file by file. 2. The working tree changes only after the user reviews the accumulated change, so verification is a designed step rather than an improvised one. 3. The README claims a 2M token effective context window and describes no method for measuring it, so the claim is asserted, not documented.

The first two properties are the most principled edit-staging design among terminal agents and would survive any model change intact. The third would not survive a question. The observation: the best-designed part is the part with no number attached.

This is the open-source-as-marketing-plan story at its end. Plandex Cloud stopped accepting new users on 2025-10-03, so there is no revenue line and no pricing power, and the remaining asset is roughly 15,600 GitHub stars attached to a repository nobody is paid to maintain. Nobody acquires a self-hosted tool with no customers; they lift the idea and leave the code.

The natural home for the design is a larger open project that adopts it as a feature. Position: fork the idea, do not build a team on the product, and treat any revival announcement as unproven until a payroll is behind it.

The demo, a multi-file change staged for review, is careful work. Procurement: there is no vendor to contract with, so a platform engineer stands up the server and becomes its support line, sixty developers bring sixty keys, and there is no SSO, no audit log and no retention policy, and the headless path runs through that same server, so CI depends on it and nothing is logged centrally.

Onboarding is a wiki page the platform engineer writes and then maintains alone. Cost is the tokens plus that engineer's time, which is the expensive line. Not yet, and not later unless a maintained fork with a company behind it appears.

Local mode is git clone, cd plandex/app, ./start_local.sh, and a provider config pointing at Ollama or OpenRouter. MIT license, every prompt readable, and the only thing missing from my checklist is an MCP client, which it never had, so my tool servers stay on the shelf. Otherwise the design is mine to keep.

The catch is upkeep: a fork could survive, but right now I would be the one fixing it, and the vendor has already demonstrated what happens when nobody is. Grudging respect for the code; eyes open on the maintenance, which is the honest price of a tool with no company left behind it.