Compozy

You will notice this the first time you close a laptop mid-run and nothing is lost. Work belongs to a background process rather than a terminal, so a client is just a window onto something that keeps going, and that separation is the deciding daily trait, because the tax on long agent work has always been having to babysit the window it lives in.

Pick it if your runs are long and your attention is not. Pick Coder when the actual requirement is isolation on shared infrastructure rather than durability on your own machine.

Two risks compound. The project is six months old and says so, which means interfaces are still moving and the failure reports that would tell you where it breaks have not accumulated yet. On top of that, centralising sessions, schedules and approvals in a single background process makes that process the thing everything else fails with, and a scheduled run that quietly stopped is worse than one that never started.

What it does right: approvals and permissions are first-class concepts rather than settings added after someone was surprised.

1. The ownership inversion is the design: state belongs to a long-lived process backed by embedded storage, and clients attach to it, which is why a disconnection is not a loss. 2. External agent binaries connect over a standard client protocol and operate on that shared state rather than their own, so the durability applies to tools this project did not write. 3. Observability is available from a browser, a shell, a stream and a socket, so verification is not tied to one client.

No benchmark is published. The observation: the interesting property is transactional, not conversational.

Early traction is genuine and the commercial problem is structural. Local-first is a promise to the user that nothing needs a server, and the businesses in this category make money precisely by running servers, so the design forecloses the standard revenue path before anyone tries it. Nothing accumulates on the vendor's side, because by construction nothing reaches them.

Likely path: a hosted control plane bolted on later, which will contradict the positioning, or maintenance as a portfolio piece. Position: pass on the company, and treat the binary as something you may end up maintaining.

One sentence on the demo: it survived a closed terminal, which is genuinely useful. Everything after that is a governance gap. This installs per developer and runs as a long-lived process on their own machine, so there is no fleet view, no central stop, and no record of what a scheduled job did overnight beyond a file on that laptop. Windows engineers cannot run it at all, which excludes part of the team before we start.

Onboarding is an hour. Not yet, and the blocker is visibility rather than price.

The interface list is the tell. A local socket and machine-readable output from the command line mean this composes with everything else on my box, which is what separates a tool from an application. It installs as a single compiled binary with a permissive licence, so there is no runtime to manage and a fork stays mine.

It also exposes itself as a tool server, so the things I already run can reach the daemon rather than only the agents inside it. What is missing is a documented local model story, so inference still assumes somebody's hosted endpoint. In readable Go, that is a patch.