Rune Is a Rust UI Framework Written for Agents, Not You

The top comment on the Rune thread did not argue. It posted a table.

nicoburns, who maintains Dioxus Native, opened with one line: "maybe skip this vibe coded project."

Then he listed eight Rust GUI frameworks by crates.io downloads. egui at 30.3 million. Iced at 3.2 million. Slint at 2.4 million. GPUI at 447k.

Rune was not on the list.

The thread hit 177 points and 130 comments in a day. That ratio is the whole story.

People did not show up to praise it. They showed up to argue about what counts as a real framework.

I read the whole thing twice. The part that stuck with me was not the download numbers. It was a reply further down.

So it's a UI framework by agents, for agents?

That is not a joke. It is close to a literal description of the repo.

What Rune actually ships

Rune is a Rust UI framework from Anomaly, the team behind OpenCode. It has its own renderer, its own text stack, its own layout, and its own spring animation system. macOS, Windows, Linux and web from one wgpu backend.

The stack list is unusually specific:

• wgpu for the GPU layer
• Taffy for flex, grid and block layout
• Parley, HarfRust, skrifa and fontique for text
• AccessKit for accessibility
• one instanced SDF quad pass plus a glyph atlas for most drawing

The goal in their own PLAN.md is "SwiftUI-on-iOS at 120 Hz." Springs are analytic tracks with duration and bounce. The render thread owns the presented tree and retargets with velocity instead of re-rendering views on the main thread.

That last part matters more than it sounds. Most Rust UI frameworks animate by rebuilding the view. Rune animates on the render thread and lets app code state a target.

The example code is another matter. Here is the toggle from the README:

let switch = el().key("switch").role("switch").label("Lights")
    .checked(s.on).focusable(true).size(38.0, 22.0).radius(11.0)
    .fill(if s.on { tok::accent(0, true) } else { t.control_off })
    .motion(motion::SNAPPY)
    .on_press(|s: &mut State| s.on = !s.on)
    .child(knob);

A commenter on HN put it better than I can: "egads man! It literally hurts my brain trying to parse it." He said he'd rather have Perl 5 line noise.

I don't hate it as much as he does. But I did have to read the absolute() line three times before I understood the knob was being positioned by hand.

The Electron comparison is the easy one

Electron bundles Chromium and Node into every app. You get a mature UI stack and you pay for it in RAM. That trade is old news.

The interesting number comes from Cap, the screen recorder. It moved from Tauri to GPUI in 0.6.1. On an M4 Max, release builds, four runs each:

Build	CPU	Memory
Tauri	76.6%	3,724 MiB
GPUI	17.5%	440 MiB

That is not a small delta. Cap's own report notes the win came partly from a redesigned path, where video frames stay on the GPU on macOS. Still, the direction is clear.

Discord's CTO announced on November 4 that the new desktop client uses GPUI. Discord is one of the biggest Electron apps on the planet. When that team moves, people notice.

Rune is aiming at the same target from a different angle. The flagship test in the plan is recreating OpenCode Desktop in Rune.

Which is a strange thing to put in a roadmap.

The GPUI section is the most honest part

Here's a question people always ask: why not just use GPUI? Zed built it, it works, it's fast.

Rune's plan answers that with a list of specific failures. Their team rebuilt the same small surfaces three times in ten days.

A pill went GPUI, then hand-written Metal, then a SwiftUI helper process. The reasons they give:

• no backdrop or glass, because GPUI draws one forward pass into one layer
• the Metal pill dropped 85 frames on finish until it got its own display-link thread
• window and focus behavior wrong for HUDs and launchers
• text looked thin, and unseen glyphs stalled the first frame by about 13 ms
• no springs, so every app hand-rolled them
• upstream frozen at 0.2.2

Their verdict: don't fork GPUI. Start fresh and lift the good parts under Apache-2.0. Rope, sum_tree, BoundsTree, the line cache, the macOS IME code.

I believe the list. It reads like someone who got burned, not someone writing marketing.

And then a reply on HN quoted Dax from Zed: "we just couldn't get gpui to look good enough." I can't verify that beyond the comment. But it fits the mood of the thread.

The part nobody else is doing

Rune's real bet is not the renderer. It's who writes the code.

From the README: "We don't take pull requests. Have your agent open an issue describing the bug or idea, and our agents usually turn it around fast."

Every app can run headless. An agent can render to PNG, dump the element tree, and drive scripted input. The accessibility tree and the agent inspector tree are the same tree.

That is genuinely new. I have not seen another UI framework ship that as a first-class feature.

And this is where the thread turned. One comment: "why are we giving more accessibility to agents than to like disabled human users?" Another asked if it was a framework by agents, for agents.

I don't think that's unfair.

---

The name is a mess

There is rune.build, a Go IDE that open sourced under GPLv3 two months ago. There is rune-rs, an embeddable dynamic language for Rust.

There is RuneScape. There is a viking game.

On the Reddit thread for the Go IDE, someone wrote "oh wait it's another Rune." Another person: "calling your C IDE Make."

I went looking for reactions to the UI framework and landed in a thread about a text editor written in Go. Two projects, one word, zero overlap. That's an afternoon gone.

The search results are just as bad. Half of my queries returned the language, the IDE, or RuneScape lore videos.

Who this is actually for

Rune is pre-release. The install line is a git rev of the dev branch. There is no crate on crates.io you should trust yet.

The docs are written for agents. A commenter called the README "more of a DONTREADME." He wasn't wrong. I read it and came out knowing less about building an app than I did going in.

If you are building a product this quarter, do not use this. Use egui, use Iced, use Tauri, use Qt. Something with a version number and users.

And if you're on Windows with no GPU fallback, ask what happens. The thread asked that and never got a clean answer.

Rune is for Anomaly, and for people who want to watch a bet get made in public.

One more thing the thread kept circling. There is no live demo on the site.

For a framework whose pitch is feel, that is a strange gap. Someone replied to that point with just: "And no live examples..."

That's the thing I'd fix first. Before tests, before docs, before the crate. Put the toggle on a page and let people click it.

The line I keep coming back to

Someone sat down and wrote documentation for a UI framework and decided the reader would be a model. Not a person learning layout. Not a contributor.

A process that renders PNGs and checks its own work.

But I keep thinking about the headless thing. An agent that can see its own output is a small idea with a long tail. Every framework will want that in two years.

I don't know if this is the future or a very expensive way to avoid writing docs for humans. But it's the first time in a while that a framework made me stop and ask who software is actually for.