Hyperion is an intent-native operating system: humans express goals, and the system determines how those goals become reality.

Want the thinking behind it? Read CLAUDE.md.

Want to know exactly what's built and what's next? See the Roadmap.

See CHANGELOG.md for what's new in each release.

📑 Contents

• 🧭 Philosophy
• 🧱 Architecture
• 🚀 Getting started
• 🔨 Build it yourself
• 💬 Try it locally
• 📄 License

🧭 Philosophy

Your goals are the operating system.

Every prior operating system asked you to manage proxies for what you wanted: a process, a file, a window, an application.

Hyperion manages what you actually have.

Old OSes	Hyperion
Processes	Goals
Threads	Intentions
Files	Knowledge
Windows	Context
Applications	Memory, reasoning, capabilities

🧱 Architecture

You speak. Everything else listens.

Hyperion is built in layers, each one building on the one below it.

Closer to the hardware, it's fast and safe.

Closer to you, it understands what you mean.

L0 Kernel — where it begins

The hardware layer everything else stands on. It's open source, so its safety claims are checkable. Capability-secured from the ground up: nothing crosses a trust boundary without an explicit, revocable grant.

L1 System runtime — how it stays fast and safe

Schedules work across CPU, GPU, memory, and battery, keeping every process in its own boundary. A unified scheduler balances compute, inference tokens, and context windows, the way earlier operating systems balanced CPU and RAM.

L2 Platform services — what it's built from

Reusable capabilities, storage, updates, and networking. Capabilities are Hyperion's replacement for the application: a declared contract, a trust level, and one or more interchangeable implementations.

L3 Knowledge — what it knows and remembers

Your information, connected by meaning. Every document, photo, message, or project is a Semantic Object with typed relationships to everything else: a knowledge graph standing in for folders and filenames.

L4 Cognition — where it thinks

Understands what you're asking for, recalls what's relevant, and picks the right model for the job. The Intent Engine turns language into a graph of sub-goals. The Context Engine attaches what already exists (a calendar event, a past conversation). The Model Router picks local or cloud reasoning per task.

L5 Coordination — how the work gets organized

When a goal needs more than one specialist, this layer decides who does what, and keeps a record of why. Multi-agent orchestration assigns sub-goals to specialized agents and resolves conflicts between them. Every decision is logged for you to inspect.

L6 Experience — what you see and say

Conversation, generated screens, and voice: the only parts of Hyperion you directly touch. The Dynamic UI Runtime assembles a Workspace on demand for whatever you're doing, then tears it down when you're done. Accessibility is built into that runtime.

Example: "I need to launch my startup."

• L6 The console captures it.
• L4 The Intent Engine splits it into sub-goals — market research, a business model, branding, legal formation.
• L5 Coordination assigns each sub-goal to a specialized agent.
• L4 Each agent gets its answer by invoking a capability, routed to whichever model fits.
• L3 Everything learned along the way is written into the knowledge graph, connected to everything else you know.
• L2/L1/L0 Every one of those steps was checked against a capability grant first, and scheduled safely underneath.
• L6 The results land back as one workspace — not four separate app windows.

🚀 Getting started

Every tagged release publishes ready-to-flash disk images for both reference platforms on the Releases page:

Platform	Download	Boots via
x86_64	hyperion-x86_64-<version>.img	UEFI (GPT disk image, EFI System Partition + GRUB2)
aarch64	hyperion-aarch64-<version>-Image + hyperion-aarch64-<version>-rootfs.ext2	direct kernel boot

For most people x86_64 is the one to grab - it's a single, complete disk image.

Put it on a USB drive

1. Download hyperion-x86_64-<version>.img from the latest release.
2. Install balenaEtcher (Windows/macOS/Linux).
3. Open Etcher, select the downloaded .img file, select your USB drive, and flash. Etcher writes the raw image directly and verifies the write afterward - no need to unpack or convert anything.
4. Boot the target machine from the USB drive (usually a one-time boot-menu key like F12/F10/Esc at power-on) and select it.

Double-check the drive you select in Etcher - flashing overwrites everything on it.

Check what you downloaded

Every image ships with proof that it's untampered and really came from this project: a .release.json manifest holding a BLAKE3 hash of the image and an Ed25519 signature over that hash, signed with Hyperion's release key. Check it against the real, published verifying key before you trust it:

b5c19b1e890fed3e164342f0285f6a1a1635d724f2284a2ebe00589a122ac90a

To verify (needs a Rust toolchain and this repo checked out):

cargo run --release -p hyperion-release-gate --bin verify-release -- \
  hyperion-x86_64-<version>.img hyperion-x86_64-<version>.img.release.json

This recomputes the hash directly from the image's own bytes (it never trusts the manifest's own recorded hash) and confirms the signature checks out against the manifest's recorded key - compare that key against the one published above.

🔨 Build it yourself

See the Roadmap and the scripts under boot/scripts/ (build-image.sh for x86_64, build-image-aarch64.sh for aarch64) if you'd rather build an image from source than download one.

💬 Try it locally

For development, the fastest loop is a native build of hyperion-console on your own machine - no image, no boot:

cargo build -p hyperion-console --bin hyperion-console
HYPERION_CONSOLE_DATA_DIR=/tmp/hyperion-scratch ./target/debug/hyperion-console scenarios/backend-mock.txt

> my name is Alex
status: done -- [mock model 1] echo: my name is Alex

> launch my startup
  market_research: Done
  business_model: Done
  branding: Done
  legal_formation: Done
status: market_research: Done -- [mock model 1] echo: Provide a concise research summary about market_research -- launch my startup. ... (see "/result market_research" for the full text)
status: business_model: Done -- [mock model 1] echo: Draft a concise, practical business_model -- launch my startup. (see "/result business_model" for the full text)
status: branding: Done -- [mock model 1] echo: Draft a concise, practical branding -- launch my startup. (see "/result branding" for the full text)
status: legal_formation: Done -- [mock model 1] echo: Draft a concise, practical legal_formation -- launch my startup. (see "/result legal_formation" for the full text)

See Usage Scenarios for how scenarios work, the full set under scenarios/, and how to point one at a real backend (Candle, a local engine, or a cloud provider).

Inspecting the knowledge graph

/graph dumps everything the current session has recorded - real nodes and edges, not a summary. Run it before and after a scenario to see exactly what changed; the output is sorted by id, so an unchanged graph dumps identically every time and any real diff is a real change:

> my name is Alex
status: done -- [mock model 1] echo: my name is Alex

> /graph
1 node:
  [0] intent -- you asked: "my name is Alex" (30% confident) (created 1784044847, updated 1784044847)

0 edges:

/graph dot prints the same graph as Graphviz DOT instead, for when you actually want to draw it:

printf '%s\n' "launch my startup" "/graph dot" > /tmp/graph-demo.txt
./target/debug/hyperion-console /tmp/graph-demo.txt | sed -n '/digraph/,/^}/p' | dot -Tsvg -o graph.svg

Talking to another Hyperion instance

/mcp-server and /a2a-server turn a running console into a real MCP or A2A server over HTTP; /standby keeps the process alive afterward so you can test it from another terminal:

printf '/mcp-server 8765\n/standby\n' > /tmp/mcp-demo.txt
HYPERION_CONSOLE_DATA_DIR=/tmp/hyperion-mcp-demo ./target/debug/hyperion-console /tmp/mcp-demo.txt

From a second terminal:

curl -s http://127.0.0.1:8765/ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"hyperion.ask","arguments":{"prompt":"my name is Alex"}}}'

/mcp-call <host> <port> <tool> <json args> and /a2a-call <host> <port> <message> are the outbound half - a real Hyperion instance calling out to another one. See Usage Scenarios for a full, live-verified transcript, and the Roadmap for what's real today across Hyperion's resourceful/social/self-sustaining pillars versus what's still deliberately deferred.

To use a real cloud provider (OpenAI, Anthropic, Gemini, Groq) or a local engine that needs its own key, copy .env.example to .env, fill in the real value, then:

set -a && source .env && set +a
cargo build -p hyperion-console --bin hyperion-console --features openai-compat
HYPERION_CONSOLE_DATA_DIR=/tmp/hyperion-scratch ./target/debug/hyperion-console scenarios/backend-cloud-groq.txt

.env is already gitignored, so a real key never gets committed. A scenario file only ever references a key by name ($GROQ_API_KEY), never as a literal - see Usage Scenarios' "Running a scenario from a file" for how that expansion works.

📄 License

MIT - See LICENSE