Rune 0.2.0: frozen, independently verified Cargo builds and an honest learning preview

What Rune is

Rune describes itself as a learning toolchain for Rust and labels itself an architecture preview. Put simply, it wraps Cargo. You approve a build plan once, Rune replays that exact plan offline, and a second clean rebuild checks that the result is byte-identical. Optional steps let a model propose a change, but the proposal is only data until a separate evaluator and a person approve it.

The repository was created on October 26, 2026, and released 0.1.0 and 0.2.0 the same day, under the MIT license. The binary is called rune, but the crates.io package is rune-toolchain, because the names rune and rune-cli belong to the unrelated Rune scripting language. If you have rune-cli installed, the two binaries collide on your PATH.

What shipped

Version 0.1.0 (18:46Z) delivered phase 1 of the project's ADR 008: frozen plans, offline replay, independent verify, explain, rollback, and a bounded OpenRouter proposal flow that never applies what it proposes.

Version 0.2.0 (21:17Z) adds the following, according to its release notes. All seven crates were published to crates.io at 0.2.0.

• rune edit applies an explicit edit, through pinned Agent Booster 0.2.2 or a built-in exact replace. A stale source hash, a path or symlink escape and oversized files are refused before anything is written.
• rune eval builds baseline and candidate in isolated copies, runs the visible tests, then a hidden holdout, then paired benchmarks, with explicit security gates.
• rune recipes stores and ranks past recipes by workload, hardware and policy fingerprint. The README is explicit that ranking is never approval.
• rune promote binds an approval to the exact tested artifact, target, compiler, policy and contract; changing any of them invalidates it.
• rune target, rune package and rune verify-artifact cross-build, classify execution evidence and write a signed or unsigned evidence directory.
• rune cleanup is a dry run by default and quarantines unreachable generated objects, never source.
• rune improve gains a cost ledger: the budget is reserved first, settled with the provider-reported cost and released on failure.

What the project measured, and what it did not show

The project reports these results from its own tests on one x86_64 Linux machine. They are the maintainers' figures for a fixture, not benchmarks of your code, and we did not reproduce them: rune build produced the same artifact SHA-256 as plain cargo build on an unchanged fixture; a fixture distance kernel ran 3.51 times faster (95% CI 3.511 to 3.513, 40 paired samples); candidates that dropped the final partial chunk, added unsafe code, used std::net or added a dependency were rejected; and two live rune improve campaigns cost $0.0221 in total.

The release is just as direct about the gaps. Its preregistered control study (34 kernels, 8 recipes, 111 evaluations) concluded "Insufficient — learning not demonstrated", because the learned library held only as many recipes as the budget allowed, so both arms evaluated the same ones. Also not met: RVM execution, RVF packaging, MetaHarness integration, real aarch64 hardware (aarch64 and WASM runs were emulated) and large real-world workspaces. Evaluation reports are unsigned.

Update: a later, narrower confirmation on main (October 27)

After the 0.2.0 release, PR #15 merged to main on October 27 at 02:08Z (commit 25d9ee6). It is later code and documentation, not part of the October 26 release or its published crates. Its PROOF.md keeps the earlier results on the record: the 34-kernel study's Insufficient and a 36-case pilot's NoDifference.

It separately reports a preregistered confirmation with the verdict Better, scoped to choosing a sorting algorithm in twelve synthetic contexts across 288 fresh input draws. Frozen training memory succeeded in 154/288 cases (53.47%), against an expected 35.53% for uniform random choice and 106/288 (36.81%) for the fixed algorithm chosen from training. The result file itself says this is "not general self improvement".

Maintainer reported, not reproduced here. This is workload-specific algorithm-selection success, not an application runtime speed-up, general self-improvement, independent reproduction or production isolation. The maintainers note a shared host, a degraded-isolation evaluator mode and within-family context reuse as limits on generalization.

Get started

Prerequisites: Rust 1.88 or later and a Cargo workspace with a committed Cargo.lock. No API key is needed for building and verifying. The commands below are the README's quick start. Expected result: build --freeze approves a plan and builds offline, recording an artifact digest and a receipt that says model calls = 0; verify rebuilds in a fresh target directory and compares digests. If you then edit a source file, rune build refuses with stale plan: source_digest until you approve again with --freeze. Exit codes are 0 for ok, 1 for failure or rejection and 2 for missing credentials.

Documentation verified only. We read the release notes, the README at the v0.2.0 tag and the crates.io record, but did not install the crate or run these commands.

cargo install rune-toolchain

rune build --freeze

rune verify

rune explain

MCP and skills: the README documents no MCP server and no npx skills setup, so none is given here. rune improve, the only command that calls a model, needs OPENROUTER_API_KEY in the environment; without it the command exits 2 before any ledger write or request. Only run it with a budget you accept.

Use it today

Input: a Rust service with a committed lockfile. Workflow: freeze a plan on the release branch, run rune verify in CI, and treat a stale-plan refusal as a signal that the inputs changed since approval. Output: an artifact digest and a receipt you can attach to the release, plus a rollback to the previous approved plan if needed.

Acceptance: in a clean checkout, rune verify reports a digest identical to the one recorded by rune build; any change to a source file makes rune build refuse until a new plan is frozen.

Experimental commentary — acceptance test

One idea is to share the recipe library across a team so a proven speed-up for one crate is suggested for similar ones. Limitation: the project's own study did not demonstrate learning, and ranking is never approval, so every suggestion must still pass rune eval and rune promote. Falsifiable test: replay the project's control design on your own kernels with a library larger than the evaluation budget, and accept the idea only if the learned arm beats the control arm on the hidden holdout. We have not run this.

Limits and verification

• Rune is an architecture preview released on the day it was created. Expect changes.
• The October 27 confirmation is on main after v0.2.0; it is not evidence about the published 0.2.0 crates.
• All figures are the project's own, from one machine and fixtures. No result here was reproduced by the newsroom.
• ruvnet/rune was created after the October 19 repository inventory snapshot, so it is not yet counted in the project directory.