Kun

You will notice the difference on the days that are not coding days. The deciding trait in daily use is scope: one window handles project work and also spreadsheets, slides and long PDF analysis, so the assistant that knows your repository is the same one that reads the requirements document somebody emailed you. Fewer tools, fewer contexts, one habit.

Pick it if that breadth matches your actual week. Pick Zed if you want everything pointed at code and nothing else, or a terminal agent if you would rather your assistant had no opinions about presentations.

Unattended is the risky word. Automation here includes schedules and repeating loops, which means the agent acts at times when nobody is reading its output, and the row records no containment around the process while it does. A loop that misreads its exit condition at two in the morning is a different category of incident from one you can interrupt. Nothing documented bounds the iterations.

What it does right: the coding side treats review as part of the work, with diffs and test runs presented for approval, so at least the changes that reach you arrive with evidence attached.

The structural decision is a client-server split done locally. 1. Both front ends connect to a single background process, so an approval granted in one surface is the same object the other surface sees, and there is no reconciliation layer to get wrong. 2. That also means the interface can change without touching the agent loop, which is the boundary most desktop tools fail to draw.

No evaluation is published and the documentation lives as repository pages rather than a reference site. The architecture is the strongest evidence on offer, which is unusual and, on this board, welcome.

There is no pricing page, no seat figure and no hosted tier, only a licence that reserves commercial rights for later. Reserving rights is not the same as having a model, and the gap between the two is where products get monetised abruptly and users get surprised. Six thousand stars say the distribution arrived before the business did.

The likely paths are a commercial edition, a hosted service using the reserved rights, or an indefinite side project. No acquirer is obvious for a desktop workbench with no revenue. Position: adopt personally, assume the terms change once someone has to justify the time spent on it.

Operationally this is sixty desktop applications each starting a background service on an engineer's laptop, which is sixty things to patch and nothing to observe centrally. Identity is absent from the row: no single sign-on, no SCIM, no audit trail, so I cannot tell you who ran what against which repository. There is no headless mode, so it never becomes a pipeline step and never produces an artefact my release process can check.

Onboarding is a day, and two modes to explain. Not yet. Bring me central visibility, then we talk about seats.

The licence is the ceiling. PolyForm Noncommercial is source-available, not open source, which means my fork is legal for tinkering and illegal for anything that earns, and that is a real limit on ownership rather than a technicality. Under that ceiling it behaves well: a named local preset, editable base URLs so any compatible endpoint works, MCP servers configured per project, plus skills and installable extensions.

So the model runs on my hardware and the code sits on my disk, and I still do not own it. That is a more honest deal than most closed tools offer, and it is not the deal I want.