Frame: An X11 Server Written in Assembly Using AI
TL;DR
A developer built a complete X11 server in 20,000 lines of assembly language using Claude as a compiler, running Firefox and GIMP with one-third the CPU usage of Xorg.
Geir Isene has built Frame, a complete X11 server from scratch in approximately 20,000 lines of x86-64 assembly language. The project uses no external libraries, no garbage collector, and zero dependencies. It can already run Firefox, GIMP, and a full desktop environment.
The unusual part: Isene used Claude as what he calls a "natural language compiler," describing high-level operations and having the AI generate the corresponding assembly code.
The Technical Achievement#
Frame represents a fundamental rethinking of how graphical servers should work. The numbers tell the story:
- 20,000 lines of assembly code
- Zero dependencies - no libc, no libX11, nothing
- One-third the CPU cycles of Xorg when idle
- Already functional - runs a complete desktop with real applications
The server is part of Isene's larger "CHasm" project (Custom Hardware Assembly), which includes:
- tile - window manager
- glass - terminal emulator
- bare - shell implementation
- bolt - authentication system
The entire stack totals roughly 100,000 lines of assembly - approximately 50 times smaller than the equivalent conventional stack (gdm, X11, i3, conky, wezterm, zsh combined).
The AI-as-Compiler Approach#
Isene's development process treats Claude not as a code generator but as a compilation layer. He describes the intended behavior at a high level, and the AI produces corresponding assembly:
"I leveraged Claude AI as a collaborative partner, describing technical requirements and receiving guidance on hardware layers, cursor rendering, GPU interactions, and event handling."
This approach inverts the traditional relationship between programmers and AI tools. Instead of using AI to generate high-level code that compiles to machine code, Isene skips the middle layers entirely and uses AI to translate intent directly into assembly.
The Hacker News discussion revealed that several developers are experimenting with similar approaches. One commenter noted:
"Given how few programmers very seriously write lots of assembly, it's kind of astonishing how good LLMs are at working with assembly. They can compile and decompile all on their own with apparently very little effort."
Another shared practical experience:
"I've had all my side projects being written in x64 for the last 6 months and it is shockingly effective."
What HN Is Saying#
The Hacker News discussion captures the mix of fascination and skepticism around the project.
On the broader trend of X11 reimplementations:
"I am loving the shift from 'X11 is too big and messy to ever reimplement' to 'there are multiple wildly different X servers being built from scratch.'"
One commenter noted their own Ruby X11 server project:
"Turns out a functioning X server is a relatively simple piece of software. It's mostly just tedious. And most of the bulk is protocol handling that Claude can handle really trivially."
On using AI for assembly generation:
"It's funny to see someone using a LLM as a compiler, making it convert higher-level operations into assembly, instead of just using a compiler."
Several commenters pushed back on the efficiency claims:
"How can a generic LLM generate better assembly than a dedicated compiler, whose sole purpose is to generate assembly code, with people pedantically adding every optimization imaginable?"
Others defended the approach:
"There are a ton of optimization opportunities that hinge on the intent of a piece of code which static compilers can never detect at scale. LLMs can actually navigate that and write surprisingly optimal assembly."
On the Linux battery optimization tangent that emerged in the thread:
"The really unfortunate thing about Linux is the defaults tend to be not battery friendly. For example, I recently got another 1 hour out of my old laptop's battery because I didn't realize for the Intel video card driver I needed to add some modprobe flags."
Why Assembly in 2026?#
The project's philosophy rejects the conventional wisdom that assembly is obsolete:
"Software designed for a large audience fits everyone a little. This fits one person exactly."
Isene argues that modern software has become unnecessarily bloated and opaque. By writing everything in assembly, he maintains complete understanding and control over his computing environment.
The performance benefits appear real. Frame uses roughly one-third the CPU cycles of Xorg when idle - a significant difference for battery-powered devices. The elimination of garbage collection and runtime overhead means the system only consumes resources when actually doing work.
The Practical Limitations#
Not everyone could replicate this approach. The project works because:
- Isene has deep systems knowledge - Understanding enough about X11, GPU programming, and system internals to describe them accurately to Claude
- X11 is well-documented - The protocol specification is detailed enough for AI to generate correct implementations
- The use case is personal - No need to support arbitrary hardware or edge cases
One commenter tried running the project and hit immediate issues with terminal emulators not rendering correctly. The author responded with fixes, but it highlights that "works on my machine" is literal for personal-use assembly software.
The AI-Assembly Debate#
The discussion revealed a deeper disagreement about whether AI-generated assembly can actually outperform traditional compilers.
The skeptical view:
"How can a generic LLM generate better assembly than a dedicated compiler? This has got to be either a masterful ragebait, or a person with very low knowledge of modern compilers."
The optimistic view:
"One simple thing that LLMs don't have to do is use a calling convention. Compilers need to use them because it's not known at compile time who will link against this function. But for a sufficiently smart LLM, noticing a register doesn't need to be preserved because there are only two callers and neither of them care about it might be doable."
The pragmatic view:
"Claude has surprisingly good knowledge of X11 protocol. The other day, a colleague showed me a terminal emulator written in one-shot by Opus. That was compiled to a 30 KB static binary. No libX11, no libXfont, not even libc."
What This Means for Developers#
Frame is unlikely to become mainstream - it's explicitly designed for one person. But it demonstrates several interesting possibilities:
AI can handle tedious protocol work. The bulk of an X11 server is mechanical protocol handling. AI excels at generating this kind of repetitive, well-specified code.
Assembly is more accessible than it used to be. With AI assistance, developers can write and debug assembly without memorizing instruction sets. The AI handles the mechanical translation while the human focuses on architecture.
Minimal dependencies have real benefits. Zero-dependency software starts instantly, uses minimal memory, and has no supply chain vulnerabilities. These benefits may become more valuable as dependency trees grow ever larger.
The "LLM as compiler" pattern works. Using AI to translate high-level intent directly to low-level code is a valid development approach, at least for personal projects where correctness can be verified through use.
The Takeaway#
Frame shows that the boundary between "impossible without a team" and "possible for one person" continues to shift. AI tools don't just accelerate conventional development - they enable entirely different approaches that would have been impractical before.
Whether using AI as a "natural language compiler" will work at scale remains unclear. But for personal computing environments where the user can verify correctness through daily use, it's already producing results that would have seemed impossible a few years ago.
As one commenter put it:
"Yeah, I've had it work on an X11 server using a Ruby X11 protocol implementation instead of libX11, and it just rushed ahead and added support for a bunch of missing requests and responses. None of that is hard - it's all very well documented - but it's tedious. Claude handles the tedious parts while I focus on architecture."
The project is available on GitHub for those interested in examining 20,000 lines of AI-generated assembly.
Continue Reading#
- Debian Debates LLM Usage: Four Proposals, One Fork in the Road
- Echo Claims Fable-Level Results at One-Third the Cost Using Open-Weight Models
- Epic Games Releases Lore: A Version Control System Built for Game Development
- lib0xc Is the Opposite of Rewrite Culture
- The RipGrep Musl Segfault That Led to a One-Line Linux Kernel Patch
Sources#
Get the next deep dive like this in your inbox
One email a week on News and the rest of the AI dev stack. Free.
Read next
Ternlight: A 7 MB Embedding Model That Runs Entirely in the Browser
Ternlight ships a ternary-quantized sentence encoder at 7 MB that runs semantic search at 5ms per embedding - entirely client-side via WASM, no API calls required. Here is how it works, what HN thinks, and where browser-side embeddings make sense.
6 min readOuter Shell: A Graphical Desktop for Your Remote Server via SSH
A new project proposes a graphical shell layer for SSH that turns remote servers into browsable desktops. The HN discussion digs into architecture choices, the terminology debate, and whether this solves a real problem.
8 min readEcho Claims Fable-Level Results at One-Third the Cost Using Open-Weight Models
A new multi-model orchestration system routes requests across open-weight models to match frontier performance at reduced inference cost. Here is what we know.
7 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.
