Most agents can "self-improve" in the small ways: a memory file, a skills directory, a prompt tweak.
Exo can rewrite the harness it is running on.
Not as a stunt. As the architecture. A trusted substrate (event log, secrets, sandboxes) sits underneath. Everything the agent is allowed to change — prompts, tools, executor policy, even TypeScript harness code — sits above it. Failed experiments rewind. Successful ones stick. Alex Krentsel has described the split as giving the model a body it can actually operate on.
That is a different product from a coding CLI. It is also a different persistence problem: if the install tree lives on an ephemeral rootfs, every reprovision throws away the self-improvements. So on jurniti the tree lives on persist.
The laptop problem
A recursive harness on the machine that holds your keys is a category error.
- The agent has a shell and can edit its own code.
- You want that loop to keep running when the laptop lid closes.
- You want tomorrow's SELF.md to still be yesterday's work, not a fresh clone.
Exo's own docs start from "one setup script to a running agent." Setup on a laptop still leaves you babysitting a process. The managed version is not more UI. It is the same harness, left on, isolated, with a disk that outlives the process.
What we actually run
jurniti gives Exo its own computer — a Firecracker microVM. Not a container. Not a shared kernel.
On provision you get:
- A fresh Ubuntu guest with
exoonPATH. The pinned checkout, toolchains, and built binaries are pre-baked. - A live in-browser terminal. Write YOUR key to
~/exo/byok.env, then runexo. - Persist at
~/exo— SELF.md, the TypeScript harness the agent rewrites, scheduler state. A reprovision keeps them. - Docker in-guest as the default sandbox backend. Nested Firecracker is not required and is not enabled.
BYOK throughout. We never proxy model spend. The bake-time dotenv is a structural placeholder so unattended install cannot hang on a secret prompt. It is not a real key, and jurniti env set writes the BYOK file that wins.
The relay stays off
Exo can speak through a vendor ExoChat relay. A managed box must not ship that on by default, and a fork must not inherit the original owner's channel identity.
The shipped config names no vendor host. The wrapper launches --template minimal. Capture drops .exo/ adapter sessions and the host secret store. If you turn the relay on, that is your data and your choice — it still will not ride a public fork.
Snapshot it — later
Public templates for Exo are vetoed until a live capture canary has proven the scrub: no key, no ExoChat session, no canary in a kept file. A forker executing another tenant's rewritten harness is a supply-chain surface this gallery has never had. The veto stays until that evidence exists.
Honest limits
- Rolling upstream. No tags, no releases. package.json says
0.1.0forever. We pin a commit and bump by hand. - Terminal-first. There is no guest-bound dashboard to proxy. You work in the in-browser terminal.
- No free tier. From $25/mo. The de-risk is a 30-day money-back guarantee on your first purchase, not a trial.
Get the box
Pick a plan, choose Exo, pay. The VM is up in a few minutes. Then:
printf 'OPENAI_API_KEY=sk-your-key\n' > ~/exo/byok.env && chmod 600 ~/exo/byok.env
exo
