ECA (Editor Code Assistant): One AI Pair Programming Server for Emacs, Vim, VS Code and IntelliJ
Editor Code Assistant (ECA) - AI pair programming capabilities agnostic of editor
At a glance
- What is it?
- ECA puts an LLM-backed server between your editor and your model providers, so chat, rewrite and completion behave the same everywhere. Here is how the protocol works, how to install a plugin, and where the design still leaves gaps.
- Who is it for?
- Adopt ECA if you work across more than one editor and want a single config.json to define your providers, agents and models, with the server spawned as a subprocess over stdin/stdout. Do not adopt it if you want a single-editor assistant with a large extension marketplace, or if you need a documented rollback path for the auto-downloaded server binary, which the README does not describe.
- 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 last received commits 3 days ago.
- What is it written in?
- Mainly Clojure, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem ECA solves: one AI assistant across editors you do not control
Most AI coding assistants ship as a plugin for one editor. If your team uses Emacs and VS Code, you end up with two extensions, two configuration formats, two sets of keybindings, and two different accounts for the same model provider. ECA takes the opposite route. The README describes it as "Editor-agnostic: protocol for any editor to integrate", with the server written in Clojure and "heavily inspired by the LSP protocol". That comparison is the whole design argument: language servers solved the N-editors-times-M-languages problem by standardising a protocol, and ECA applies the same shape to LLM interaction.
The audience is narrow and specific. It is for engineers who already have a preferred editor and will not switch, but who want chat, rewrite and completion to behave identically in each one. It is also for people who maintain editor integrations, since the protocol is documented separately from any single plugin. If you only ever open one editor and you are happy with its native assistant, the abstraction buys you nothing and costs you a subprocess per session.
How the server and editor plugin talk to each other
The README states the mechanism plainly: "Editors spawn the server via `eca server` and communicate via stdin/stdout, similar to LSPs." There is no daemon listening on a port, no HTTP endpoint to firewall, and no separate service to keep alive. The editor owns the process lifecycle, which means when you close the editor the server goes with it.
That choice explains several other properties. Because the server sits in the middle, the README lists what it can centralise: "Tool call management", "Multiple LLM interaction", "Telemetry of feature usage", "Single way to configure for any editor". A plugin only has to render chat and send protocol messages. Provider authentication, model selection and agent behaviour live on the server side, in a config.json that is global or local.
The documented feature set covers three surfaces: chat, rewrite and completion, "all powered by your LLM". On top of that sit agents and subagents, which the README says can be configured "with different models, tools, and behaviors", plus context injection including "MCP resources and prompts". Multi-model support is listed for OpenAI, Anthropic, Copilot and Ollama local models. OpenTelemetry export covers "metrics of tools, prompts, server usage", which is the part that matters if you are trying to justify the tool to a team rather than to yourself.
Installing ECA through an editor plugin and configuring a first model
The README's Quickstart does not ask you to install the server by hand. Step one is to install the plugin for your editor, and the text says the server "will be downloaded and started automatically". Separate repositories exist for Emacs, VS Code, Vim, IntelliJ and a desktop build. The install page linked from the README is https://eca.dev/install, and the repository also contains an `install` entry at the top level.
If you are integrating rather than using an existing plugin, the entry point is the server command the editor spawns:
eca serverOnce a plugin is running, the README's second step is model setup. The interactive path is a chat command, not a config file edit:
/loginThe README describes the sequence: type `/login` in the chat, choose your provider, follow the steps to configure the key or auth, and ECA "will add to the global config.json the config for that provider". The README also notes that GitHub Copilot offers free models, which is the cheapest way to confirm the whole path works before you commit to a paid provider. Manual configuration is documented at https://eca.dev/config/models for providers not covered by the login flow, and custom providers have their own section on that page.
After a model is configured, the third step is simply using the feature interface in your editor. The README points to a Suggested Workflow page at https://eca.dev/workflows rather than describing the workflow inline, so expect to read that page before you have a working habit.
Where ECA gets in the way: auto-downloads, Clojure, and thin documentation
The most concrete limitation is the one the README states as a feature. Plugins download and start the server automatically, which is convenient on a managed laptop and awkward everywhere else. The README does not document rollback, pinning a specific server version, or running the server from a local build in the plugin path. If your environment restricts outbound downloads or requires a reviewed binary, that gap is the first thing you will hit, and the README is silent on it.
The implementation language is a second real constraint. The server is Clojure, and the repository layout reflects that: `deps.edn`, `bb.edn`, `build.clj`, `flake.nix`, and a `src/` tree of Clojure sources. Using ECA as a black box requires no Clojure knowledge, and the README never asks for any. Contributing to the server, debugging a protocol message, or building from source does. Editors and tooling teams should weigh that against a TypeScript or Rust server they could patch themselves.
Documentation depth is uneven. The README links to pages for configuration, models, protocol, troubleshooting and development, and the repository has a `docs/` directory and `mkdocs.yml`, so the site is generated from the repo. But the README itself is a pointer document: it tells you where things are rather than how they behave. For a protocol that other people are expected to implement against, that is a reasonable split. For someone evaluating the tool in an afternoon, it means several page loads before you know whether completion works the way you expect.
ECA compared with single-editor assistants like Claude Code IDE mode
The closest comparison people search for is Claude Code's IDE mode, and the difference is architectural rather than cosmetic. An editor-specific assistant is built inside that editor: it can use the editor's own extension APIs, its diff view, its file watcher and its settings UI directly. ECA gives that up deliberately. The plugin is a client of a protocol, and everything the assistant knows about your project arrives as protocol messages.
The trade is visible in the feature list. ECA gains a single config.json shared across editors, agents and subagents with per-agent models and tools, MCP resources and prompts as context, and OpenTelemetry metrics of tool and prompt usage. It loses whatever a given editor exposes only through its native extension API, and it depends on each plugin author keeping up with the protocol. The README notes that editors already integrated "require no extra configuration" because they download the server on start, which keeps the plugin side small but also means the plugin's quality varies by maintainer.
There is a second comparison worth making. Running a local model through Ollama keeps prompt and code data on your machine, and ECA lists Ollama among supported providers. If your reason for avoiding a hosted assistant is data residency, the server-in-the-middle design does not change that; the model provider does. ECA is neutral on which one you pick, which is the point.
Maintenance, release cadence and what Apache-2.0 means here
The repository is not archived, and the last push was on 2026-09-10. Recent releases are close together: 0.159.0 on 2026-09-08, 0.158.1 on 2026-09-03, and 0.158.0 on 2026-09-01. The version numbers are still in the 0.x range, and the README has a Roadmap section pointing at a GitHub project board, so the maintainers treat the API as movable. For a protocol that other editors implement against, that is the upgrade risk to plan for: a plugin built against an older server may not match a newer one, and the README does not describe a compatibility policy.
Licensing is Apache-2.0, per the repository's LICENSE file. That is a permissive licence with an explicit patent grant, which matters if your organisation has policies about which open source licences it accepts in developer tooling. It does not tell you anything about the model providers you connect to: their terms, their data handling and their costs are separate agreements, and the repository includes a PRIVACY.md that is about this project rather than about your chosen provider. Nothing here is legal advice; read LICENSE and PRIVACY.md yourself before you roll ECA out to a team.
Upgrade cost is mostly the auto-download. Because plugins fetch the server on start, you do not control the version by default, and the README does not document a way to pin one. Teams that need reproducible tooling should confirm that behaviour with their editor's plugin before standardising on ECA.
Editorial conclusion
Adopt ECA if you work across more than one editor and want a single config.json to define your providers, agents and models, with the server spawned as a subprocess over stdin/stdout. Do not adopt it if you want a single-editor assistant with a large extension marketplace, or if you need a documented rollback path for the auto-downloaded server binary, which the README does not describe. Before committing, install the plugin for your editor, run /login in the chat to add one provider, and confirm that the version the plugin fetches matches the release you expect.
Frequently asked questions
Which code editor is best for coding?
ECA does not rank editors. It is built as a protocol any editor can integrate with, and the README lists supported plugins for Emacs, VS Code, Vim, IntelliJ and a desktop build, so the choice of editor stays yours.
Is Emacs a code editor?
Emacs is one of the editors ECA integrates with. There is a separate eca-emacs plugin repository, and the README lists Emacs first among the supported integrations, with the plugin downloading and starting the server automatically.
What is Microsoft's code editor called?
VS Code is the Microsoft editor among ECA's supported integrations, with its own eca-vscode plugin repository. Installing that plugin is enough, because the README states the ECA server is downloaded and started automatically.
What is an IDE and code editor?
ECA targets both categories through the same protocol. IntelliJ is listed as an IDE integration and Emacs, Vim and VS Code as editor integrations, and all of them spawn the server via the eca server command and communicate over stdin/stdout.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/editor-code-assistant-eca)