Most "host an agent" posts start with a feature list. This one starts with a number.
npm install -g @kilocode/cli does not install Kilo Code. It installs a launcher. The launcher's postinstall step then reaches out and downloads a platform-specific binary of roughly 162MB — about 221MB once it has unpacked on disk. On x86 it inspects /proc/cpuinfo first and chooses between an AVX2 build and a non-AVX2 build. It also ships its own bwrap (bubblewrap) for sandboxing.
That is not a criticism. It is a well-built native agent. But it tells you something useful: Kilo Code wants a real machine.
The laptop problem
A quarter of a gigabyte of agent runtime is fine on a workstation you never close. It is less fine when:
- You close the lid and the long-running task dies with it.
- You want the same agent, same state, reachable from a phone.
- The agent runs shell commands, and you would rather that not be your primary machine.
- You are running several agents at once and they are fighting over the same CPU.
The bubblewrap detail is the tell. Kilo bundles a sandbox because a coding agent executes things. A sandbox inside your laptop is a process boundary. It is not a hardware boundary.
What we actually run
jurniti gives the agent its own computer — a Firecracker microVM, the same isolation primitive AWS uses for Lambda. Not a container, not a shared box with your neighbours' agents in adjacent namespaces.
Concretely, on provision you get:
- A fresh Ubuntu microVM with
kiloalready onPATH. The 162MB binary is pre-baked into the harness image, so you are not waiting on a download at first boot. - A live in-browser terminal. Run
kilo auth login, pick your provider, and go. - A persistent home directory that survives stop/start and reboots — your config at
~/.config/kilo/, your agent's working state alongside it. - Pinned CPU and RAM. Your reservation, not a slice you contend for.
BYOK throughout. Kilo addresses models as provider/model across 500+ of them; you bring the key and it never leaves your VM.
The bit people miss: one-shot runs compose
kilo run -- "your task" is non-interactive. That is more interesting than it sounds, because it means the agent is scriptable — and once it is scriptable, one VM stops being the unit of work.
jurniti's swarm dispatch fans the same one-shot command across many microVMs at once, each isolated, each with its own reservation. Ten Kilo agents working ten problems in parallel is a command, not an afternoon of setup.
Snapshot it, fork it, share it
Once your Kilo box is configured the way you like — rules, config, project scaffolding — snapshot it into a template. A template forks into a fresh paid VM in about three minutes, carrying that state.
Credentials do not travel. Public templates are scrubbed: the entire ~/.local/share/kilo tree is dropped on capture — that tree holds kilo.db plus kilo's auth files, so we drop all of it rather than guess at one credential path. What survives is the reusable layer — your config and rules, not your keys.
Honest limits
- This is the CLI, not the editor. If your workflow is the VS Code extension against local files, keep using it. Host the agent when you want it off the laptop and always on.
- Terminal-first. Kilo ships
kilo serveandkilo web, but we do not auto-start a web dashboard for it yet — its default port is random and we have not verified the web surface's auth inside a guest. We would rather ship no dashboard than an unauthenticated one on your VM. - No free tier. From $25/mo. The de-risk is a 30-day money-back guarantee on your first purchase, not a trial that expires while you are still evaluating.
Get the box
Managed Kilo Code hosting — $25/mo, BYOK, your own microVM, 30-day money-back.
As of July 2026, Kilo Code sits in the top five by routed token volume on OpenRouter's public app board. Plenty of people are running it. The question is whether it should be running on the machine you carry around.