ECA: One AI Coding Server for Emacs, VS Code, Vim and IntelliJ
Editor Code Assistant (ECA) - AI pair programming capabilities agnostic of editor
At a glance
- What is it?
- Editor Code Assistant puts a Clojure server between your editor and your LLM, speaking a JSON-RPC protocol modelled on LSP. It is worth a look if you switch editors often or want one config for chat, rewrite and completion. The trade-off is a young protocol and a server you now have to keep alive.
- Who is it for?
- Adopt ECA if you already work across more than one editor, or if you want chat, completion and rewrite driven from one config.json and one model login rather than configuring each editor separately. Skip it if you need a mature plugin ecosystem, if you are unwilling to run a separate server process, or if your editor is not one of the five that already have plugins.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Clojure, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The editor-by-editor AI plugin problem ECA is trying to avoid
AI coding features usually arrive as one plugin per editor. Each plugin owns its own model configuration, its own chat UI, its own tool-calling loop, and its own idea of what a diff looks like. If you use Emacs at home and IntelliJ at work, you configure the same provider twice and get two different behaviours. ECA's stated rationale is to put a server in the middle so that the editor only has to render and send keystrokes. The README lists the intended benefits directly: tool call management, multiple LLM interaction, telemetry of feature usage, a single way to configure for any editor, and the same UX across editors so that onboarding people and teams is easier. The audience is therefore not the developer who lives in one editor and is happy with that editor's built-in assistant. It is the developer or team that already pays the cost of switching, or that wants the model configuration to live in one file rather than in five plugin settings screens.
What actually crosses the stdin/stdout boundary
The mechanism is deliberately close to the Language Server Protocol. According to the README, editors spawn the server with eca server and communicate over stdin/stdout, in the same way an LSP client talks to a language server. The server is written in Clojure and the site publishes a protocol page, which suggests the wire format is documented rather than implied. Features named in the README are chat, rewrite and completion, all routed to whichever LLM you configured. Agents and subagents are configurable with different models, tools and behaviours, so a single server process can hold more than one persona. Context can include MCP resources and prompts. OpenTelemetry export is listed for metrics on tools, prompts and server usage. The practical consequence of the architecture is that the editor plugin is thin: it starts a process, speaks JSON-RPC, and draws results. Anything the server can do, every supported editor gets at roughly the same time, which is the strongest argument for this design over per-editor plugins.
Installing a plugin and letting it fetch the server
The quickstart path does not ask you to install the server yourself. You install the plugin for your editor, and the README states that supported editors download the latest server on start and require no extra configuration. Five integrations are linked: eca-emacs, eca-vscode, eca-nvim, eca-intellij and eca-desktop. Model setup happens after that. The documented flow is to type /login in the chat, choose a provider, and follow the prompts for the key or auth. The README notes that this writes the provider configuration into the global config.json. The same page points to a manual configuration route and to custom providers for anything not covered by the built-in list. Providers named in the feature list are OpenAI, Anthropic, Copilot and Ollama local models, with the README adding that GitHub Copilot offers free models. Two config locations are mentioned, global and local, and the claim is that configuring ECA once makes it behave the same in any editor. If you maintain a dotfiles repository, that is the file to track; the README does not spell out the exact path per platform in the material available here, so check the configuration page before assuming a location.
Where the server-in-the-middle design costs you
A separate process is a separate failure surface. The editor plugin starts eca server and speaks to it over stdin/stdout, which means a crash, a hang, or a slow model response is now something the plugin has to detect and recover from, and something you have to debug in two places instead of one. The troubleshooting page exists for a reason. There is also a version skew question the README does not answer: plugins download the latest server on start, so a plugin that has not been updated recently may be talking to a protocol version it does not expect. Nothing in the supplied material describes protocol version negotiation or a pinning mechanism. The project is also pre-1.0, with releases 0.159.0, 0.158.1 and 0.158.0 landing within roughly a week of each other, which is a fast cadence for something you are expected to run inside your editor all day. And if your editor is not one of the five with a plugin, the protocol is the only path in, which means writing a client yourself.
How ECA differs from editor-native assistants and from Aider
The obvious comparison is the assistant already shipped inside your editor. Those are single-editor by construction: the model configuration, the chat panel and the completion engine live in that editor's extension host or core, and none of it transfers when you open a different editor. ECA's answer is the opposite arrangement, with the logic in a shared Clojure server and the editor reduced to a client. A second comparison is Aider, which is a terminal program that edits files in your repository and expects you to drive it from a shell. Aider's unit of work is the repository and the command line; ECA's unit of work is the editor session, with chat, rewrite and completion surfaced inside the editor UI. Neither is a superset of the other. If your workflow is already terminal-centric and you want an agent that commits, Aider's shape fits better. If your workflow is editor-centric and you move between editors, the protocol approach is the one that avoids duplicated configuration. The README's own framing is that model differences will matter less over time while the UX of editing and planning code will persist, which is a fair summary of where ECA places its bet.
Maintenance, release cadence and the Apache-2.0 licence
The repository is active, not archived, with the last push dated 2026-09-10 and a 0.159.0 release two days earlier. Three releases inside eight days is a signal about how much is still moving, and it is the main maintenance cost: you should expect to update the plugin and the server together rather than treating either as fixed. The licence is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the notices and state changes, and it includes an explicit patent grant. That is a permissive licence and removes most of the questions a team would ask before shipping ECA inside a corporate environment, though the usual caveat applies: licence terms interact with how you distribute the software, and that is a question for your own legal review rather than something a project page can settle. The README also points to a public roadmap project and a Slack channel on clojurians.slack.com for support, so the maintenance model is community-driven rather than vendor-backed.
What to check before you make ECA your daily driver
Start with the protocol page, because that is the contract everything else depends on. If the protocol is documented well enough that you could write a client, the architecture is doing what it claims. Then confirm the two operational basics on your own machine: that eca server starts and stays up, and that /login succeeds against the provider you actually intend to use, including any local Ollama endpoint. Check which config file your editor plugin reads, since the README distinguishes global from local configuration without listing paths in the material available here. If you work in a team, the single-configuration claim is the one worth validating first: put a provider entry in the global config.json, open two different editors, and confirm both pick it up. Finally, decide whether you are comfortable with the release cadence. If you need a pinned, slowly changing tool, ECA at 0.159.0 is not that yet. If you want the same AI-assisted editing experience in every editor you touch, and you are willing to run a server process to get it, the design is coherent and the integration list is real.
Editorial conclusion
Adopt ECA if you already work across more than one editor, or if you want chat, completion and rewrite driven from one config.json and one model login rather than configuring each editor separately. Skip it if you need a mature plugin ecosystem, if you are unwilling to run a separate server process, or if your editor is not one of the five that already have plugins. Before committing, verify three things: that the eca binary starts on your platform with eca server, that /login completes against your chosen provider, and that the config.json written to your global config path is the file your editor plugin actually reads. The Apache-2.0 licence removes most distribution concerns, but the project is still pre-1.0 and releases land weekly.
Community notes