Ellama: LLM chat, context and agent loops inside Emacs

The gap Ellama fills for Emacs users

Most LLM tooling assumes you will leave your editor. Ellama takes the opposite position: the README says it brings large language models into Emacs "without turning Emacs into a web app". That framing is the whole design brief. The target user is someone who already has buffers, regions, Info nodes and project files open, and who wants the model to see those things without copy-pasting into a browser tab. The commands reflect that. ellama-ask-about adds the selected region or the current buffer to ephemeral context for one request. ellama-ask-line sends a single line. ellama-ask-selection pushes a region into a chat buffer. None of these require leaving the file you are editing. The package also covers the routine writing tasks the README lists: translation, summarization, proofreading, code review and editing, extraction, formatting and commit-message generation. If your work is mostly one-shot transformations of text you already have on screen, the ephemeral context commands are the useful surface. If your work is long conversations with a model, the session machinery is. Ellama is not trying to be a chat product with an editor plugin. It is an Emacs package that happens to talk to models.

One command surface, many providers through llm

Ellama does not implement provider protocols itself. It depends on the llm package, and the README states that Ollama works with a local model while the same commands can be configured for OpenAI-compatible APIs, OpenAI, Claude, Gemini, Vertex, GPT4All, LlamaCpp and other llm providers. The practical consequence is that switching backends is a matter of changing ellama-provider, not of learning a second set of commands. The README also notes that when a provider supports extra capabilities, Ellama uses them: streaming responses, model lists, image and audio input, tool calls, token limits and interactive model switching. That list is worth reading as a warning rather than a feature list. Capability support is provider-dependent, so an image command such as ellama-ask-image or ellama-chat-with-images only makes sense against a provider that accepts image input. The agent commands only make sense against a provider that supports tool calls. The documentation does not, in the material available here, give a matrix mapping each command to the providers that can serve it. That is a real gap: you will discover the boundary by trying a command and reading the failure. The upside of the llm dependency is that Ellama inherits provider work instead of duplicating it. The downside is that provider quirks surface as Ellama behaviour.

Getting it installed and pointed at a model

Installation is a single package install from GNU ELPA: M-x package-install RET ellama RET. By default Ellama uses the first available Ollama model, so if you want that path you install Ollama and pull a model, for example ollama pull qwen3.6:35b. The README uses that model for its agentic coding examples and tells you to substitute whatever is available in your Ollama installation. The minimal Emacs configuration binds C-c e to the ellama transient menu, hooks ellama-chat-send-last-message into org-ctrl-c-ctrl-c-hook, sets ellama-auto-scroll, and enables ellama-context-header-line-global-mode and ellama-session-header-line-global-mode. The agentic setup adds require of llm-ollama and constructs the provider explicitly with make-llm-ollama, passing :chat-model and :embedding-model. It then calls ellama-setup-agentic-coding, which the README describes as enabling tools, compacting old context, showing sub-agent buffers, enforcing DLP, blocking irreversible actions and giving agent loops enough steps to finish real work. Provider-specific tuning goes through :default-chat-non-standard-params, shown with (("num_ctx" . 32768)). Other settings in the same block include ellama-language, ellama-naming-scheme, ellama-chat-display-action-function and ellama-instant-display-action-function. Note the shape of the agentic config: one function call changes a lot of behaviour at once.

Context, sessions and compaction

The README calls context first-class, and the request model backs that up. A request can include buffers, files, directories, Info nodes, selections, images and audio files. Ephemeral context is attached for a single request by commands like ellama-ask-about; chat sessions keep history instead. Sessions can be saved, resumed, renamed, and compacted. Compaction is the interesting part. It can be triggered manually or automatically before a session runs past the model context window. That automatic path is what makes long agent loops plausible at all, because a plan-and-act loop that keeps appending tool output will otherwise hit the window and fail. The cost is that compaction is lossy by definition: old turns are summarized or dropped, and the README does not specify the summarization strategy or what gets preserved. If you are running a long coding session, the practical question is what disappears first. The documentation available here does not answer it. The two header-line global modes exist so you can see session and context state without opening a separate buffer, which suggests the authors expect context to change under you often enough that you need a persistent indicator.

Agent loops and the policy layer around tools

ellama-plan-and-act starts an agent loop that first creates a checklist plan and then acts on it with automatic continuations. The README says it reuses the current chat session when possible and is reachable from the main transient menu with A in the Problem solving section. The agent reads project instructions from AGENTS.md, can load reusable skills and blueprint prompts, and runs plan-and-act loops or subagents from the task tool. Tool calls are subject to project policy: filesystem checks, edit hooks and DLP scans can block or warn on reads, writes, shell commands and tool output. This is the most consequential part of Ellama and the least specified in the material here. The README shows ellama-setup-agentic-coding taking an optional srt settings file path, and describes the difference in a comment: with an srt policy, normal tool confirmations are skipped, ordinary DLP input findings are allowed, output findings are redacted, and irreversible actions are still blocked. Without SRT, confirmations stay active and ordinary DLP input and output findings ask first. Read that comment carefully, because it describes two very different operating modes and the README ships the permissive one commented out. The default is the cautious one. Anyone enabling the srt variant is choosing to remove a confirmation step, and should know exactly what the policy file permits before doing so.

Where Ellama is the wrong tool

Ellama is an Emacs package. If your team does not use Emacs, nothing here applies, and no amount of provider flexibility changes that. Second, the agent path assumes a model that handles tool calls well. The README's own example uses qwen3.6:35b with an embedding model, and a smaller or older local model may produce tool calls that the policy layer rejects or that loop without converging. The README does not publish guidance on minimum model capability, so this is a trial-and-error boundary. Third, the context model is generous but not free: attaching directories and files to requests consumes the context window, and automatic compaction exists precisely because that budget runs out. Fourth, the documentation available here does not include a provider capability matrix, so you cannot tell from the README alone whether a given command will work against Claude, Gemini or an OpenAI-compatible endpoint without testing. Finally, the agent defaults are bundled into a single setup function. That is convenient, but it means a reader who wants tools enabled without DLP, or DLP without blocked irreversible actions, has to work out which individual settings the function sets. The README does not enumerate them.

Comparing the approach with gptel

The obvious alternative in the same space is gptel, another Emacs LLM client. The difference in approach is architectural rather than cosmetic. Ellama is built on the llm package and inherits its provider abstraction, which is why the README can list Ollama, OpenAI, Claude, Gemini, Vertex, GPT4All and LlamaCpp under one command set. That abstraction is also why Ellama can offer tool calls, image and audio input and model lists as provider capabilities rather than as separate code paths. A client that talks to provider HTTP APIs directly tends to expose each backend's own request format and to add features provider by provider. Ellama's bet is that the shared interface is worth the indirection. The second difference is scope. Ellama ships an agent layer: AGENTS.md project instructions, skills, blueprint prompts, plan-and-act loops, subagents, and a policy layer with filesystem checks, edit hooks and DLP scans. A lighter client leaves that to the user or omits it. Whether you want that layer depends on whether you intend to let a model write files and run shell commands from your editor. If you only want chat and region rewrites, the agent machinery is weight you will configure around.

Licence, maintenance and what to verify

Ellama is GPL-3.0 and is distributed through GNU ELPA, MELPA and MELPA Stable, according to the badges at the top of the README. GPL-3.0 matters if you plan to redistribute a modified Ellama or bundle it into a larger Emacs configuration you ship. It is a copyleft licence, so derivative distribution carries source obligations. That is a statement about the licence text, not legal advice; if you are shipping a product that embeds this code, talk to someone qualified. On maintenance, the repository was last pushed in August 2026 and is not archived. No releases were retrieved for this article, so version history and upgrade cadence cannot be assessed from the material here. Upgrading means updating the package and re-reading the configuration surface, because the README shows a fairly wide set of options (provider construction, display actions, naming scheme, agent setup, DLP policy) and agent defaults can change behaviour without changing your config. The concrete next step is to install from GNU ELPA, run ellama-chat against your chosen provider, and only then call ellama-setup-agentic-coding, reading the srt policy file it points at before switching off confirmations.

Editorial conclusion

Adopt Ellama if you already live in Emacs and want one interface for both a local Ollama model and cloud providers, with region and buffer context close at hand. Do not adopt it if you want a general chat client, or if you are not prepared to configure and audit the agent path: ellama-setup-agentic-coding enables tools, DLP and blocked irreversible actions in one call, and the README itself shows the srt policy variant as a commented-out option, which tells you the default posture is confirmations. Before trusting it on a real repository, run the plain ellama-chat path first, then read the tool policy files the agent path references and confirm what your chosen provider actually supports.

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. s-kostyaev/ellama on GitHub