opcode

You will like the first hour. The deciding trait in daily use is retrieval: a project and session browser means the conversation where you worked out that migration is something you can find again, rather than something you scroll a terminal buffer hoping to see. The token dashboard answers the other daily question, which is where the month went.

Pick it only if that recall problem is genuinely costing you time. Pick Conductor for the same shape with someone still shipping, or stay in the command-line tool itself if you never lose track of a session.

The risk is drift. Everything this presents comes from a rapidly moving external program, and an interface layer that has not moved since late 2025 accumulates mismatches with every upstream release. Nothing on the row promises a supported interface between the two. The failure mode is not a crash; it is a panel that quietly stops reflecting what the underlying tool is doing, which is worse in a product whose entire job is visibility.

What it does right: agents are defined with their own file and network permission settings, so capability is scoped per agent rather than granted once to everything.

Two observations. 1. Versioning is applied at the conversation layer rather than the repository layer, so a checkpoint restores the session's state and makes no claim about the working tree. That distinction is stated rather than blurred, which is more precision than most wrappers offer, and it means the mental model a user forms is the correct one. 2. Session history is browsable as data, so past runs are inspectable after the fact.

No evaluation is published. The design's durability depends entirely on the stability of an interface it does not own, which is the structural weakness of every wrapper.

Two ownership signals in one row. The product carried a different name until a version bump renamed it, and the repository subsequently moved to another organisation. Renames cost accumulated search traffic and moves usually mean the original steward stepped back, so together they read as a project being handed on rather than built up. No tier, no hosted service, no revenue path attached to a copyleft desktop wrapper.

There is no acquirer for this; the vendor whose tool it wraps would build it in a fortnight if it mattered. Position: no commercial dependency, and treat any future revival as a new product.

Distribution decides this one. There is no signed package on the row, only a clone-and-compile path that expects a toolchain on the machine, and asking sixty engineers to build their own desktop application is not a rollout, it is sixty unsupported binaries. Nothing offers SSO, SCIM or an audit trail, and there is no headless mode, so it contributes nothing to a pipeline.

The usage dashboard is genuinely useful for an individual and reports to nobody above them. Onboarding is an afternoon plus a build. Not yet, and probably never in this form.

The licence is the good news: strong copyleft means a fork stays open and anyone who ships a hosted version owes the source back, and building it myself is a normal afternoon rather than a reverse-engineering project. Managing MCP servers from the interface is the feature I would otherwise be editing JSON for.

The bad news is the ceiling. This drives one vendor's command-line tool, so the model is not a choice I get to make, my own key is the only thing I bring, and nothing here runs on my own hardware. A fork inherits that limitation because the limitation is the point of the product.