A Rust UI Framework That Lets Your Coding Agent Check Its Own Work

If you've ever watched a coding agent confidently write UI code it can't actually see, you know the problem. It generates a layout, declares victory, and you're the one who discovers the button is off-screen or the text is clipped. Rune takes a different approach: it's a Rust UI framework where every app can run headless, so an agent can render to PNG, dump the element tree, and drive it with scripted input to verify what it built.

What It Does

Rune is a native, GPU-rendered UI framework for Rust targeting macOS, Windows, Linux, and the web. It ships with its own renderer, text stack, layout engine, and spring-based motion system—no dependency on platform UI toolkits or a browser engine to do the heavy lifting.

The API is a declarative view function that returns an element tree. You compose elements with a fluent builder style: set sizes, radii, fills, focusability, accessibility roles, and press handlers inline. In the example from the README, a toggle switch is built from a couple of elements, a theme token lookup, and an on_press closure that flips state. Layout primitives like col() with w_full(), h_full(), and center() handle positioning, and animation comes from named motion presets like motion::SNAPPY.

The headless capability is the architectural decision that matters most here. Because rendering isn't tied to a window, the same app code can produce PNGs and expose its element tree for inspection—which is exactly the feedback loop an agent needs.

Why It's Cool

• The agent workflow is the headline, not an afterthought. The README doesn't just mention headless mode in passing—it builds the onboarding around it. You're told to hand the repo to your coding agent, point it at examples/hello, and let it verify its own work by rendering PNGs and inspecting the tree. That's a concrete, testable loop instead of "trust me, it compiles."

• It's genuinely self-contained. Own renderer, own text, own layout, own springs. That's a lot of surface area to maintain, but it means consistent behavior across four platforms and—crucially—no windowing dependency standing between your agent and a screenshot.

• The element tree is inspectable by design. Scripted input plus a dumpable tree means an agent can not only see what rendered but interact with it and confirm state changed. That's closer to real UI testing than most frameworks offer out of the box.

• The code style is compact without being cryptic. A full interactive switch with accessibility metadata, focus handling, and animation fits in about a dozen lines. Theme tokens (tok::theme(true)) keep light and dark modes honest.

• The contribution model is unusual and consistent with the pitch. No pull requests—you have your agent open an issue describing the bug or idea, and their agents turn it around. Whether you love or hate that, it's a coherent stance for a project built around agent-driven development.

How to Try It

Rune is pre-release, so you'll pin a revision of the dev branch (the README notes dev is never rewritten, so a pinned rev stays valid).

1. Add it to your Cargo.toml:

rune = { git = "https://github.com/anomalyco/rune", rev = "<dev rev>" }

1. Clone the repo and look at examples/hello as your starting point. The framework docs live in crates/rune/README.md, and the component library is documented in crates/rune-kit/README.md.

2. If you want to try the agent workflow, give your coding agent the repo and a prompt along these lines:

Build me a <thing> with Rune (github.com/anomalyco/rune). Start from examples/hello and check your work headlessly.

Then let it render PNGs and inspect the element tree to iterate. There are also examples covering chat interfaces, split diffs, settings windows, and GPU effects like liquid metal if you want to see what the renderer can do.

Everything's at github.com/anomalyco/rune, MIT licensed.

Final Thoughts

Rune is early, and the README is upfront about that—pre-release, pinned revisions, docs spread across crate-level READMEs. The self-contained renderer is an ambitious bet, and the no-PRs policy won't suit everyone. But if you're building tooling where an agent needs to verify UI output rather than guess at it, the headless-first design is the most interesting thing here. Worth a look if you're working at the intersection of Rust and agent-driven development.

Follow @githubprojects for more developer tools and open source projects.