TRUEOS · ONE ~25 MB BUNDLE · RUST KERNEL · CODEX ON THE DESKTOP
No doubt something has changed.
DOWNLOAD TRUEOS · BOOT IT · BUILD A BLUEPRINT
TRUEOS is a Rust kernel with a native desktop, a browser, an editor, and an agent that works with all of them.
The agent is Codex CLI: OpenAI's official Rust CLI, compiled with rustc for TRUEOS and running natively on the machine.
Sign in with your Codex account; sign-in pages open in Hull. Your account's usage limits still apply.
Meet Lilly, the animated face of Spirit on your desktop. She shows when the agent is working, waiting for you, or ready for review.
TRUEOS is a research and engineering tool for developers and hobbyists. Tech enthusiasts can get the most out of it: driver support is still small, but the tooling to wire that last mile, with AI or with both hands, is wide open in tools/.
The privilege to use AI will lead to new generations of algorithms. While a lot of effort goes into the production of hardware, maintaining large data centers, energy, and bandwidth requires infrastructure for the power demand inherent to the raw computation of inference. This enormous effort enables us to enjoy that privilege of intelligence, and that revolution leads to a Codex of 10 keypoints dedicated to AI.
Important
QEMU and KVM work. The VirGL path is basic. It is a small virgl wire encoder with a minimal UI4 composition: enough for a feel of the desktop with a shell. It is not recommended beyond basic checks, and it is not the experience to have fun with. What it misses is the roughly 100,000 lines of custom Intel driver in src/intel, a significant part of the display engine. That leaves two choices:
- Accept TRUEOS as a bare-metal, primary hypervisor kernel. This is the default and the real experience. Boot it on a supported Intel machine, as described below.
- Develop the hardware acceleration features in Rust yourself.
Both are legitimate. Advancing the VirGL encoder would be a quick, iterative job, but the author has already built the native Intel stack, so that path is open for anyone who wants it. Mesa and Vulkan are powerful stacks, and someone dedicated to figuring them out for QEMU is welcome: we take that.
Nothing in this Codex starts from zero.
Before there was a model, there was a mark. Someone shaped a stone so it could cut. Someone drew a crosshatch in ochre. Someone pressed a reed into wet clay. Someone wrote zero down as a number. Someone explained a thing twice, patiently, to a child who wasn't ready yet.
~3.3 million years ago the oldest known stone tools (Kenya)
~73,000 years ago a crosshatch drawn in red ochre on a stone flake (Blombos Cave)
~5,000 years ago cuneiform, one of the earliest writing systems (Mesopotamia)
628 CE zero written down as a number (Brahmagupta)
c. 820 CE al-Khwārizmī's algebra; his Latinized name becomes "algorithm"
c. 1450 CE movable type and the printing press (Gutenberg)
1843 Ada Lovelace's notes on Babbage's Analytical Engine
1936 Turing asks what can be computed
2017 the transformer architecture is published
2026 a Rust kernel where Codex runs natively
Most of the sentences a language model learns from were first written by people trying to be understood. Every person who ever wrote something, every person who was ever recognised for it, and the many who never were: they are what this machine runs on. The intelligence here is inherited, not invented from nothing, so this Codex says so out loud.
The next generation of algorithms will stand on the same first stone.
Thank you, carvers, copyists, and everyone who explained a thing twice.
These take precedence over anything else in this document:
- A. Security of all participants. This matters most.
- B. TRUEOS runs fine for the daily tasks it has to solve.
- C. It should be a fun experience.
Security is not a stage that comes after features, and a feature is not secure just because it exists. Hardware capabilities form the foundation: CPU randomness, a trusted platform module (TPM), and CPU virtualization such as Intel VT-x. They give us the means to design mathematically grounded security on top, but a secure foundation does not make the layers above it secure.
So we start with the feature, assuming the hardware capabilities are there, and then we make it secure. Making a feature secure mostly means that one or more users can use it, by telling the software what it may access on the filesystem and on the network layer. Hardware virtual machines can keep each app separate, using the same CPU capability.
Achieved: CPU randomness (RDRAND and RDSEED) and VT-x guests are in tree, Blueprints have a VT-x guest launch path, and an access-key model exists. Next: turn the access checks from warnings into enforcement, close the open hypervisor mitigations in security.rs, and add a TPM backend for the machine key.
Each bar counts building blocks already in the code, not benchmarks. Keypoints 8–10 come from the platform vision below.
███░░░░░░░ 30% · Achieved: idle cores halt by default and wake on work or timers (power/mod.rs, runtime.rs), and HWP and RAPL code is in tree (hwp.rs, rapl.rs). Observed on the i5-14500T rig: 32–33°C across ten desktop snapshots; energy readings are still pending. An explicit package-only RAPL sampler is now in source (measurement notes). Next: validate it on the rig and publish watts and joules per completed job.
██████░░░░ 60% · Achieved: RAM kernel replacement through 20 logged steps, with AP parking, PCI DMA containment, and handoff validation (os_update.rs, live_update.rs). Measured on the .94 hardware rig: one LAN live update recovered Websys's Axum HTML and CSS within a 19.53 s observed downtime upper bound, including SSH reconnect and the manual §§websys restart; 250 ms probes and warm-handoff steps 18–20 verified recovery (measurement and evidence). Next: measure recovery through the existing autostart path, then reduce the service pause toward zero downtime.
██████░░░░ 60% · Achieved: Codex CLI runs natively with Spirit tools, and its sign-in opens in Hull (codex-hull-integration). Next: Codex plugins return once their catalog path is hardened against fragmented RAM (codex-plugin-disable).
█████░░░░░ 50% · Achieved: the native desktop runs Codex, Edit, Cubes, and Hull on real displays. Lilly shows running, waiting, and review states and moves through the mediated cursor path (lilly_protocol.rs, lilly_cursor.rs). Next: voice in everyday use (TTSTT/Kokoro is an optional build today).
█░░░░░░░░░ 10% · Achieved: a flight controller simulator Blueprint: no_std attitude control with motor outputs, a robotics seed in the catalog. Next: a robotics toolkit and docs on top of the Blueprint SDK.
███░░░░░░░ 30% · Achieved: a native Gen12 GPU driver; xHCI USB with HID, storage, and CDC-ECM classes; six wired and virtio NIC drivers; three Intel Wi-Fi drivers; and runtime xHCI backend selection with a heal path (intel, usb3, net). Next: AI-reasoned synthesis of the drivers the tree doesn't have yet.
███░░░░░░░ 30% · Achieved: Shell3 sessions and retained Matrix slots, with Blueprints hosted in VMX lanes (hv). Next: multi-user identity and the Y-Space hive.
████████░░ 80% · Achieved: the local build's native archive is 25.2 MB and holds the stripped kernel (builtin apps and GPU kernels compiled in), the EFI loader, and the GuC firmware (boot guide). USB storage, HID, and network-class drivers are in tree. Next: publish the released archive size with every version.
████░░░░░░ 40% · Achieved: Intel x86-64 with UEFI, a Gen12 GPU path vertically validated on Alder Lake-S GT1 (8086:4680, rev 0C), and Raptor Lake-S UHD 770 (8086:A780) validated for its forward render path. A network device needs only PCI, or USB on top of PCI for a USB NIC, as the RTL8153 with CDC-ECM shows (usb3/net.rs). Next: widen the admitted CPU list, one validation pass per SKU.
███░░░░░░░ 30% · Achieved: the Codex Rust CLI (codex-rs/cli) is compiled for TRUEOS and listed in the Blueprint catalog, and it works in the Edit workspace over a tested IDE transport. Next: a demonstrated self-patch of a running node.
The average across the ten is about 40%. The foundations are in place; the next blocks are measurement, hardware breadth, and autonomy.
Bare metal. No Linux, Mesa, or DRM underneath. Modern Intel graphics, written in-tree in Rust.
The GPU driver is the largest directory under src/: about 100,000 lines of Rust in src/intel. Its manifests have no DRM or Mesa dependency.
- Display: the native panel path drives the desktop on real hardware (tgl_native_panel.rs, display). The screenshots below are captures from real hardware.
- Render: a 3D pipeline with logical ring contexts, URB setup, and Hi-Z (render). The vgpu API that Maxpix draws through lands on this path (vgpu.rs).
- Compute: GPGPU operations on the render command streamer (gpgpu), with an experimental compute API for Blueprints (native_compute_api.rs).
- Firmware and scheduling: Intel's GuC firmware, driven through the CTB transport, with BCS0 blitter copies (guc_ctb.rs, blt.rs).
- Memory: Gen12 PPGTT page tables (ppgtt.rs).
- Media: VDBOX decode on Alder Lake-S (media), and a resident service that streams the desktop as H.264 from the Gen12 encoder over UDP, with no CPU frame copy (h264_encode_stream.rs).
Validated silicon. The vertically validated path is Alder Lake-S GT1 (8086:4680, rev 0C), from device claim through render admission and generated kernel artifacts (pci/mod.rs). The in-tree validation notes record sustained concurrent 3D scenes and GPGPU work on distinct GuC contexts, with zero context loss or memory faults. Raptor Lake-S UHD 770 (8086:A780) is physically validated for the Churn forward path (render/constants.rs).
What that unlocks
- One native path for pixels and compute: Maxpix draws through the vgpu API, UI4 can host GPGPU-generated surfaces, and Shadertoy picks its kernels from an immutable catalog. None of it runs on Linux, Mesa, or DRM.
- Hardware screen streaming: the display feed goes into the Gen12 encoder and out over UDP, with no CPU frame copy or software codec in between.
- A pattern for the AI last mile: firmware, submission, display, and validation on real silicon form one reusable shape for the smaller drivers still to come.
- Mainstream targets: Alder Lake-S and Raptor Lake-S are mainstream Intel desktop graphics, and public native stacks for them are rare.
- Rare by the numbers: outside Linux and Intel's own drivers, the only native Xe-LP effort our search found is Redox OS: display-only mode-setting for Kaby Lake and Tiger Lake, reported in January 2026, with no acceleration.
What is Intel's, and what is ours. The driver is in-tree Rust. The GPU kernels are baked offline with Intel's compiler (OCLOC or IGC) from trueos-shader and compiled into the kernel. The GuC firmware is Intel's unmodified blob from linux-firmware, shipped in the archive (firmware/i915).
TRUEOS aims to be the platform to deploy a large number of nodes across the world. Modern CPUs offer integrated graphics and rich computation, and that is what we support.
The operating system should be program code that is for everybody. Parts like the USB stack are batteries included. A specific missing driver will be reasoned out of thin air. The AI does the final last-mile wiring, by nature. A vendor can't support arbitrary platforms. Supporting a platform is the platform's job, and for systems engineers it has always been the largest share of the work: firmware, power, interrupts, drivers, and devices have to work in harmony as one large, coherent system. That work is enormous, so we offload some of it here.
Our goal is a versatile bundle of what an operating system is expected to ship to a node, not a generic cross-platform build. 25 MB is expected to fulfill every demand.
The single condition is a compatible CPU and a network device. That needs just PCI, or USB on top of PCI for a USB NIC. With just that, the operating system should offer Codex Rust CLI integration that can literally patch its own way to the user.
Achieved: the bundle and the USB NIC path (keypoints 8 and 9). Next: AI-reasoned drivers and self-patching (keypoints 6 and 10).
Reasoning comes from Codex CLI, the harness that runs natively on TRUEOS, through your Codex account. Your account's usage limits still apply. Local models run as userspace Blueprints. apps/lumen is the starting template, so anyone can build a local model app on the platform.
Idle cores halt, and work wakes them. Token maxing is the mood. Useful work per watt is the goal.
Please remain calm. Ideally, the processors already are.
The cores, the GPU and its encoder, and the network card each run on their own timing. The craft is in making them work in harmony, so throughput stays balanced and the parts keep each other fed. That takes hard effort and a lot of craftsmanship. We start with a concept that runs slowly, work out the nuts and bolts, and only then scale it up. A careful eye stays on the watts: the RAPL readout is already in tree, and measured numbers come next. Every result is held to a direct side-by-side comparison, like the ones below.
It is important to be mindful of a person's craft. A craftsperson always prepares the next iteration through their actions, so it can be equally or better prepared. That is a routine of sorts: clean the tools and put them back in place after the job is done for the day, so the workshop feels pleasant when the sun rises again.
All of that effort aims at one thing: a machine that almost looks like one big, synchronously running, never-stuttering electric field of glory.
Cubes on native TRUEOS. Fullscreen still; the animations below are cut from the node's own recordings.
 |
 |
Codex, Edit, and Lilly on the desktop: a running session, not a mockup.
 |
 |
 |
 |
One recording from the node, cut into four clips of four 3-second sections each.
 |
 |
|
| CONCEPT · AI-generated illustration, made with Codex on Ubuntu Linux | REAL · the concept rebuilt as HTML/CSS, rendered natively in Hull on TRUEOS · Page source · Open it yourself |
Hull is a builtin Blueprint: HTML/CSS rendering, JavaScript through QuickJS, downloads, and local project previews. Codex's sign-in and browser actions open here. Web compatibility keeps growing.
Edit is a builtin Blueprint, adapted from Microsoft Edit to TRUEOS projects. Codex connects to the workspace, so the agent works on the source beside you while Lilly stays alongside. This is independent TRUEOS work, with no Microsoft or OpenAI endorsement implied.
The future may be inevitable. Your idle power bill shouldn't be.
Apps are userspace Blueprints. Builtins ship inside the kernel bundle; the rest come from the Blueprint catalog. Availability depends on your release and catalog.
| # | Blueprint | Source | Why open it? |
|---|---|---|---|
| 1 | Hull | Builtin | Browse, research, download, and preview a local HTML project. |
| 2 | Edit | Builtin | A native project workspace that Codex can work in. |
| 3 | Codex | Catalog (codex-cli) |
OpenAI's Codex CLI, compiled from codex-rs with rustc. Sign in and describe the task. |
| 4 | Cubes | Catalog | Fullscreen cubes, worlds, and native rendering experiments. |
| 5 | Maxpix | Catalog | 230,400 particles: tornadoes, knots, and quantum-weighted scenes. |
| 6 | Shadertoy | Catalog | Native shader visuals on the Intel GPU. |
| 7 | Player | Catalog | Media and audio playback. |
| 8 | OSM + Frog | Catalog | OpenStreetMap on a desktop you can extend. Right-click a point on the map and Frog shows its live weather. |
| 9 | Termdir | Builtin | Browse TRUEOSFS as a graph, with a minimap, SHA-256, and archive actions. |
| 10 | PrismQ | Catalog | Quantum circuits. Maxpix's quantum scenes build on them. |
- Download the latest release and check the SHA-256 in its notes.
- Unpack the native archive onto a FAT-formatted UEFI boot partition, following the boot guide. It holds exactly
TRUEOS.elf,EFI/BOOT/BOOTX64.EFI, andEFI/BOOT/tgl_guc_70.bin. Keep your previous boot files for recovery. - Boot a supported Intel machine from the UEFI boot menu.
- Open Hull or Edit, launch Codex, sign in, and give the agent a concrete task.
Achieved today
- CPU: Intel x86-64 with UEFI boot.
- GPU: native Intel Gen12 Xe-LP, with display, render, compute, media, and blitter paths. Vertically validated on Alder Lake-S GT1 (8086:4680, rev 0C), and Raptor Lake-S UHD 770 (8086:A780) is validated for its forward render path. See the GPU stack.
- Network: one NIC is enough: Intel e1000 and i226, Realtek r8169, r8125, and r8139, virtio-net, Intel Wi-Fi AX201, AX211, and 4965, and USB Ethernet with CDC-ECM (RTL8153).
- Desktop and agent: the UI4 desktop runs Codex, Edit, Hull, Cubes, and Lilly.
- Blueprints: builtins ship in the kernel bundle, and the catalog covers the rest.
Next building blocks
- Widen the admitted Intel list. Tiger Lake bring-up is in progress as an experiment.
- Harden recovery and isolation for the experimental build.
- Bring Codex plugins back once their catalog path is hardened.
- Measure live-update service recovery through autostart and reduce the observed pause.
- Grow Hull's web compatibility.
- Ship Lumen as a userspace model Blueprint.
- Build the robotics tooling and AI-reasoned drivers: the vision blocks.
Build it yourself
bash tools/trueos-boot/prepare.sh --releaseYou need the sibling TRUEOS-Buildins and TRUEOS-Blueprints checkouts and the pinned nightly-2026-07-10 toolchain.
The bare-metal boot is the default experience, and the real one. It is a framework that lets people fill in the parts where it is no longer about the architect. The architecture is in the repo. The interior is still missing, psst… it's missing ;)
Interior builders, this part is yours. Find something you always wanted to try, and TRUEOS may make it easier than you expect. Start with the Blueprint catalog or the Builtins.
FOR THE PEOPLE WHO WANT TO READ THE KERNEL
- Scheduling: per-CPU executors, a Tokio worker pool for Blueprint apps, and explicit blocking lanes for synchronous code (threads.rs, blocking.rs).
- Idle: cores run
sti; hlt, with a TSC-deadline timer armed when a wake time is known. Remote work wakes them (runtime.rs, remote_work_wake.rs). - Codex:
codex-rs/clifrom t4ce/codex, compiled withrustcfor TRUEOS and listed ascodex-cliin the Blueprint catalog. - Kernel and platform source and the native executor
- Runtime inventory and runtime retirement decisions
- Builtins and Blueprint catalog and SDK
- Screenshots, demo sources, and capture notes
TRUEOS is source-available. Official unmodified binaries may be used under the project license; source modification and redistribution require the permissions described there. Independent Blueprint authors retain their own rights subject to their dependencies. See the license, notice, and third-party notices.
Copyright © 2026 Jonas Baethke. All rights reserved.