Rust UI framework Rune targets AI agents as its users, and developers push back

What Rune is

According to a dev.to write-up, Rune is a pre-release Rust UI framework from Anomaly, the team behind the OpenCode editor. It targets macOS, Windows, Linux and the web from a single wgpu-backed renderer and builds the rest of the stack itself: Taffy handles flex, grid and block layout; Parley, HarfRust, skrifa and fontique handle text; AccessKit supplies accessibility; and most drawing runs through an instanced SDF quad pass and a glyph atlas.

The project's plan document sets an ambitious bar, aiming for the feel of SwiftUI on iOS at 120 Hz. Springs are analytic tracks with duration and bounce, and animation happens on the render thread, which owns the presented tree and retargets using velocity instead of rebuilding views on the main thread — a departure from how most Rust UI frameworks animate.

The README's sample code is another matter. It packs many configuration calls into single dense expressions, and Hacker News commenters found it hard to parse; one said line-noise Perl would be easier on the brain.

Agents as the intended audience

Two decisions define the project. Rune does not accept pull requests: the README tells contributors to have their AI agent file an issue describing the bug or idea, and the maintainers' agents usually turn it around. And every Rune app can run headless — an agent can render the interface to a PNG, dump the element tree and drive scripted input, with the accessibility tree doubling as the agent inspector tree.

The documentation targets the same audience. One commenter called the README closer to a list of warnings than a guide, and the dev.to author admits to finishing it knowing less about building an app than before. A reply in the thread asked whether this made Rune a framework built by agents for agents — which, the author notes, is nearly a literal description of the repository.

Why the team skipped GPUI

The plan tackles the obvious question — why not use Zed's GPUI — with a list of problems Anomaly hit while rebuilding the same small surfaces three times in ten days: no backdrop or glass effects, frame drops in a hand-written Metal version, wrong window and focus behavior for HUDs and launchers, thin-looking text, first-frame stalls of roughly 13 milliseconds from unseen glyphs, no built-in springs, and an upstream frozen at version 0.2.2. Their verdict was to start fresh and port the good parts — the rope, sum_tree, BoundsTree, line cache and macOS IME code — under Apache-2.0. The roadmap's flagship test is rebuilding OpenCode Desktop in Rune.

The community reaction

The Hacker News thread reached 177 points and 130 comments in a day, a ratio the dev.to author reads as argument rather than praise. nicoburns, who maintains Dioxus Native, opened by questioning whether the project should be taken seriously and posted crates.io download counts for eight Rust GUI frameworks: egui at 30.3 million, Iced at 3.2 million, Slint at 2.4 million and GPUI at 447,000. Rune was not on the list.

Others pressed on priorities, with one commenter asking why agents get richer access to the interface than disabled human users. Practical gaps drew attention too: there is no live demo on the site, installation points at a dev-branch git revision rather than a published crate, and a question about Windows machines without GPU fallback went unanswered. The name also collides with a recently open-sourced Go IDE, an embeddable scripting language for Rust, and a fantasy MMORPG that dominates search results.

The Electron backdrop

The post frames Rune against a wider move away from Electron. Cap, a screen recorder, reported that switching from Tauri to GPUI cut CPU use from 76.6 percent to 17.5 percent and memory from 3,724 MiB to 440 MiB on an M4 Max, though partly because a redesigned path keeps video frames on the GPU on macOS. Discord's CTO announced on November 4 that the new desktop client uses GPUI. Rune is chasing the same native-performance territory from a different angle.

Why it matters

Rune's real wager is not its renderer but its assumption about who writes GUI code next. If AI agents become the primary authors of applications, frameworks built for machine consumption — headless rendering, inspectable trees, issue-based contribution flows — could become a genuine advantage, and the dev.to author expects every framework to want something similar within a few years. The backlash shows the other side of the trade: the same choices can read as neglect of human developers and accessibility users, and nothing should be built on Rune in its current state. Whether agent-first design becomes the norm or a curiosity, the argument it started about who documentation and tooling are actually for is the part worth watching.