v1.1.0 · Rust + SurrealDB · Apache-2.0

The agentic OS.

Your coding agents already run all day. SuperX captures every one of them — every message, every tool call, live and historical. Then it puts them to work: model the work as a graph, schedule it, and agents execute it in dependency order while the OS records them doing it. Every change is an insert; nothing is ever overwritten.

Install Source on GitHub

$ superx --initialize
OS: running in background (pid 1094)
UI: http://127.0.0.1:5150
kernel modules:
  kernel    active    entities  active
  capture   active    runner    active
  ui        active    hello     active
adapters:
  claude_code · gemini_cli · claude_desktop
OS running in background — capture is live.

The loop

Capture everything. Then direct it.

SuperX boots, finds the agents already installed on your machine — Claude Code, Gemini CLI, Claude Desktop — and reads their transcripts directly: full conversations, tool calls, token usage, backfilled history plus a live tail. No agent-side configuration, no hooks to install, nothing to remember to turn on. Sessions are identified agent/uuid7 and the raw transcript line is kept beside every message.

Then the loop closes. You model work as a graph of typed entities — products contain components, tasks carry instructions, tasks consult RAG sources, repos link credentials, documents attach anywhere. The runner schedules the graph: independent tasks dispatch in parallel, dependencies wait their turn, each executed by a spawned agent — whose session SuperX captures on its own dashboard. The OS directs the work and watches itself do it.

capture everything→ model work as a graph→ schedule the graph→ agents execute→ results land in the graph↺

See it

The dashboard, from a running instance

Every screenshot on this page is captured from a live SuperX instance — not a mockup. This is the core dashboard: what your agents did, what it cost, and what is happening right now.

SuperX core dashboard: agents, sessions, events captured, token and cache counters, an events-per-minute chart, a tool-usage donut, busiest sessions, message roles, boot durations and a work calendar — Status — live counters (agents, sessions, events, messages, tokens, cache hit rate, capture lag), events per minute, what the agents actually run, the busiest sessions, and a calendar built from the agent's own clock rather than capture time.

◉

Total capture

Full transcripts from Claude Code, Gemini CLI and Claude Desktop — history backfilled on first contact, then a live tail with cursor checkpoints, so nothing is lost across restarts.

▦

One live feed

Messages and actions merged in one stream over SSE, grouped by session, searchable back through all of history, each session in its own colour.

◷

Cost and context

Prompt, output and cache tokens per session and per model, cache hit rate, context pressure, and the capture lag — read from the transcripts, not estimated.

⌘

CLI everywhere

Everything the dashboard shows is a command: agents, sessions, read, actions --live, status, logs — and the Console page runs them from the browser.

The product graph

The thing your agents work on

Entities are typed nodes joined by native graph edges: 18 types seeded and extensible at runtime — product, task, rag, model, document, text, repo, credential — with contains, depends_on, consults, describes, produced and more between them. Expanding a node costs its degree, never the size of the history.

A force-directed graph of a SuperX product: 23 nodes and 32 edges, a product at the centre with task nodes around it, contains edges in grey and depends_on edges in purple — A real product graph — 23 nodes, 32 edges. Grey is `contains`, purple is `depends_on`: every build task paired with the QA task that gates it. Click a node to re-root, drag to pan, scroll to zoom.

A SuperX entity detail page: breadcrumb ancestor path in the header, a task with its description rendered as markdown, its edges, attachments and attributes — One entity. The header breadcrumb is its real ancestor path through the graph. Long-form text — descriptions, instructions, comments — are themselves nodes linked by role edges, so every edit is a new version with its own history, and files attach as document nodes.

◈

Types as data

Node and edge kinds are rows, not enums. Add review or dataset at runtime with one command — no schema change, no rebuild.

Text is a node

Descriptions, instructions and comments are text entities linked by role edges. Editing one appends a version; comments thread; one text can serve many entities.

∞

Nothing is lost

Append-only throughout: updates insert versions, unlinks insert retractions, cancels append rows. Time-ordered uuid7 ids make the substrate its own historical log.

◧

Its own dashboard

The entities module ships its own UI on its own port, discovered from the substrate and linked from the core dashboard — the module contract taken to its conclusion.

The runner

Schedule the graph; agents execute it

A schedule row says one thing: at this time, kick this entity. Everything else already lives in the graph. The runner resolves the target's subgraph, layers the task nodes over their depends_on edges, and dispatches each wave — independent tasks in parallel, dependants only after their dependencies have a successful run in this firing. Cycles are refused with the path named.

Each task spawns the agent command you configured, with a prompt assembled from the task's instructions, the product's description and the attributes of everything it links to. Output writes back into the graph as a produced text node. Every run pins the exact version of the instructions it dispatched with, and the subgraph is re-read at every wave — so editing the graph mid-run steers everything not yet dispatched.

dry run — the waves the graph implies

$ superx runner plan <product>
wave 1:
  01a01b4b-e2c6  Kernel changes
wave 2:  (parallel)
  01a01b4b-e33b  Build module A
  01a01b4b-e3b7  Build module B
wave 3:
  01a01b4b-e431  QA module A
4 tasks in 3 waves

then let it run

$ superx runner config agent_cmd claude -p
$ superx runner schedule <product> --in 10s --every 1d
$ superx runner runs
  firing 01a01b4b  task 01a01b4b-e2c6  done  → 01a01b4b-f469
  firing 01a01b4b  task 01a01b4b-e33b  done  → 01a01b4b-f54c

The executor command is a substrate parameter with no default: until you set it, dispatch refuses loudly and nothing spawns.

Modules

A kernel, and everything else is a module

Kernel — boot, discovery, the capture engine, the telemetry firehose, the append-only substrate verbs, the module registry. The hub every module talks through; modules never depend on each other.

Adapters — per-agent capture with tolerant parsers, per-file cursor checkpoints and history backfill.

Modules — each self-contained: its own database and service account, its own directory, log, CLI namespace, parameters, uuid7 identity, and optionally its own UI. Enable or disable them live; several of a kind can coexist.

Agents — spawned by the runner, observed by the adapters: the loop that makes this an OS rather than a logger.

module	what it owns	cli
kernel	the substrate, boot, the module registry	superx status · logs
capture	the capture loop over every discovered agent	superx agents · sessions · read
ui	the core dashboard — status, live feed, sessions, console	superx ui url
entities	the product graph — nodes, native edges, texts, documents, its own UI	superx entities …
runner	schedules, dependency waves, agent dispatch, write-back	superx runner …
website	this site	—
hello	the contribution template — copy it, ship a module	superx hello greet

Install

One command to a running OS

clone + build

git clone https://github.com/k8nstantin/superx
cd superx && cargo build

initialize — prompts for a password, provisions, boots, returns your terminal

target/debug/superx --initialize

confirm capture, open the dashboard, build a graph

superx sessions
superx ui url            # → http://127.0.0.1:5150
superx modules provision entities && superx restart
superx entities create --type product --describe "what it is" Widget X

Upgrades are the same three steps: git pull, cargo build, superx restart — the substrate schema self-upgrades on version mismatch.