Why elelem

Pick two #

Every coding agent trades between three things. Fast: it answers before you lose your train of thought. Correct: the change works. Autonomous: it gets there without you. You can have any two. A fast, autonomous agent cuts corners. A correct, autonomous one takes its time. A fast, correct one needs you in the loop.

Most tools don’t say which two they picked. elelem puts the trade in the tagline, and leaves the choice to you: the model, the tools, and how much the agent may do on its own are all yours to pick.

Small is a feature #

The core of elelem is a few files of Ruby: the agent loop, the conversation, the toolbox, slash commands, and the plugin registry. It fits in an afternoon of reading.

That matters because an agent is trusted with a lot. It reads your files, runs commands, and writes code you will ship. When it misbehaves, you should be able to open the source and find out why, without a framework, an SDK, or a build system in the way.

Small also means honest. elelem has no defensive layers that hide what is going on. It assumes a capable model that behaves like a capable engineer, and it gets out of the way.

The Vim of coding agents #

Vim has lasted for decades because it got a few things right. It starts fast and runs in any terminal. You shape it with files you own, and people extend it with plugins instead of asking for changes to the editor.

elelem is built to be that for coding agents. The loop is small and stays small. Your instructions live in AGENTS.md, your extensions in .agents/plugins/. Learn it once, shape it to how you work, and keep it.

Open for extension, closed for modification #

The plugin system follows the open/closed principle, as Bertrand Meyer put it: software should be open for extension and closed for modification. You never fork or patch the core to add a model, a tool, or an interface. You write a plugin. Elelem.configure lets any Ruby file register a provider, add tools and slash commands, or replace how elelem reads input and writes output.

elelem holds itself to the same rule. In 0.11.0, every provider, tool, and interface moved out of the core into its own gem. The core got smaller, and nothing got harder to extend.

Everything else is a plugin #

Anything that is not the loop lives outside the core. Models are providers. Reading and writing files are tools. A plugin can replace the terminal UI, and the web UI is a plugin. A plugin can be as small as one Ruby file in .agents/plugins/, kept in your dotfiles or committed with your project.

You install what you use. A team that only runs a local model never installs an HTTP client for a cloud API. A team that wants MCP servers and agent skills adds two gems.

Your model, your machine #

Hosted models are excellent, and elelem supports Claude and Ollama, with OpenAI support still being finished. But some code should not leave the building, and some developers want to understand what happens to their tokens.

elelem-llama loads a GGUF model file straight into the elelem process through llama.cpp. There is no server and no API key, and nothing goes over the network. The lab goes further: elelem-ggml builds a Qwen2 transformer by hand on ggml, and elelem-llama2 runs Karpathy’s llama2.c. You can read the whole path from your prompt to the matrix multiply.

Unix at heart #

elelem is a command. elelem chat opens a session. elelem ask takes a prompt and reads stdin, so it fits in a pipe:

git diff | elelem ask -p ollama "write a commit message for this"

Compose it with the tools you already have.

What elelem is not #

It is not an IDE, a hosted service, or a framework for building other agents. It does not try to stop a model from doing something dumb with layers of guardrails; it gives you a small, readable harness. elelem-tools asks before a tool runs. That is a speed bump, not a sandbox. If you want an agent that does everything out of the box, there are good ones. If you want one you understand, start here.

Read the quickstart or browse the plugins.