Claurst: a Rust terminal coding agent with multi-provider routing and an ACP mode

What Claurst actually is, and who ships with it

Claurst is a terminal coding agent. You run it in a shell, point it at a codebase, and it works on the code through a TUI. The README describes it as an "open-source, multi-provider terminal coding agent" built in Rust, and says it began as a clean-room reimplementation of Claude Code's behavior from a spec directory in the repository. That origin matters, because it sets expectations: this is not a fork of anything, and the spec folder is the reference the implementation was written against.

The intended user is someone who already lives in a terminal and wants the agent to be theirs to configure. The tagline is "Agentic Coding for Builders who Ship," and the README claims no tracking or telemetry. Multi-provider support is the differentiator: rather than being welded to one vendor's endpoint, Claurst routes across providers you configure. If your reason for looking at it is that you want an agent you can run however you want, that is the pitch.

It is also in Beta. The README states v0.1.7 is "stable enough for daily driving" while warning of rough edges around experimental features. That is the honest framing, and it should shape how you read the rest of this piece.

The mechanism: a Rust core, a TUI, and JSON-RPC over stdio

Claurst is a single binary. The Rust core hosts the agent loop, provider routing and the TUI, and the repository layout puts the implementation under src-rust with the spec alongside it. Configuration lives in ~/.claurst/settings.json, and the README notes that claurst auth login and the in-session /connect command are alternative ways to set credentials. The same credentials and providers are shared between the interactive TUI and the ACP agent, so you configure once.

The editor integration is the most concrete piece of architecture in the documentation. Claurst speaks the Agent Client Protocol, described in the README as the open protocol pioneered by Zed for editor-to-agent communication. An ACP-compatible editor launches Claurst as a subprocess and talks to it in JSON-RPC 2.0 over stdio. The README lists the methods it implements: initialize, session/new, session/prompt and session/cancel. It streams session/update notifications carrying text deltas, agent thinking, and tool calls with their progress and results. Every tool permission is routed through session/request_permission so the editor can render a native approval dialog.

That last detail is the one worth pausing on. Permission handling is not bolted on at the end of the pipeline; it is a protocol method the editor is expected to answer. If your editor does not implement that side of ACP, the agent has nowhere to send the request.

Installing Claurst and running a first query

The fastest path is the install script. On Linux or macOS the README gives a curl one-liner that pipes into bash; on Windows there is a PowerShell equivalent. The script places the binary in ~/.local/bin, or %LOCALAPPDATA%\Programs\claurst on Windows, and adds it to PATH. Open a new terminal afterwards so the updated PATH takes effect.

curl -fsSL https://github.com/kuberwastaken/claurst/releases/latest/download/install.sh | bash

If you already have Node.js or Bun, the npm route works too. The postinstall script downloads the pre-built binary for your platform, and npx or bunx will run it without a global install.

npm install -g claurst

Before the first run you need credentials. The README shows exporting an Anthropic key, and notes that /connect inside Claurst configures the same thing. The settings file at ~/.claurst/settings.json is the other place to put a provider and key.

export ANTHROPIC_API_KEY=sk-ant-...
claurst

For a non-interactive run, Claurst takes a prompt flag. The README's example asks it to explain a codebase, which is a reasonable smoke test: it exercises provider routing and file reading without committing the agent to edits.

claurst -p "explain this codebase"

Upgrades go through the binary itself. The README documents claurst upgrade, and notes that both installers accept a --version flag to pin a specific release if you would rather not track latest.

Experimental surfaces you should treat as unfinished

The README is unusually candid about what is not done, and the list is long enough to matter. /share sends chat sessions to others via unlisted GitHub Gists. Free Mode is offered through /connect as a way to get an agentic coding experience at no cost. /goal takes an objective and keeps the agent working across multiple turns instead of stopping after one. ultracode is the highest effort level, sitting past max in the /effort selector, and it can also be triggered by typing the word into a prompt. It runs a plan, delegate, integrate and verify workflow that fans work out across native subagents, swarms and background tasks.

Every one of those is marked [EXPERIMENTAL] in the README. Take the marking literally. /share in particular moves your session content off your machine and onto a third-party service, which is a different risk category from a local feature that misbehaves. Free Mode depends on an endpoint the project does not describe, so there is no documented basis for judging its reliability or its data handling. ultracode composes with /goal, which means the most expensive reasoning mode can be paired with the longest-running objective mode. That is a combination to try on a small repository first, not on your main branch.

The Beta notice says core agent, multi-provider routing and TUI are stable enough for daily driving, and that rough edges are expected around the experimental features. That split is the useful signal: the routing and the interface are the parts the maintainers are willing to stand behind.

Where Claurst is the wrong tool, and what to use instead

Claurst is a terminal-first agent. If your team works inside an IDE chat panel and does not want a shell in the loop, the ACP route is the only bridge, and it depends on your editor implementing the protocol side that renders permission dialogs. Editors that do not speak ACP have no path in. The README names Zed, Neovim and JetBrains plugins as the class of editors that can drive it, and gives a Zed configuration example, but it does not document a fallback for anything else.

The alternative most readers will weigh is Claude Code itself, and the difference is not cosmetic. Claurst was written against a spec as a clean-room reimplementation rather than being built on the same code, and its distinguishing feature is provider routing: you are not locked to one vendor's API. That cuts both ways. A single-vendor tool has one credential path, one set of provider-specific behaviors and one place for bugs to hide; Claurst's routing layer is exactly the part that has to be correct for every provider you add, and the README does not document per-provider caveats. If you only ever intend to use one provider, the multi-provider machinery buys you little and adds a configuration surface you have to maintain.

There is also the licence question. Claurst is GPL-3.0. If you plan to embed it in a product, that is a conversation to have with someone qualified to have it, not something to settle from a README.

Maintenance, releases and the cost of upgrading

The last push to the repository was on 2026-07-06, which is when v0.1.7 was released. The two releases before it, v0.1.6 and v0.1.5, landed on 2026-06-26 and 2026-06-11. That is a cadence of roughly two to three weeks between releases across that window. The repository is not archived.

What that cadence means for you depends on how you install. If you use the install script or npm, claurst upgrade is a single command, and the --version flag lets you hold a known release instead of moving forward. If you build from source, the cost is a cargo build in src-rust, and the README documents a variant for Raspberry Pi and other systems without ALSA: building with --no-default-features drops voice and microphone support so libasound2-dev is not required. That flag is worth knowing about even on ordinary headless servers, because it removes a system dependency you would otherwise have to install.

The npm path has one failure mode the README does not address: the postinstall script downloads a platform-specific binary, and the README does not document what happens when that download fails or when your platform is not among the listed archives. The manual download table covers Windows x86_64, Linux x86_64, Linux aarch64, macOS Intel and macOS Apple Silicon. Anything outside those five targets has no documented binary.

On licensing: Claurst is GPL-3.0, and the repository carries a LICENSE.md. The GPL's obligations attach to distribution, so running the binary yourself is one thing and shipping it inside your own product is another. The documentation does not discuss this, and it is not a question to answer from an article.

Editorial conclusion

Adopt Claurst if you want a Rust terminal agent you can point at more than one provider and drive from Zed or another ACP editor, and if you are comfortable running Beta software where /share, Free Mode, /goal and ultracode are all flagged experimental. Do not adopt it if you need a stable, fully documented tool, or if you cannot accept GPL-3.0 terms. Before you commit, verify three things: that ~/.claurst/settings.json accepts your provider and key, that your editor launches claurst acp and completes the permission round trip, and that the npm postinstall actually fetched a binary for your platform rather than leaving you with a broken global package.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes