Autolith: a Common Lisp agent that edits its own running image
Autolith is a self-modifiable general purpose Lisp AI agent
At a glance
- What is it?
- Autolith is a terminal LLM agent built on a live Common Lisp image, with self-modification tools, isolated SBCL worker REPLs and a recursive inference layer. The interesting part is not the chat window, it is the image generation and rollback model underneath it.
- Who is it for?
- Autolith fits engineers who already work in Common Lisp or SBCL and want an agent whose tools, prompts and scripts share one evaluator, on Linux, MacOS or a BSD with a packaged release or Nix. It is the wrong pick if you want a language-agnostic agent that runs from a single static binary on any host, or if you cannot accept that the agent's own image is a mutable artefact you must version.
- Can I use it commercially?
- Yes. ISC 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 1 day ago.
- What is it written in?
- Mainly Common Lisp, 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
What Autolith is actually for
Most terminal coding agents are a chat loop wrapped around a tool registry: the model writes text, the harness parses it, a subprocess runs. Autolith starts from the opposite assumption. It is a Common Lisp image that happens to accept prose, and the README is explicit that the message window is a REPL. The stated goal is a live agent that can observe its own code and live state, introspect what it is doing, and modify itself in response. The README calls the result "pretty close to a Lisp Machine" and is careful to say it is not a small game engine. The audience that follows from that is narrow on purpose: people who already think in Lisp forms and want the agent's control surface to be the same evaluator they use by hand. If you have never wanted to call a tool the way the model calls it, the design will read as unnecessary.
The image is the state, and generations are the undo
Self-modification is the load-bearing idea, so the obvious question is what stops it from bricking itself. The README's answer is generations: Autolith creates generations of the image and can roll back to one. It claims even a full lobotomy is not fatal, because the agent reloads into a recovery image and diagnoses the issue, optionally fixing it. That is a checkpoint model rather than a sandbox model. Nothing in the supplied material describes how generations are stored, how large they get, or what triggers a new one, so treat the recovery story as documented behaviour rather than a guarantee. The distinction matters: a checkpoint protects the agent from its own edits, not your filesystem from the agent. The README does not describe a permission boundary around file writes, and I would not assume one exists.
Two tool families keep experiments out of the agent's head
The split between self.* and lisp.* is the most concrete design decision in the README. The self.* tools inspect and modify the active Autolith image. The lisp.* tools run Common Lisp in named, heap-isolated SBCL workers that are separate from that image, and they can target read-only active inspection explicitly. The README frames this as avoiding throwaway Python scripts, which removes a system dependency and lets Autolith observe its own scratch work. It also lets the agent keep a REPL alive or spin up a pristine one, and hold several at once. The example forms are (lisp.eval :form "(+ 20 22)" :repl "scratch"), (lisp.describe :designator "APPLICATION" :target "self") and (self.status). The parallel naming is deliberate: same calling convention, different blast radius. If you are evaluating this for any kind of unattended work, the lisp.* path is the one to standardise on, because a worker that dies takes nothing with it.
Recursive inference treats a big file as an environment
The RLM layer addresses the case where the input does not fit the context window. infer runs one bounded inference over context you pass explicitly, returns a Lisp value, and per the README never touches your conversation. Frames can recurse and fan out through rlm-map, and return validated data instead of prose when you supply a JSON Schema contract. Calls, tokens and recursion depth draw on one shared budget, so a fan-out cannot outspend its allocation, and the private frame conversations cannot pollute yours or your prompt cache. rlm-complete is the heavier form: the input is interned as a content-addressed object, the root model sees only its label, size and digest, and it writes Lisp in an isolated environment to slice, search and sub-infer over that object. Every frame persists a trace under data/inferences/, readable afterwards through inference:<trace-id> URIs. The model reaches the same operations through the rlm.infer, rlm.map and rlm.complete tools. The budget sharing is the part worth noting, because it is a real constraint rather than a capability claim.
Install, auth and the update path
Linux, MacOS and the BSDs get standalone binary releases and Nix. Windows runs from a source checkout through script\bootstrap.ps1 and bin\autolith.cmd. The curl installer is curl -fsSL https://sh.lambda-symbolics.com/autolith | sh, and the README tells you to inspect the installer script first, which is the right instinct for any pipe-to-shell. Nix supplies the full runtime with nix run github:lambda-symbolics/autolith. Provider credentials come from web flows or API keys: autolith auth chatgpt, gemini, grok, nous, anthropic, fireworks, opencode, openrouter and mistral are all listed as subcommands, then you start it with autolith. Updates are (update) inside the image or autolith update in your shell. Note what is missing: no version pinning is shown for the curl path, so the installer gives you the packaged release for your platform, not a release you chose.
Where the design costs you
The failure mode is not that self-modification breaks the agent, since generations and the recovery image are meant to cover that. It is that the agent's state is now something you have to reason about. An agent whose tools live in a mutable image is harder to reproduce than one whose tools live in a versioned config file, and the README does not document an export or diff format for those generations. The release history reinforces the point: v0.47.1, v0.48.0 and v0.49.0 all landed within five days of each other. That pace is fine for a tool you drive interactively and fine if you track master, but it is a poor fit for a pinned pipeline. The other boundary is platform. Windows has no packaged release, so a Windows user is on a source checkout and a PowerShell bootstrap. If your team is mixed-platform, that asymmetry is the first thing you will hit.
How it differs from a harness-plus-tools agent
Aider is the useful comparison because the difference is architectural rather than cosmetic. Aider is a Python application that edits your repository through a git-aware diff loop: the model proposes changes, the tool applies them, git records them. Autolith's unit of change is the running Lisp image, and the tools the model calls are the same forms you can type at the prompt. That is why the README can say a plain message is sugar for (prompt "...") and that delegation is (prompt :to 'test-review "Run the focused tests and report only failures."), with the child's next useful reply returning to the primary terminal. In Aider, a sub-agent is a separate process you coordinate. In Autolith, it is a form with a :to parameter. If you want diff review as the safety mechanism, Aider gives you that directly. If you want one evaluator shared by you and the model, Autolith is the one making that bet.
Licence, maintenance and what to check first
Autolith is ISC licensed, a permissive licence that is short and close to MIT in effect. That matters here because self-modifying agents invite questions about what you are allowed to redistribute and modify, and a permissive licence removes most of that friction. This is not legal advice; read the ISC text yourself, and note that the README does not state a separate licence for the bundled runtime or for provider SDKs pulled in at auth time. Maintenance cost is the real question. The commit history shows active work, the project is not archived, and there is a Zulip instance at zulip.lambda-symbolics.com for questions, with the README warning that confirmation emails often land in spam. What is not in the material: any statement about a support window, a stable tool API, or how long an image generation is retained. If you adopt this, decide early whether you pin a binary release or follow the curl installer, because those are different upgrade contracts and the README only documents the second one.
Editorial conclusion
Autolith fits engineers who already work in Common Lisp or SBCL and want an agent whose tools, prompts and scripts share one evaluator, on Linux, MacOS or a BSD with a packaged release or Nix. It is the wrong pick if you want a language-agnostic agent that runs from a single static binary on any host, or if you cannot accept that the agent's own image is a mutable artefact you must version. Before adopting, verify two things: that the release cadence (v0.47.1 to v0.49.0 inside five days) matches your tolerance for churn, and that the Windows source-checkout path through script\bootstrap.ps1 and bin\autolith.cmd works on your machine, since that platform has no packaged binary.
Community notes