Peak Evergreen systems R&D

Peak OS

A from-scratch, AI-first developer OS.

Freestanding C. Own bootloaders. In-guest agent, network, desktop, and browser. No Linux. No host bridges. Agents and workspace memory as system primitives.

0.3.0-ai · research workstation · MIT

The thesis

The agent belongs in the kernel’s neighborhood, not on the host.

Peak OS is Peak Evergreen’s R&D bet that an “AI-first” developer environment should be a real operating system — not a chat panel glued to Linux, and not a hobby kernel that stops at a shell prompt.

Most hobby OS projects prove that boot works. Most “AI OS” demos prove that a model can call tools over SSH. Peak aims past both: a freestanding kernel with Peak-authored BIOS and UEFI loaders, a VFS workspace, an in-guest planner called peak-agent, a multi-window desktop, an HTTP(S) browser surface, containers, and a local vector index — all Peak C inside the guest.

Agents, tools, and project context are system primitives. Inference stays an in-guest planner. There is no host LLM bridge by default.

userspace shell → peak-agent (local) → tools (fs / exec)

Under /var/peak/ live the durable primitives: workspace policy, action audit, session memory, and PeakVec recall. Capabilities gate what a subject may touch. Privacy grants gate the network. Opening the desktop does not phone home.

What “AI OS” usually means — and why that is not interesting enough.

Today’s default path is convenient and opaque at once: a general-purpose Linux host, a container runtime, a cloud model, and a sidecar that shells out. The “operating system” part of the story is borrowed. The agent’s memory is an app concern. The trust boundary is fuzzy.

Hobby kernels have the opposite failure mode. They stop when the serial console prints hello. Networking, TLS, a desktop, a browser, and an agent that can write files under policy never arrive.

Peak OS treats that gap as the research question: can you build a single-user research workstation where the interesting parts are Peak-authored, inspectable, and local-first — without pretending to be Linux?

CI runs scripts/purity-check.sh: no Limine, no COM2/COM3 host bridges, no host agent proxy. If the agent works, it works in-guest. If HTTPS works, Peak’s stack spoke TLS.

Problems Peak OS is actively attacking.

Vertical developer surface

  • Past the bootloader CLI, multi-window desktop, browser, net tools, and ctr demos inside one Peak kernel.
  • In-guest networking that is real DHCP, DNS, TCP, TLS 1.2/1.3, HTTP/2 ALPN, WebPKI and optional TOFU — Peak C, not a borrowed host stack.
  • Dual-arch path x86_64 QEMU as the daily loop; flashable aarch64 Raspberry Pi SD image with Pi 3 as the hardware gate.

Local-first agency

  • Agent as OS citizen ask "…" drives a bounded planner over allowlisted tools with policy, audit, and write approval.
  • Context as infrastructure Session memory and PeakVec sit beside VFS — hashed n-gram embeddings, local only, no model weights.
  • Privacy as product property No telemetry. Network-idle GUI. Explicit persist profiles and net grants. Kerckhoffs: schemes public, seeds secret.

What Peak OS is deliberately not.

Why this is worth an R&D page.

Purity as a product constraint

Most demos cheat quietly. Peak encodes the cheat as a CI failure — BootInfo ABI, thin HAL seams, portable VFS/GUI/net/agent above them.

Agent + PeakVec as kernel-adjacent primitives

Policy, audit, GUI write approval, and local semantic recall without cloud embeddings. The claim is not “we have an LLM.”

In-guest cloud-shaped surfaces without Linux

TLS with WebPKI, software-composited desktop, explicit-fetch browser, tiny container runtime — asking: does the stack compose?

One path from firmware to shell.

Firmware hands off to a Peak loader. The loader builds BootInfo and enters the higher-half kernel. Shared subsystems — VFS, GUI, net, agent — sit above the HAL.

Firmware Peak loader kernel_entry VFS · GUI · Net · Agent Shell & desktop

That path is why the screenshots are not a theme skin over someone else’s kernel.

What it looks like in QEMU today.

Captured from the guest framebuffer. Open source at github.com/peakevergreen/peak-os.

Where the research sits.

Baseline v0.1.0-mvp; current line 0.3.0-ai. Agent, PeakVec, TLS/WebPKI, desktop, browser, and container demos are in-tree — with honest gaps documented alongside them.

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.
Security
Experimental. Verified boot / signed releases incomplete.
License
MIT for Peak-authored code; documented Pi firmware binary exception.

Peak OS is trying to make an AI-native research workstation true in the guest — and equally trying not to fake that truth with Linux, Limine, or a host bridge.

Systems R&D from our studio

Peak OS is open-source Peak Evergreen research — the same team that ships client products and Shell Forecast.