Kernel-owned authority
Services and apps can request, never forge. Tickets, capabilities, approvals and leases are issued and checked by the kernel.
Experimental operating system · x86_64 UEFI
Humans and AI agents, working safely together.
OSAIKU is a new operating system written from scratch. It is designed from the kernel up so that AI agents can understand the system and act in it through typed, bounded and human-approved actions, never by scraping your screen.
In active development. Not ready for everyday use or important data.
- Stage 29/36
- current roadmap stage
- 1,164
- commits
- 415
- merged pull requests
- ≈400k
- lines of code
- 927
- deterministic QEMU proof modes
Figures from the project repository, October 2026.
01 — What is OSAIKU
An operating system that expects an AI to share the machine with you.
Today's desktops were built for people and only later taught to put up with automation. OSAIKU starts from the opposite question: what would an operating system look like if a human and an AI agent were expected to work in it together from day one?
The answer so far is a small kernel that owns every grant of authority, services and apps that can only ask, and a desktop that describes itself to agents as structured, verifiable data. The human stays in charge. An agent can observe and propose, and it acts only inside a lease the person has approved.
The agent loop
- Observestructured, semantic system state
- Planwithin declared constraints
- Proposeone typed, validated action
- Approvea person grants approval or a lease
- Executeonly through a bounded tool
- Verifythe result against what was proposed
- Recordprovenance anyone can audit
02 — Principles
Six rules the whole system is built around.
Semantic, not screenshots
Agents read the interface as stable records: roles, labels, state, bounds, hashes and provenance. No pixel scraping, framebuffer readback or OCR.
Proven, not promised
Every change ships with deterministic QEMU proofs, including absence proofs that state what a path does not do. Real hardware is tested on top, never instead.
The desktop comes first
Input and the desktop keep guaranteed priority. AI work runs asynchronously on bounded compute and never blocks the system you are using.
Local-first AI
Models are meant to run on your own machine, on a device chosen for the task. Network access arrives only behind explicit policy and containment.
Recoverable by design
Storage is authenticated and copy-on-write. Signed updates boot as a trial first and fall back to the previous system on failure.
03 — Where it stands
28 of 36 roadmap stages closed. Stage 29 is underway.
OSAIKU already boots on real hardware and runs its own desktop and apps. The current stage is about making storage durable, updates safe and the system multicore, which are the prerequisites for running a local AI model inside it.
Closed · 1–28
In progress · 29
Planned · 30–36
Working today
- Boots via UEFI in QEMU and on a real laptop (Dell Precision 7670), from USB or installed on its internal disk.
- Its own desktop compositor, with multiple windows you can open, focus, drag, resize and close.
- Its own USB (xHCI) stack for a physical keyboard and mouse.
- Apps run as isolated processes with private memory: Document, File Manager, System Manager and System Update.
- An authenticated copy-on-write filesystem. Documents survive a reboot and a full power-off.
- AI groundwork: an agent context protocol, a local model service skeleton, a typed tool gateway and proposal-only UI action planning with human review.
Being qualified now
- Signed system updates. Trial boot and automatic fallback already worked on the physical laptop. Independent recovery is still open.
- Full-disk install. A scalable OSAIFS volume that uses the whole disk and can hold model-sized files.
- Multicore foundation. One isolated processor core runs bounded compute work, so AI never competes with the desktop for the only CPU.
- Storage closure. Final acceptance of integrity, recovery and the boundary between secrets and agents.
Not there yet
- No local language model running inside OSAIKU yet. That is Stage 30.
- No networking and no web browser.
- No SDK or third-party apps.
- Tested on a small set of machines. The display uses the firmware framebuffer, not native GPU drivers.
04 — Roadmap
From a trusted boot to a local AI agent.
-
Stages 1–7
Foundations
Trusted UEFI boot, a fixed service core, secure assistant actions, a preemptive scheduler, storage trust, AI-friendly filesystem metadata and the first local AI runtime skeleton.
-
Stages 8–16
Apps and real hardware
An app execution boundary, controlled app capsules and launch, physical bring-up on real laptops, hardware observability, and display and input foundations.
-
Stages 17–26
The human and AI interface
Interaction design, prompt and assistant surfaces, semantic screen observability, typed UI action planning, diagnostic boot, modern input and approved action leases.
-
Stages 27–28
A usable desktop
The first document app with a privacy contract, then a functional desktop with its own compositor and multiple windows and processes.
-
Stage 29 · now
Durable storage and integrity
Authenticated storage, files and a file manager, a full-disk install, signed updates with fallback and a multicore foundation.
Next
30
Up next
Local LLM runtime and AI agent integration
31
Agent memory, retrieval and context compression
32
Networking, browser containment and VMs
33
OSAIKU SDK and native app portability
34
Security review and hardening
35
Human-friendly desktop polish
36
Broader hardware support
05 — The look
Calm graphite, violet accents, room to breathe.
These design references set the direction for the desktop. The native compositor already follows their palette and window style. Several apps shown here, such as the browser, calendar and music player, are still on the roadmap.
