← Back to Blog

Developing with Eca

I’m now using Eca now as my most recent LLM framework.

Eca is an editor agnostic framework to talk to LLMs (via APIs or local LLMs)

Previously I’ve used Aider which is a CLI that’s service agnostic.

The Emacs Implementation of this worked well, but you’re mainly working with a wrapper around a TUI via emacs, which is similar to using one of the CLIs currently provided by all of the services or working with a an LLM specific editor.

Eca will allow you to stay agnostic of service and editor and provides you features hooks, commands etc.

Setup

I will focus on the emacs implementation as that’s what I’m using, but eca is available for vscode and intellij as well.

Configuration

You can configure Eca globally in the ~/.config/eca/config.json file or in your repository in a GIT_ROOT/.eca/config.json file.

This configuration will contain api keys, mcp configurations and more.

Authentication

Eca also supports authentication via logging in to your LLM subscription service.

You can configure

Simple type

sh
/login

And you will get a list of services and show you furhter instructions how to use eca with your LLM service subscription of choice.

Authenticating via ~/.netrc

Netrc is a file containing your authentication passwords.

Ideally you encrypt this file via gnupg.

The format for eca looks like this

rc
machine api.llm-provider.com
login company
password ********************************

Now you can use LLM models from multiple sources (e.g.: company, private) by defining:

json
{
  "providers": {
    "my-company": {
      "api": "anthropic",
      "url": "https://api.anthropic.com",
      "keyRc": "api.llm-provider.com",
      "models": {
        "claude-sonnet-4-5": {}
      }
    }
  }
}

If you call M-x eca-chat-select-model in the eca-chat buffer, you will be able to select your company chat model and your key will be loaded by user .netrc file, so you can keep your configuration secrets private!

This will let you keep your root config in systems like Nixos without having to encrypt it.

MCPs

MCPs let LLms talk to services like your LSP.

I’m slowly moving away from MCPs though, as I’m understanding that they cost context tokens and can muddy the given task.

But here are a couple of MCPs that I’m using:

Chrome DevTools MCP

This lets your LLM inspect web pages by interfacing with chrome.

It lets your LLM look at the chrome developer tools to inspect and debug programs.

json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp",
        "--browserUrl",
        "http://localhost:9222"
      ]
    }
  }
}

This will install chrome-devtools-mcp automatically via npx for you

Clojure MCP

This MCP connects to the clojure nrepl to evaluate clojure live.

json
{
  "mcpServers": {
    "clojure-mcp": {
      "command": "bash",
      "args": ["-c", "clojure -X:mcp :port 7888"],
      "disabled": false,
      "autoApprove": []
    }
  }
}

To install it, add to your local deps in ~/.config/clojure/deps.edn

edn
{:aliases
  {:mcp
    {:deps {com.bhauman/clojure-mcp {:git/url "https://github.com/bhauman/clojure-mcp.git"
                                     :git/tag "v0.1.8-alpha"
                                     :git/sha "457f197"}}
     :exec-fn clojure-mcp.main/start-mcp-server
     :exec-args {:port 7888}}}}

Now the LLM can talk to your clojure session via the NREPL. If you don’t have an NREPL server start one via

sh
clojure -M:nrepl

Commands

Commands will let you share instructions to LLMs via simple / prefixed commands.

You can store them in your eca directory in ./.eca/commands and are stored in mardown format.

They’re like aliases for your LLM.

My current commands are pretty simple:

/catchup

In ~/.config/eca/commands/catchup.md

markdown
Review the git diff of the current branch to add to the context
Run: `git diff main...HEAD`

This will add context of the current branch to continue developing on a feature.

/fix

~/.config/eca/commands/fix.md

markdown
Run build and fix the errors
Run: `my-build-script`

This is i a repository specific command to look at the errors and try to fix them via the LLM.

You can add things like these via https://eca.dev/configuration/#hooks, but I like to execute these manually as otherwise they create too much overhead and token usage.