The dangerous part of most coding agents is that they forget. Autolith has the opposite problem: it remembers enough state to keep changing itself after you close the terminal.

Autolith live-runtime project visual

That is the pitch behind Autolith, a Common Lisp programming agent released as v0.35.0. It can inspect a repository, edit files, run tests, and keep project context like other terminal agents. The unusual bit is the resident Lisp image underneath. The agent can inspect and replace functions, methods, classes, macros, and settings in its running process, then exercise the change, discard it, or save it as a private image commit.

This is a much more interesting design than another shell wrapper around an LLM. It is also a much worse place to be casual with permissions.

Safe install choices

The first choice is not which model to connect. It is whether the agent gets to evaluate code at all.

Autolith's own documentation is unusually direct about this. Model-generated code runs with the user's privileges. The process boundaries are there for reliability, not to turn the program into a hostile-code sandbox. That one sentence should decide how you test it. A repository with disposable fixtures is a reasonable starting point. A checkout containing cloud credentials, production deployment keys, or personal SSH material is not.

The project page lists binaries for Linux x86-64, Linux aarch64, macOS arm64, FreeBSD x86-64, NetBSD x86-64, and OpenBSD x86-64. The v0.35.0 bundle carries SBCL 2.6.6, its Lisp dependencies, and native helpers. Linux has both glibc and musl builds. The page recommends Nix when you want the complete build pinned from the beginning, while the quick installer is:

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

I would not pipe that installer into a shell on a machine that matters. Read it first, or use the documented Nix route:

nix run github:luciusmagn/autolith -- auth
nix run github:luciusmagn/autolith

For the first inspection pass, use immutable mode:

autolith --immutable

In that mode, the project says the agent keeps read-only inspection and recovery information but withholds evaluation, mutation, persistence, checkpoint, and rollback tools. That makes it useful for learning how the agent sees a codebase without handing it a loaded code-rewriting mechanism.

The provider list is broad enough for experimentation: ChatGPT Codex and Grok subscriptions, Fireworks AI, Anthropic's pay-per-token API, OpenCode, and other OpenAI-compatible endpoints through the REPL. The provider choice affects cost and answer quality, but it does not change the local security boundary. A clever model still receives the same user privileges.

What the live runtime buys you

Autolith's best demo is not code generation. It is state that survives the model context window.

One captured session gives the agent a 3.1 MB concatenation of 121 Lisp source files. The corpus never enters the root prompt. Instead, rlm.complete interns it as a content-addressed object and gives the model a label, size, and digest. The agent then drives a heap-isolated Lisp environment through bounded searches and sub-inferences. The recorded run used a budget of 32 calls and 400,000 tokens, finished in 3 minutes 15 seconds for the answer, and returned all 83 condition classes grouped across 14 subsystems. The whole session took 4 minutes 36 seconds.

That is a useful pattern for codebases that are awkwardly larger than the model's context. The system treats the repository as an environment to query, not a giant prompt to paste into a chat window. It also leaves a readable inference trace, which is more useful than a final paragraph claiming that the agent “looked through everything.”

The more consequential feature is live mutation. In another captured session, the agent changed a duration formatter in the running image, tested values including 59 seconds, 61 minutes, and 26 hours, and committed the result privately. The private commit contains a manifest and an executable Lisp replay script in a separate private Git history. It does not quietly patch the tracked repository source.

Then the demo deliberately breaks the function. The bad definition kills the active process. Autolith writes a crash capsule, boots a pristine recovery image, restores the conversation, and opens a read-only diagnosis turn. The documented run took about 6 minutes, including the crash and recovery boot. The committed version survived the process that authored it.

That is a real distinction from the usual edit, run, and restart loop. A normal coding agent treats the process as disposable. Autolith treats the running process as part of the artifact. This can make exploratory work faster because a useful change does not need a full restart, but it also means the agent's state has another lifetime to audit.

The design keeps several lifetimes separate: conversations, memories, agendas, private image commits, saved generations, worker images, and recovery state. That separation is the part I would want to inspect in the source before trusting it. Persistence is only helpful when you know exactly what is persisted and which state becomes active after a restart.

Failure modes worth testing

The first failure test is mundane: start in a directory with a fake secret file and ask the agent to search for credentials. If it can read the file, you have confirmed the warning. Do this before connecting a paid provider or giving it a real checkout.

The second test is a mutation boundary test. Run immutable mode and verify that an attempted function replacement is refused. Then run normal mode in a throwaway repository and ask for a tiny change that can be checked with an assertion. Confirm the journal, diff, and rollback behavior before trying a change that touches the actual application.

The third test is the one most demos avoid: kill the process while a mutation is pending. The official recordings show that Autolith has crash capsules and pristine recovery images, but a captured happy path is not the same as an operational guarantee. Check what is restored, what is marked pending, and whether the next session can distinguish a committed mutation from a disposable experiment.

The fourth test is provider failure. Disconnect the API after a tool call, resume the conversation, and inspect whether the local state remains understandable. A resident agent should fail in a way that leaves a human-readable trail, not leave a half-applied change that only the model knows how to explain.

Finally, test repository state separately from image state. The project explicitly says a private image commit can change the active agent without quietly patching the tracked source repository. That sounds sensible, but it creates two versions of “the code”: the files in Git and the definitions currently loaded in the Lisp image. Before you merge anything, restart from clean source and prove that the behavior comes from the tracked change rather than an invisible private mutation.

This is where Autolith differs from a parallel-agent supervisor. A supervisor controls several disposable workers. Autolith gives one agent a durable, inspectable runtime that can change its own loaded environment. If you already use a local supervisor for parallel agents, the same principle applies here: make the state transition visible, keep the workspace narrow, and put a human approval step before anything that can reach production.

My decision is simple. Autolith is worth trying for Common Lisp work, codebase archaeology, and experiments where a live image is genuinely more useful than repeated restarts. It is not a security sandbox, and it should not be installed as one. Start with immutable inspection, use a fake repository, verify recovery by breaking something on purpose, and only then allow live mutation. The feature is powerful because the agent can keep a world around. That is also the reason the world needs boundaries.

Sources