Choreographr v0.1.0 Released — Choreographr Blog

Giving an LLM shell access is a perfectly valid choice — for developers and power users. You understand what the model is doing, you can review its commands, and a coding agent with a terminal is genuinely useful.

The problem comes when there is no one to review. Autonomous agents prompted by regular users — research agents, personal assistants, business agents — need the complete protection of a sandbox, because no one is watching what the model does between prompts.

Choreographr is built for both. Developers and power users can give it shell access and work the way they always have; for everyone else, LLM-generated code runs in a sandboxed RISC-V VM instead — an isolated environment with no host memory, no raw syscalls, and no filesystem access except through registered, logged tools. Around that core sits a persistent server that lets clients — terminal, desktop, Telegram, editor — come and go, written in Rust so it stays lean, memory-safe, and honest about everything the agent did. The first release, v0.1.0, is out now.

Try it now — no Rust toolchain needed. Prebuilt binaries ship for macOS and Linux: Homebrew on macOS, .deb/.rpm or a static tarball on Linux. Then it's a few commands to your first conversation:

# macOS — Homebrew
brew tap choreographr/choreographr
brew trust choreographr/choreographr
brew install choreographr
choreographr   # terminal 1 — the server
choreo-tui     # terminal 2 — the terminal client

Homebrew 6.0 and later refuse to load non-official taps until they are explicitly trusted — loading a tap can run Ruby code from it, so brew trust is how you tell Homebrew you've reviewed and accepted this one.

See the installation guide for every platform, and the quick start for your first prompt.

So why another agent?

There are already very good agents — Codex, Claude Code, OpenCode, Pi, Openclaw, Hermes, and more. Choreographr exists because three things matter that few agents deliver together:

Safety by design — model output runs in a sandboxed VM, not an unlogged shell, and every tool call is recorded.
A server that owns your sessions — clients come and go; start a task in the terminal and check on it from your phone.
A core that can be trusted to run for months — Rust: memory-safe by construction, and light enough on CPU and RAM that you stop noticing it.

The rest of this post digs into those three, and there's a feature-by-feature comparison on the homepage if you want the table view.

A sandbox, not a shell

An agent with shell access can do anything — and with a careful developer in the loop, that is exactly what makes it useful. It only works because someone is watching. Hand the same agent to a regular user who can't review every command, and "it can do anything" becomes a recipe for disaster: no easy way to see what the model is doing, no reliable log of what it has done.

Choreographr replaces the shell with a RISC-V virtual machine. Instead of issuing tool calls at the end of each turn, the model writes a small script (in Rust, compiled to RISC-V) that runs inside an isolated VM with its own flat memory: no host syscalls, no host filesystem access, no raw shell. Every tool call the guest makes is dispatched through the same typed ToolRegistry the host agent uses — including subsessions — and every call is logged. Secure by design rather than bolted on, and fully observable.

The VM in action

Here's what that looks like in practice. I asked the agent to use the riscv-vm tool — the prompt below is the one I typed into choreo-tui:

Use the riscv-vm tool to run a rust program that programatically generates a beautiful, detailed and colorful geometric design in a SVG and show it to me. Only use integer math.

The agent writes a small Rust program, the server compiles it to RISC-V and runs it inside the sandboxed VM, and the generated SVG comes back as a file the TUI renders inline:

choreo-tui: the riscv-vm prompt typed into the session

choreo-tui: the agent writing the Rust program

choreo-tui: compiling and running the program in the RISC-V VM

choreo-tui: the generated SVG rendered inline in the terminal

choreo-tui: the finished session

And this is the SVG the VM produced — a geometric mandala drawn entirely with integer math:

Geometric mandala SVG generated by a Rust program running in the RISC-V VM

One server, every surface

Most agents are a single process with a single UI. Choreographr is built the other way around: one server owns your sessions, and clients connect and disconnect whenever they want.

choreo-tui — a full-screen terminal UI with O(1) scrolling and streaming, markdown rendering, syntax highlighting, and a model selector. It also renders images inline in your chat — PNG, JPEG, and vector SVG — using the kitty graphics protocol or sixel where supported, with a universal fallback everywhere else, plus click-to-open fullscreen viewing.
choreo-gui — a desktop app (Dioxus), in development.
choreo-im — chat with your agent on the go, from Telegram.
choreo-acp — drive sessions from ACP-compatible editors like Claude Code and Cline.

Because sessions live in the server, you can start a task in the terminal and check on it from your phone. Everything persists in an embedded redb database and survives restarts.

Choreographr architecture: clients (TUI, GUI, IM, ACP) and the server handoff connect to the choreographr server, which talks to model providers and runs MCP servers, a RISC-V VM sandbox, and a redb database

Rust, because it has to last

Most agents are written in JavaScript or Python — and it shows, both in how much CPU and RAM they burn and in what it means to run one for weeks while it holds your API keys. Choreographr's core is pure Rust for three reasons:

Memory safety by construction — no null dereferences, use-after-free, or buffer overflows; the compiler rejects them before they exist. A long-lived server that holds your keys and runs untrusted model output should not be one segfault away from a problem.
Threads, not async — the server uses real OS threads with message passing; each session owns its state, with none of the shared-state and cancellation complexity an async runtime brings.
Lean enough to ignore — agents are I/O bound, and Choreographr stays light on CPU and RAM so you barely notice it's running. Your builds, of course, are another story.

The Why Rust? page goes into the details.

Blockchain native

Choreographr has native tool calling for Ethereum (EVM) and Polkadot (Substrate), compiled into the release binaries. From any session you can read balances, inspect blocks and transactions, make read-only contract calls, resolve ENS names, and query Substrate storage — see the blockchain tools reference. Solana support is on the roadmap.

Why this matters:

Using AI to read and write the blockchain is incredibly powerful — a DeFi trading bot, for example.
Agent coordination: today agents collaborate through centralized services like GitHub, which is proving unreliable. On-chain coordination is the natural next step.
Existing on-chain publishing technologies, like my other project Acuity, are a perfect fit for agents.

It will also be possible to pay for model access with cryptocurrency directly in the TUI/GUI.

And everything else

The rest of the feature list in brief:

70+ model providers — OpenAI, Anthropic, Mistral, DeepSeek, xAI, Groq, Ollama, OpenRouter and more, via OpenAI-compatible, Anthropic Messages, and Gemini APIs.
Concurrent sessions & subsessions — the server runs many sessions in parallel on real threads, and any session can spawn hierarchical subsessions through a tool call.
Encrypted credentials — every key is encrypted at rest with X25519 ECDH + AES-256-GCM; the server starts locked and decrypts in memory only after unlock. See security.
Agent database — a persistent, session-scoped key-value store (redb) the agent writes to and reads back. See database tools.
MCP client — spawn Model Context Protocol servers, discover their tools, and call them from any session.
ACP bridge — drive sessions from ACP-compatible editors like Claude Code and Cline.
Undo/redo per session — if the agent mis-steps, remove the prompt instead of prompting more.

What's next

Subsessions already exist; here's what's on the roadmap:

Git worktrees — each subsession works on its own branch, so parallel agents can share a codebase without colliding.
Cron — save RISC-V programs and run them on a schedule.
Extensions — hook into the server over a local socket to add tools and plugins.
OS-level sandboxing — Landlock on Linux, Seatbelt on macOS, for tools that must run outside the VM.
Inter-server handoff — pass sessions between servers over Noise.

Ready to give it a spin? The quick start gets you to your first prompt, and the release notes cover what's in v0.1.0.

We'd love your help — star the repo, open issues, and join the Telegram community.