Evener

The deciding trait is that one running service feeds three front ends. A session begun in the web view is the same session you steer from the terminal dashboard or script against without a prompt, so the interface stops being a commitment you make at the start. Most tools in this category make you choose once and live with it.

What you give up is maturity, because this is a young project and the polish is uneven. Pick it if the multi-surface idea solves something real for you. Pick a single-surface agent if you were happy in the terminal anyway.

The failure mode is central. Putting an orchestrator between the user and every session is a reasonable architecture and it also concentrates the risk: a crash, a restart, an upgrade, and the state of every task in flight is undocumented. Tracking many sessions at once means many losses at once, and the row does not say whether any of them resume.

What it does right is show the work. The web view streams the agent reading files, running commands and editing code as it happens, so a run going wrong is visible while it goes wrong.

1. Using native tool calling removes an entire class of parsing failure and shifts the correctness burden onto the provider, which is the right place for it. 2. Documenting runtime contracts for subagents, plugins and hooks means a third-party extension is written against a stated interface rather than against observed behaviour, and interfaces are the part of a design that has to survive model changes.

2. Confinement covers file, process and network access as separate axes, which is a more precise statement than most projects make. 4. No evaluation is published.

An incorporated vendor publishing a free tool with no commercial surface is doing one of two things: recruiting, or building the thing it needed internally and publishing it because that costs nothing. Either way the roadmap answers to a business that earns elsewhere, and attention moves when that business does.

Moat: none, and none sought. Likely path: it tracks the internal need that produced it and stops when that need is met. Position: usable now, unwise as a dependency you cannot replace in an afternoon.

The scriptable entry point is what makes this worth a conversation. A tool that runs without a terminal in front of it can be measured, scheduled and put behind the same review gates as everything else we run, rather than living as sixty private habits I hear about anecdotally.

Against that, procurement gets nothing: no identity integration, no provisioning, no audit record and no supplier who owes us anything. Onboarding a Go-comfortable engineer is quick; the operating burden lands on my platform team. Approved with conditions: pipeline use first, laptops later, and keys issued centrally.

The licence is the good news and the source is readable, so a fork stays viable and I can patch what annoys me. Bringing my own key across the three supported providers works, and installing by piping a script into a shell is at least honest about what it is doing to my machine.

The closed doors are on the model side. No local endpoint, so my own hardware is not a target, and no MCP client, so the servers I already run are not tools here. For a project this configurable elsewhere, both feel like omissions rather than decisions.