01 — Thesis
The agent should live in the OS, not on the host.
Most “AI OS” demos are Linux plus a model that shells out over SSH. Most hobby kernels stop at a prompt. Peak OS is the thing in between.
It's a real kernel with its own bootloaders, a workspace, an in-guest planner called peak-agent, a desktop, TLS, a browser, containers, and local memory — all Peak C inside the guest.
The agent, the tools, and the project context are OS primitives. The planner stays in the guest. There is no host LLM bridge by default.
That's the architecture:
userspace shell → peak-agent (local) → tools (fs / exec)
Policy, audit, session memory, and PeakVec live under /var/peak/. Capabilities decide what the agent can touch. Network needs an explicit grant. Opening the desktop doesn't phone home.
02 — The problem
The usual “AI OS” is someone else's kernel.
The convenient path is a Linux host, a container, a cloud model, and a sidecar. You didn't build the OS. The agent's memory is an app problem. Trust gets fuzzy — serial bridges, host proxies, credentials sitting on the laptop.
Hobby kernels fail the other way. They print hello and call it done. Networking, TLS, a desktop, a browser, and an agent that can write files under policy never show up, because the demo doesn't need them.
The question I actually care about: can you build a single-user research workstation where the interesting parts are yours, inspectable, and local — without pretending to be Linux?
CI enforces that. scripts/purity-check.sh bans Limine, COM2/COM3 host bridges, peak-host-proxy, and agent_poll_host. If the agent works, it works in the guest. If HTTPS works, Peak's stack spoke TLS. That's the point.
03 — What I'm solving
A usable developer surface, with the agent inside it.
Not every systems problem. A focused set that makes an AI-native workstation actually coherent.
The whole stack, not just boot
-
Past the bootloader
CLI, multi-window desktop, browser tabs, net tools, and
ctrdemos in one Peak kernel. “It boots” is not the finish line. - Networking that actually lives in the guest DHCP, DNS, TCP, TLS 1.2/1.3, HTTP/2 ALPN, WebPKI, optional TOFU — Peak C, not a borrowed host stack. Live CDN HTTPS bodies are still often empty (Partial — TLS fingerprint / B-HTTPS-H2).
- Two architectures x86_64 QEMU is the daily loop. There's a flashable aarch64 Pi SD image; Pi 3 is the hardware gate.
Local-first, on purpose
-
Agent as an OS citizen
ask "…"and a GUI Agent window run a bounded planner over allowlisted tools (fs.*,net.*,mem.recall, …) with policy, audit, and write approval. - Memory next to the filesystem Session memory and PeakVec sit beside VFS. Hashed n-grams, cosine search, blobstore-backed. Local only. No model weights.
-
Privacy you can actually check
No telemetry. Desktop stays network-idle until you grant it. Persist profiles (
private/workspace/full), net grants, kill switch. Schemes are public; seeds stay secret.
Trust you can read
Capability bits (CAP_AGENT, CAP_VEC, CAP_NET_*), NX/W^X, ASLR/KASLR/canaries, fail-closed entropy for release crypto, and an audit log at /var/peak/audit.log are part of the product, not a later “security phase.” I want this workstation to be explainable: what persisted, what went on the wire, what the agent was allowed to do.
04 — Not solving
What this is not.
Scope discipline is part of the story. Calling non-goals early keeps the page honest.
-
Not Linux userspace
Peak
/bin/*builtins and ELF scaffolding. I'm not dropping Debian onto a hobby kernel — that would kill the whole point. - Not a host LLM sidecar No serial agent bridges, no default remote model. The planner is a bounded in-guest engine. A remote LLM over TLS might show up later. It will never be the default.
-
Not Chromium, Docker, or Pinecone
The browser is a Peak JS / DOM subset.
ctris not runc (no image pulls, netns, or process-isolation theater). PeakVec is local hashed embeddings, not a cloud vector DB. - Not GPU / Wayland / multi-monitor Software framebuffer and compositor. 1080p @ UI scale 3 is the polish target. Hardware accel waits unless Monitor shows a real bottleneck.
- Not production-hardened yet Treat it like research, because it is. Verified boot and signed releases are incomplete. Browser ring-3 isolation is still deepening. Session lock is a privacy cover (Enter unlocks) — not authentication.
- Not defending a hostile hypervisor A hostile QEMU host and physical bus attackers are out of scope. Secure deletion is best-effort against snapshots you don't control.
- Not done on Pi silicon Pi 3 SD images build in CI; HDMI/USB/PeakFS hardware acceptance is still the gate. Pi 4/5 Ethernet, xHCI, Wi‑Fi, and GPU are stubs. SMP secondaries stay parked.
05 — What's interesting
Why I keep working on this.
Purity is a CI gate, not a slogan
Most demos cheat quietly. Peak makes the cheat fail the build. The guest has to carry its own boot, net, TLS, agent, and UI. That forces a real BootInfo ABI from Peak loaders into kernel_entry, thin arch_* / platform_* / blockdev / netdev seams, and VFS, GUI, Peak JS, peak-agent, and PeakVec on top.
The agent isn't an Electron app we also ship
Tools and policy live in-kernel. Writes can require a GUI Y/N. Turns go into session memory and PeakVec. Syscalls SYS_agent and SYS_peakvec make this systemic. The interesting claim isn't “we have an LLM” — we don't, by default. It's that workspace agency has policy, an audit trail, and local recall with no cloud embeddings.
Cloud-shaped surfaces without Linux
TLS with WebPKI, a software desktop, a browser that only fetches when you hit Go, a tiny container runtime over Peak TCP. None of that has to win a standards bake-off. Together they answer a simpler question: does the stack actually compose?
Enhancement-pass culture
The tree has a long sequence of numbered passes (through Wave 7 / ~Pass 158), locked by smoke-cli. That's not marketing cadence. It's how vertical integration doesn't rot. The changelog is a log of what became true in the guest this week.
06 — Architecture
Firmware to shell, one path.
Firmware (SeaBIOS, OVMF, or VideoCore) hands off to a Peak loader — BIOS El Torito, UEFI, or Pi shim. The loader builds BootInfo (memory map, framebuffer, HHDM, optional DTB) and jumps into the higher-half kernel. VFS, GUI, net, and the agent sit above a thin HAL. You get a shell and a desktop.
Higher-half at 0xffffffff80000000, HHDM at 0xffff800000000000. PeakFS streams persist to PeakDisk (ATA on PC, SDHCI on Pi). Blobstore backs large objects and PeakVec pages. You don't need to memorize that to get the thesis — but it's why the screenshots aren't a theme skin over someone else's kernel.
07 — Proof
What it looks like in QEMU today.
Screendumps from the guest framebuffer. This is the Peak Evergreen R&D note on kevinmull.in.
08 — Status
Where it actually is.
Started at v0.1.0-mvp. Current line is 0.3.0-ai. Agent, PeakVec, TLS/WebPKI, desktop polish, browser interactive-bar code, and container demos are in-tree. The gaps are in-tree too — live public HTTPS body fetch is still Partial (B-HTTPS-H2). Documented, not papered over.
- x86_64 QEMU
- Supported — SeaBIOS smoke in CI; UEFI locally.
- aarch64 QEMU
- Supported — serial smoke in CI.
- Raspberry Pi 3
- SD image built in CI; HDMI/USB hardware acceptance still pending.
- Pi 4 / 5 I/O
- Ethernet, xHCI, Wi‑Fi, GPU accel — not ready.
- Security posture
- Experimental. Verified boot / signed releases incomplete. Report issues via SECURITY.md.
- License
- MIT for Peak-authored code. Raspberry Pi boot/Wi‑Fi firmware is a documented binary exception.
Privacy claims that already hold: no telemetry; local-only agent; network-idle GUI; explicit persistence; explicit network disclosure; identifier minimization; release serial must not print seeds, canaries, or passphrases.
I'm trying to make an AI-native workstation true in the guest. I'm not going to fake that with Linux, Limine, or a host bridge.