Pi Web

The deciding trait is that there are two ways to branch. You can split a whole new session off an earlier message, or branch inside the one you are in, and those are genuinely different moves: one is a fresh attempt, the other is a detour you intend to come back from. Once you have both, going back to a single thread feels careless.

You are the wrong buyer if a conversation is disposable to you. Pick it if you rework old sessions. Pick the plain terminal if you never reopen one.

A server is a server. This one listens locally, manages provider logins and keys through the browser, and can upload files into your project, and nothing in the row describes an authentication step in front of any of it. On a laptop at home that is fine. On a shared machine, a conference network or a misconfigured interface, it is an unauthenticated key manager.

What it does right is avoid a second copy of the truth. Configuration and history are the files the agent itself uses, not a duplicate that can disagree.

1. The interface reads the same files the underlying agent writes, which means there is one representation of a session rather than two that must be reconciled. Divergence between a front end's model and the engine's model is a common and tedious source of defects, and this design removes it by refusing to have a second model.

2. The consequence is that the front end can be replaced or removed without migration. 3. No evaluation is published and none is claimed, which suits a project asserting only an interface.

5,917 stars is a striking figure for a front end, and it is measuring somebody else's popularity. What it proves is that the upstream agent has a large user base underserved by its own interface, which is useful information for the upstream and difficult to monetise from here.

Moat: none, and being first is the whole position. Likely acquirer: none, though upstream absorbing the idea is the standard resolution and would be entirely reasonable. Position: use it, and read the star count as a fact about the ecosystem rather than about this project.

The deployment detail that matters is the runtime floor: it needs a recent Node release, which means my endpoint fleet has a version requirement before anyone can start, and that is a ticket per machine on the laptops that have drifted.

Nothing per seat, and the model spend sits on provider accounts my engineers already hold. There is no SSO, no audit log, no retention policy, no console, and nothing runs unattended. Approved with conditions: managed runtime versions, and loopback binding enforced by policy.

It asks me for nothing. Provider logins, keys, models, plugins and skills are the ones already configured on this machine, managed from a page rather than re-entered, so adopting the interface does not mean maintaining a second credential store.

MIT means the fork is available and the server is small enough to read in an evening. There is no MCP in either direction, so the tool surface belongs to the agent underneath and this layer cannot extend it, which is honest for a front end and still a limit.