Peak Evergreen systems R&D
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.
01 — Thesis
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.
02 — The problem shape
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.
03 — Trying to solve
ctr demos inside one Peak kernel.
ask "…" drives a bounded planner over allowlisted tools with policy, audit, and write approval.
04 — Not solving
/bin/* builtins — not Debian userspace on a hobby kernel.
ctr is not runc. PeakVec is local hashed embeddings only.
05 — What’s interesting
Most demos cheat quietly. Peak encodes the cheat as a CI failure — BootInfo ABI, thin HAL seams, portable VFS/GUI/net/agent above them.
Policy, audit, GUI write approval, and local semantic recall without cloud embeddings. The claim is not “we have an LLM.”
TLS with WebPKI, software-composited desktop, explicit-fetch browser, tiny container runtime — asking: does the stack compose?
06 — Architecture
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.
That path is why the screenshots are not a theme skin over someone else’s kernel.
07 — Proof surface
Captured from the guest framebuffer. Open source at github.com/peakevergreen/peak-os.
08 — Status & honesty
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.
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.
Built by Peak Evergreen
Peak OS is open-source Peak Evergreen research — the same team that ships client products and Shell Forecast.