Autolith: a self-modifying Common Lisp agent that lives in a terminal image

What Autolith is for, and who it is not for

Most terminal agents treat the model as the only thing that thinks and the shell as the only thing that acts. Autolith inverts part of that. It runs inside a live Common Lisp image, and the README describes it as able to "observe, self-modify, discover, introspect its own code, its live state and what it's doing." The agent can change the running program it is made of.

The audience is narrow and specific. You need to be comfortable with a Lisp REPL, because the message window is one. You need to accept that the agent may rewrite parts of its own image, because that is the stated design. If your mental model of an agent is a chat box that emits shell commands, Autolith will feel like a different category of tool rather than a variant of the one you already use.

The README is candid that this sounds risky, and answers the obvious objection with generations: Autolith "creates generations of this image your or it can rollback to." The claim is that even a "full frontal lobotomy" is recoverable, because Autolith reloads into a recovery image and can diagnose and optionally fix the problem. That is the central bet of the project, and everything else in the README is downstream of it.

How the live image, the self tools and the lisp workers divide the work

There are three distinct execution contexts, and conflating them is the fastest way to misunderstand Autolith.

The first is the active image. This is Autolith itself, running in SBCL. The self.* tools report on or change this image. The README's example is (self.status), and the documentation describes self.* as the family that "changes or reports the active Autolith image." Live brain surgery, in the project's own phrasing.

The second is the lisp.* family, which runs in named, heap-isolated SBCL workers. These are separate from the agent's image. The README gives (lisp.eval :form "(+ 20 22)" :repl "scratch") and (lisp.describe :designator "APPLICATION" :target "self"). The stated motivation is that Autolith can avoid writing throwaway Python scripts, do the work in its bundled Common Lisp runtime instead, and observe its own scripts more closely. The README also notes that lisp.* can target read-only active inspection explicitly, which matters: inspecting the running image and mutating it are different operations with different blast radii.

The third context is inference. The infer form runs "one bounded inference over context you pass explicitly, returns a Lisp value, and never touches your conversation." Frames recurse, fan out through rlm-map, and can return validated data against a JSON Schema contract instead of prose. Budgets are shared: "Calls, tokens, and recursion depth come out of one shared budget, so a fan-out cannot outspend its allocation." The private frame conversations are kept out of your conversation and, per the README, out of your prompt cache.

The rlm-complete form is the heavy version. 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 it. Inputs larger than the provider context window are handled this way. Every frame persists its own trace under data/inferences/, readable afterwards through inference:<trace-id> URIs. That trace directory is the part worth noticing: it means an inference can be audited after the fact rather than only observed while it runs.

Installing Autolith and running a first inference

The README lists standalone binary releases and Nix for Linux, macOS and the BSDs. Windows is supported from a source checkout through script\bootstrap.ps1 and bin\autolith.cmd rather than from a packaged release.

The curl installer installs or updates the packaged release for your platform. The README explicitly suggests inspecting the installer script before piping it into a shell:

curl -fsSL https://sh.lambda-symbolics.com/autolith | sh

Nix supplies the complete runtime, which is the option to take if you already have a flake-based setup:

nix run github:lambda-symbolics/autolith

Before Autolith can talk to a model, you authenticate a provider. The README lists web flows and API keys as the two routes, and names these providers:

autolith auth chatgpt
autolith auth gemini
autolith auth grok
autolith auth nous
autolith auth anthropic
autolith auth fireworks
autolith auth opencode
autolith auth openrouter
autolith auth mistral

Then start it with the bare command:

autolith

Once inside, the message window is a REPL. Typing prose is sugar for a prompt form. The README's example is that a plain message becomes (prompt "Hello Autolith! how do you do?"), with the :to parameter defaulting to 'autolith. To steer a delegated sub-agent named test-review, you prompt it by name:

(prompt :to 'test-review
        "Run the focused tests and report only failures.")

The README states that the child's next useful verbal response returns to the primary terminal. For work that should not touch your conversation at all, use infer with explicit context:

(infer "List the invariants this file maintains."
       :context (list #p"src/conversation/store.lisp"))

What you should see is a Lisp value returned to the REPL, not a paragraph appended to your chat. That separation is the first thing worth confirming on your own machine, because it is the property the rest of the design leans on.

The recovery story is the weakest documented part

Self-modification is the headline feature and the recovery path is the load-bearing one, so it is worth being precise about what the README does and does not say.

It says Autolith creates generations of the image that can be rolled back to. It says a lobotomy is not a showstopper because AL reloads into a recovery image and diagnoses and optionally fixes the issue. The repository has a recovery/ directory at top level, which is consistent with that description. What the README does not document is the rollback procedure itself: there is no stated command for listing generations, selecting one, or forcing a reload into recovery. The update section documents (update) and autolith update, and those are the only lifecycle commands the README spells out.

That gap is not proof the mechanism is missing. It is proof that the public README is not where the mechanism is explained. Anyone evaluating Autolith for work where a broken image costs real time should read docs/architecture.org and the recovery directory before trusting the one-paragraph summary.

The second limitation is more mundane and easier to miss. The lisp.* workers are described as heap-isolated SBCL workers, and lisp.* can target read-only active inspection. Isolation between workers does not mean isolation from the host. A worker that evaluates a form with filesystem access has filesystem access. The README frames separate REPLs as a way to keep scratch work clean and observable, not as a sandbox, and it should not be read as one.

Autolith compared with an editor-integrated assistant

The obvious alternative for most engineers is an editor-integrated assistant, the kind that lives in a sidebar, proposes diffs and runs commands in your shell. The difference is not which model answers. It is where the agent's own code lives.

In an editor-integrated assistant, the agent is a fixed program. You can configure it, extend it with plugins, and give it tools, but the running agent cannot rewrite its own definition while it works. Autolith can, and the README treats that as the point: the self.* tools exist to inspect and modify the live image, and lisp.* exists so the agent can run Lisp in pristine REPLs separate from that image rather than shelling out to a scripting language it does not control.

A second difference is what the agent's output is. In an editor assistant, the output is usually a diff or a message. In Autolith, the prompt input is a REPL, exact forms can compute prompts or return results, and the README notes that "the model will see them." That makes templating and computed prompts natural rather than bolted on. The README's example of reading a prompt from a file, (prompt (read-file "path")), is one line in Autolith and a wrapper script elsewhere.

The trade is real. An editor assistant starts in seconds and has no runtime to maintain. Autolith carries a Common Lisp image, a set of image generations, and a recovery path that you may need to understand under pressure. The README does not claim otherwise; it describes the project as "pretty close to a Lisp Machine," which is a fair description of both the appeal and the cost.

Maintenance, updates and the ISC licence

Autolith is not archived. The last push to the default branch was on 2026-09-10, and the most recent release listed is v0.49.0 on 2026-09-08, with v0.48.0 two days earlier and v0.47.1 before that. The release cadence visible in the repository is fast, and version numbers in the 0.4x range indicate the project has not reached 1.0.

Updating is deliberately cheap. The README gives two equivalent routes: the form (update) inside the image, or autolith update in your shell. The curl installer also "installs or updates the packaged release for your platform," so re-running it is a third path. That is more update surface than most agents offer, and it means a version bump does not require rebuilding from source.

The licence is ISC, a short permissive licence. It is compatible with proprietary use and imposes few conditions beyond retaining the copyright notice and permission text. This is a description of the licence identifier in the repository, not legal advice; the LICENSE file at the top level is the authoritative text and should be read directly if the terms matter to your organization.

One maintenance detail is worth flagging for anyone building from source. The repository carries sbcl.version, sbcl-source.sha256, sbcl-source-releases.sha256 and sbcl-windows-releases.sha256 alongside flake.nix and flake.lock. The pinned SBCL version and the checksums mean a source build is tied to a specific Lisp implementation release, and those files will need to move together when the pin is updated.

Editorial conclusion

Autolith fits engineers who already work in Common Lisp or SBCL and want an agent whose prompt window is a real REPL, whose tools are callable forms, and whose modifications can be rolled back to a previous image generation. It is a poor fit for anyone who wants a small, single-purpose coding assistant with no Lisp runtime underneath, and for Windows users who will not work from a source checkout, since the README lists Windows support only through script\bootstrap.ps1 and bin\autolith.cmd. Before adopting it, verify three things in your own environment: that the packaged release exists for your platform and architecture, that the provider you intend to use appears in the autolith auth list, and that the recovery behavior described in the README actually triggers the way you expect when a self-modification goes wrong.

Frequently asked questions

Official sources

1. lambda-symbolics/autolith on GitHub
2. License: ISC
3. Project website
4. README
5. Releases