ECA

The deciding trait is that the assistant behaves the same wherever you opened it. Chat, rewrite and completion are the same implementation in every client, so the person on a twenty-year-old editor and the person on the newest one are describing the same tool when they help each other. That is worth more than any individual feature.

What you give up is the deep integration a native extension gets from living inside one editor. Pick it when your team is genuinely mixed. Pick the editor's own agent when it is not.

The loop is open by construction. An agent that writes code without a way to execute it cannot discover that an import is wrong, a signature changed or a suite went red; it can only propose and wait. Every correction therefore costs a full human round trip, and the failure mode is not dramatic, it is slow.

What it does right is the subagent arrangement. Different agents carry different models, tools and behaviour, so a cheap one can answer questions while an expensive one edits, and the user knows which answered.

1. Emitting telemetry in a standard format rather than a bespoke log means the questions that matter, how often a tool is called, how many tokens a prompt consumes, how long a turn takes, are answerable with instrumentation an organisation already runs. 2. That is the difference between a vendor's published number and a number a reader can generate on their own workload.

2. Modelling the whole thing on an established editor protocol is the second sound decision: the failure modes of a stdio server negotiating with a client are twenty years catalogued rather than newly invented.

The language choice is the risk nobody prices. It is a fine decision for the people writing it and it materially shrinks the set of contributors who could take over, which for a project with no commercial entity behind it is the only succession plan there is. Nearly a thousand stars is genuine interest and finances nothing.

Moat: neutrality across editors, which is a real position because no editor vendor will build it. Likely path: continued volunteer maintenance, or absorption of the protocol idea by a larger project. Position: adopt, pin, and read the source before you depend on it.

Configuration is the reason this is easy. One place defines behaviour for everybody and a project-level file lets a repository override it, so I can set the model, the tools and the limits without visiting sixty machines or trusting sixty developers to read a wiki page. That is a rollout memo rather than a project.

What it will not do is run unattended, so it never becomes a measurable pipeline step, and the permissive licence means legal review is a formality. Approved with conditions: the global configuration is owned by the platform group and shipped with the plugin.

Implementing the parts of the protocol beyond tool calling is the detail that tells me somebody read the specification instead of the blog post. Resources and prompts mean a server I already run can supply context and canned instructions, not just functions, and that is a much larger surface than the usual implementation exposes.

Local inference is a first-class login rather than an escape hatch, so the whole thing runs with nothing leaving the machine. Permissive licence, a plain process speaking over standard input and output, and I can drive it from a script without an editor at all.