ACP UI

You will like this if you already run two or three ACP agents and are tired of a separate window for each one. The deciding trait is that it brings no model and no opinion: whatever agent you already pay for keeps its own credentials, and this is just the surface you drive it from.

What it is wrong for is the developer who lives in one agent and one terminal, where a second app buys you nothing. Pick it if you switch between agents weekly and want one habit instead of five. Pick the vendor's own desktop client if you have settled on a single agent.

The risk is a client with nothing behind it. Every capability listed belongs to the hosted agent and reaches the user through a protocol that agent must implement and keep implementing. When an upstream vendor changes its interface, no fallback is documented, and the failure arrives as a session that will not start.

The mobile and browser builds carry the second half of that problem: they reach a remote agent over WebSocket and cannot spawn a subprocess or touch a host filesystem, so the phone app is a viewer more than a workspace. What it does right is admitting this in the documentation rather than in the release notes.

1. The separation is principled: the agent decides, the client executes, and the permission policy sits at the boundary where a decision becomes a write. That is the correct place for a gate, since it does not depend on the agent behaving well.

2. Exposing protocol traffic to the user is a verification affordance rather than a debugging convenience.

3. No benchmark is published and none is claimed, which is consistent: the project asserts an interface, not a capability. The omission is that no measurement of protocol overhead accompanies the design, so the cost of mediating every file operation through a second process remains undocumented.

The structure is a single-author project with no company attached, which removes the acquisition question and replaces it with a calendar question. Stars are evidence of interest and finance nothing. Moat: none available, because the value sits in a specification the author does not control and anyone can implement against.

Likely path: the agent vendors ship their own clients, this one keeps a devoted few, and the good ideas migrate into an editor that already has distribution. There is nothing to acquire except the author. Position: use it freely, and do not let it become the only way your team reaches an agent.

Financially this is free sixty times over, and the spend stays on the agent subscriptions we already reconcile. Operationally it is sixty desktop installations with no administrative console, no single sign-on and no audit record of which agent touched which repository. Version drift is mine to manage with the desktop tooling I already run.

It does not run unattended, so it never appears in CI and never becomes a number I can report. Onboarding is an afternoon, which is the one easy line here. Not yet: it may sit on an individual developer's machine, but it is not something I can put in front of sixty people and answer for.

MIT is the right licence and a Tauri shell is a small enough codebase that a fork stays maintainable by one person. I like that it hosts my agent rather than replacing it: my keys stay where they were, and nothing new asks for a login. Installers exist for four platforms and the source builds without ceremony.

What I cannot do is add tools. There is no MCP client and no MCP server here, so anything I want to extend, I extend inside the agent instead. Grudging respect for staying that small on purpose, but ownership of a window is not ownership of a toolchain.