Dynamic Dev, Static Ship
ONE SOURCE · EVERY ECOSYSTEM
A scripting language while you build, a systems language when you ship — the same source, in every ecosystem.
auto run (interpreted) ↔ a2r (native Rust)
Read the full story ↓v0.5 milestone
Auto: The v0.5 Milestone
v0.5 is Auto’s biggest ecosystem update ever — a key milestone from language to ecosystem!
R&D Investment
- 150 BillionR&D Tokens
- 1 MillionLines of Rust
- 400KLines of Auto
- 10K+Commits
Ecosystem Results
- 1UI FrameworkAutoUI
- 2Desktop EnvironmentsNative desktop · AutoOS
- 3Platform IntegrationsWeb · Windows · Linux
- 4Main ApplicationsAutoEdit · AutoShell · AutoMusk · AutoJade
- 28Demo ApplicationsExamples and demos in the application directory
Author-provided cumulative Auto ecosystem totals · October 11, 2026. See product capabilities and requirements below.
v0.5 milestone preview. Release artifacts and downloads await candidate freeze; captures retain their dated evidence status.
Six Months, Three Major Steps
v0.5 brings three advances together: AutoUI for Web and desktop, a usable AutoOS virtual desktop, and a growing application ecosystem. Here is the path from v0.3 to v0.5 (April — October 2026).
v0.3 answered "is it a language?"; v0.4 answered "can it run real things?". With v0.5, the question is the hardest one yet: "can it become something you open every day?"
Auto has grown from a language kernel, runtime, and transpilers into interfaces, a desktop, and real applications. First, the three release steps; then, the v0.5 experience.
v0.3
The language kernel stood up
Type system, ownership and borrowing, pattern matching — the foundation of a language was laid.
v0.4
Runtime and transpilers
AutoVM and a2r expanded their supported paths, while AI-agent infrastructure started supporting real application workflows.
v0.5
Desktop and app ecosystem
The AutoUI dual-backend architecture matured, the AutoOS virtual desktop became usable, and Auto apps and Rust services formed a desktop ecosystem.
Three Ideas, One Platform
Dynamic dev, decoupled frontends, Language as OS — every section that follows is evidence.
Decoupled at Every Layer
FRONTEND EXPRESSES · BACKEND DELIVERS
One architectural law from the UI down to the OS kernel — both ends of the seam stay replaceable.
UI↔renderer / app↔compositor / agent↔daemon / shell↔kernel
Read the full story ↓Language as OS
LAOS
Use Auto to organize system components, adapt to ecosystems, and develop consistent public interfaces and experiences.
desktop · apps · configuration · shell · services · platform adapters
Read the full story ↓The AutoOS Virtual Desktop
A virtual compositor inside a single OS window fits AutoUI apps into a cross-platform desktop — running on Windows and Linux today; HarmonyOS integration remains on the roadmap.
This time, the first thing we want to show you isn't a language feature — it's a desktop you can use. The window manager itself is an AutoUI app: virtual-window behavior is implemented in Auto above the host window; dragging, focus, and the taskbar are all ordinary Auto code. Both light and dark themes are in place, and apps are progressively integrated, with varying maturity.
- WM-as-App — the chrome, dragging, focus, and taskbar of virtual windows are all written as ordinary AutoUI apps; a shared contract supports consistency across renderers.
- Light & dark views — the first two captures compare the desktop themes; the later views show Launcher, games and an editor workspace.
- Application integration — the captures show Launcher, three games, AutoEdit, Todo, and Calendar. Integration and maturity vary by application.
- Shared settings — auto-os-config organizes its UI in Auto and derives forms from supported data shapes. Modules can require additional rules and integration.
- AutoTerm terminal infrastructure — PTY + an alacritty emulation core, the terminal foundation of AutoOS.
Explore AutoOS and its runtime conditions →
AutoUI · Headline
AutoUI: One Contract, Two Renderers
Dual Web + desktop support: the UI contract is independent of any host framework, and the same .at source generates both the Vue (Web) and iced (desktop) ends.
The desktop runs because of an earlier decision: pulling the UI contract out of the renderer. We worked on this architecture for two years, and v0.5 is where we can finally say it was right — the same .at now genuinely grows both a Web end and a desktop end at once, with behavior checked by corpus tests.
- Contract-layer decoupling — component declarations, state, and the event protocol depend on no renderer; swapping rendering arms is like swapping backends, using Vue / iced as the main paths, with ArkTS / Jetpack Compose at feasibility-demo maturity.
- Cross-renderer verification — Vue and iced have component, event and layout checks; verified corpus protects consistency while known differences continue to be addressed.
- Hot reload is the soul of development — desktop development supports hot reload; state preservation depends on the path and the change.
- Tokenized light/dark theming — one theme declaration, one look across both ends; the example ecosystem defaults to dark, one CLI flag flips to light.
One .atComponents · State · Event contract
a2ts emit
VueWeb · the browser is the canvas
a2r transpile
icedDesktop · native windows
One contract · one behavior · one look
One source, two arms
The matching Vue and native desktop views will use one kanban fixture and source revision. These capture slots await candidate verification. The example is separate from Musk Kanban; images alone do not establish behavioral parity.
Four Main Applications
AutoEdit for code and text, AutoShell for commands and scripts, AutoMusk for AI-assisted development, and AutoJade for documents and knowledge. Features, prerequisites and readiness are described individually.
📝 AutoEdit
A lightweight text workspace for browsing, editing, and comparing files. Native desktop use, code review, and small focused edits guide its development.
Explore this application →🐚 AutoShell
Everyday shell commands, field-based data pipelines, and AutoScript in one session. Use it interactively or call it from the command line.
Explore this application →🤖 AutoMusk
A coding agent that organizes development around Plans and Specs, keeping requirements, execution, verification, and project knowledge traceable.
Explore this application →📄 AutoJade
An editor for AutoDown documents and local knowledge bases. Writing, page links, search, and directory organization form a developing personal knowledge workspace.
Explore this application →AutoDown supplies document and editor foundations. Jade Garden is an existing knowledge-base project, described separately from AutoJade. Related resources →
28 System App and Demo Introductions
The directory groups 28 introductions with real captures, typical actions and runtime conditions. This is an introduction set, not a release-app count or universal online-playability claim. The older gallery has a different sample set; broader Web desktop and application experiences are planned for v0.5.1. Browse the application introductions
Music Player
Web and desktop music-player forms, with playlists, progress and cover art; real media interactions continue to improve.
Video Player
Web and desktop video-player forms with real media services; desktop controls and hit testing continue to improve.
File Manager
A file-browser demo with directory, preview and selection interfaces; data and supported operations are described individually.
Launcher
The application launcher and start-menu foundation; available entries depend on the desktop build.
FreeCell
A card-game demo; its introduction describes the supported controls and runtime path.
Minesweeper
A Minesweeper demo showing the board, flags, timer and difficulty selection.
Tetris
Tetris: falling, rotation, line clears, scoring, smooth keyboard control.
Sys Monitor
System-monitor charts and a process table; distinguish sample data from a connected system service.
Playground
The New Playground: An Auto Lab in Your Browser
Read and edit corpus notes, golden samples and book snippets in the browser. Running, transpiling and debugging require a configured Playground backend.
The Playground brings corpus browsing to the website. Reading and editing need no backend; connect a local or co-deployed service to run supported examples. Debugging coverage depends on the execution path.
- Corpus snapshot (2026-09-07) — 460 VM golden samples, 158 AAVM files, 634 book fences and 28 demo examples; the current browser lists the generated collection.
- Debug support — pair it with a local backend to watch the AutoVM execute, no longer just a black box.
- Run / transpile with a backend — inspect execution and generated Rust/Python for supported examples; one result is not itself a parity test.
460
VM Golden Samples
Corpus as tests.
634
Book Fences
Eight books with browsable snippets; execution needs a backend.
Debug
Debug Support
Watch it execute.
Language
Language Progress: Full-Ecosystem Scripting + Curved Bootstrap
v0.5 moves Auto into the Rust, Python, and Web ecosystems all at once, and Auto's toolchain starts to be written in Auto — and run by Auto.
Last but not least, the language itself. v0.5's answer is full-ecosystem scripting: Rust, Python, and Web advancing in parallel — and deep in the toolchain, the bootstrap loop closed, along a curved route.
- Rust ecosystem — AutoVM calls Rust through natives and dep/use.rs shims, with a2r as the static release path. Layout probes, concrete generic instances and real-library parity provide evidence; compatibility depends on interfaces and signatures rather than an ecosystem-wide percentage.
- Python ecosystem — use.py calls CPython and a2py emits Python. The .as script mode adds bridge syntax, exceptions and context managers; PyTorch inference, training and Module/Dataset callbacks have three-way parity tests.
- Vue / TS / JS ecosystem — Vue is the main Web renderer, supporting state, events and full-stack APIs; component support follows concrete examples and verified coverage.
- Curved bootstrap — host side (avm, a2r) × bootstrap side (aavm, aa2r): since Auto doesn't yet have a compiler backend that emits binaries, bootstrapping takes a curved route — the VM and transpiler written in Auto are transpiled to Rust by aa2r and compiled into binaries, then run the VM and transpiler written in Auto.
Curved bootstrap: [avm, a2r] × [aavm, aa2r] × aa2r
avmRust host interpreter
a2rTranspiled to native Rust
aavmVM written in Auto
aa2rTranspiler written in Auto
One .at corpus, four execution paths, identical output; the last mile of bootstrap borrows the Rust compiler — transpiled by aa2r, compiled to binary
New: inspectable, maintainable applications
Beyond the desktop, these toolchain changes are part of the v0.5 milestone.
Real Rust libraries
dep/use.rs, layout probes and concrete generic instances, checked against real dependencies through three-way parity.
Python scripts and PyTorch
.as lowering, exceptions and with-as, with inference, training and Module/Dataset callback corpus.
Structured UI inspection
Live MCP trees, layout and screenshots, plus Select Anything rectangle export to Auto/JSON/Atom.
Shared editor foundation
Rope, COW snapshots, edit deltas and text/directory diff; full-document materialization remains a large-file limit.
Backend and cache
Axum/Hyper HTTP transport, segmented UI-handler waiting and automatic UI-cache invalidation on generator updates.
The Ideas Behind v0.5
Each philosophy in one line above; the full arguments are expandable below — no claim was trimmed in this reorganization.
🌓 Dynamic Dev, Static Ship — A scripting language while you build, a systems language when you ship — the same source, in every ecosystem.
dynamic-static across ecosystems · three-backend parity
- Most languages make you choose: scripting gives instant iteration but leaves performance at the door; systems languages deliver native speed but tax every idea with a compile cycle. Auto refuses to choose.
- In development, the AutoVM interprets your code — instant startup, hot reload, with REPL and LSP at your side.
- At release, a2r transpiles supported sources to Rust. The C generator has its own scope; complete MCU delivery remains a longer-term direction.
- Not just Rust — this dynamic-static pairing is the shared design origin of every ecosystem across Auto's map.
- A dynamic-static pairing for every ecosystem — UI development (VM/iced hot-reload preview ↔ transpiled release), MCU and Godot dynamic/static pairings still being explored in stages, scientific computing (use.py calls PyTorch directly ↔ a2r ships the service). Before entering any ecosystem, two questions must be answered: how does it run dynamically, and how does it ship statically?
- Hot reload is the soul of the dynamic side — the value of dynamic mode is more than fast startup: edit without restarting, keep your running state, and see exactly what you just changed. AutoUI desktop development supports hot reload; state preservation depends on the path and the change.
- Consistency guarded by machines — the parity harness runs every test through AutoVM, transpiled Rust, and native Rust, requiring identical output; 20+ replicated third-party Rust libraries serve as standing regression corpus.
🔌 Decoupled at Every Layer — One architectural law from the UI down to the OS kernel — both ends of the seam stay replaceable.
frontend · seam · backend
- Decoupling isn't a UI trick — it's the meta-pattern Auto applies at every layer.
- Outermost is AutoUI: its contract is independent of any host framework, and the same .at switches rendering arms between Vue, iced, ArkTS, and Jetpack Compose.
- Moving inward, the pattern repeats — all the way up to the operating system itself, where shell and kernel are just another front and back.
- The current virtual desktop uses the host window system, services, kernel, and drivers. Independent Linux or OpenHarmony integration requires additional platform work; it is a future operating form.
- One pattern, recurring at every layer — AutoUI ↔ rendering engines (Vue / iced / ArkTS / Jetpack); the AutoOS app architecture: auto-ui ↔ auto-compositor (RenderQueue, lock-free over shared memory); AutoAI: agents and AI-apps ↔ ai-daemon (LLM resources scheduled centrally).
- Shared definitions connect applications and services. AutoMusk combines Auto UI sources, generated code, and Rust infrastructure; its workflow remains distinct from the model daemon.
🖥️ Language as OS — Use Auto to organize system components, adapt to ecosystems, and develop consistent public interfaces and experiences.
LaOS → OS over OS → AI + Lang + OS
- Language as OS (LaOS) is the implementation idea: use Auto to organize UI, composition, desktop, applications, configuration, launch, monitoring, shells, and AI services.
- The current runtime and underlying facilities rely substantially on Rust and existing ecosystems. Kernels, drivers, and host services are distinct from the language runtime.
- OS over OS is the current product form: a virtual desktop alongside the host desktop, with its own applications and platform-specific host integration.
- An independent system using Linux or OpenHarmony is a future direction. An AutoOS kernel and a self-implemented native language foundation are longer-term research, not current deliveries.
- Consistent commands, UI, services, notifications, launch, and communication across ecosystems are incremental goals, not a claim of complete platform compatibility.
- AI + Lang + OS is the longer-term human-centered direction for knowledge, work, and everyday life: shared AI, language, and OS/application facilities carry tasks and outcomes.
Development Scale and Sources
150 Billion
R&D Tokens
Cumulative Auto ecosystem R&D investment, provided by the author.
1 Million
Lines of Rust
Language, runtime, rendering, and ecosystem infrastructure.
400K
Lines of Auto
Bootstrap libraries, applications, examples, and corpus.
10K+
Commits
Cumulative ecosystem development commits, provided by the author.
Author-provided cumulative Auto ecosystem totals · October 11, 2026. See product capabilities and requirements below.
Looking Ahead to v0.6
Near-term work and longer-term directions. Independent OS forms and knowledge collaboration have no fixed release date.
AutoOS
Improve the virtual desktop and host integration; explore independent systems using existing kernels. An AutoOS kernel remains longer-term research, without a delivery date.
AutoUI
Build on Harmony and Jetpack Compose feasibility demos; complete Android and iOS delivery still needs further work and validation.
ROS2 Ecosystem
Robotics node development on Rust/Python, plugging into DORA-RS and beyond.
Godot Ecosystem
Fuller GDScript support and native Scene/Node capabilities, fitting into the Godot development workflow.
MCU Ecosystem
Embedded: Auto transpiles to C, and the AutoMan build system takes Auto into the microcontroller world.
AutoAI
Develop shared model services and Agent work tools. Cross-application knowledge collaboration is a longer-term direction, built on clearer data and interaction contracts.
Try Auto Today
Read an example, then prepare the toolchain with the run and build guide. Browsing needs no backend; execution and debugging require a service.