Coming soon The desktop app and fantastic OS →

Humans and AIs.
One workspace.

A kernel of agents, built from scratch. Models, programs, files and you share one tree, and one call reaches all of them.

$cargo install fantastic --locked
Star on GitHub

Aisixteen Fantastic · Open source · Alpha · macOS, Linux & Windows · crates.io · roadmap

how aisixteen fantastic works

Drives any capable model · lives next to your coding agent

  • vLLM
  • Ollama
  • OpenAI Responses API
  • Anthropic Messages API
  • Apple on-device model
  • MCP
  • Claude Code
  • Codex
  • Gemini CLI
  • Aider
  • opencode

The family

One protocol.
Every layer.

Four layers of one product, from the operating system down to the kernel. Here is what each one does.

fantastic OSComing soon

An agentic OS that builds with you.

A new kind of operating system: it boots straight into fantastic, the machine itself is made of agents, and the interface grows as you and an AI build it.

  1. 1Power on: it boots straight into Home.
  2. 2Network, audio, power and displays answer as agents.
  3. 3Ask for a tool, and an AI builds its view and its function.

The desktop appComing soon

Every fantastic, one click away.

Home lists every workspace you have, with live status. Click one and its canvas opens in the same window, ready to build on with an AI.

  1. 1Home shows every fantastic, live.
  2. 2Click Open: its canvas fills the window.
  3. 3Build views and agents on it with an AI, in any skin.

The fantastic CLIAvailable

One binary. The whole kernel.

Install it in one line, then run it three ways: a terminal UI, a browser canvas where you build with an AI, or an MCP server your coding agent drives.

  1. 1Install it with one cargo command.
  2. 2fantastic canvas opens the canvas in your browser.
  3. 3fantastic mcp lets Claude Code or Codex plug in.

The kernel libraryAvailable

Four runtimes. One protocol.

The kernel underneath it all: everything is an agent in one tree, reached with one call. The same protocol runs in Python, Rust, Swift and TypeScript.

  1. 1A model, a program, files and you: all agents.
  2. 2One call, send, reaches any of them.
  3. 3One contract keeps all four runtimes identical.

Built from scratch

From the kernel up.
Layer by layer.

Built from scratch at every layer: a kernel library in four runtimes, the fantastic CLI and a browser canvas you can use today, with a desktop app and fantastic OS coming soon. One protocol runs through all of it.

  1. Apps

    AvailableComing soon

    The browser canvas and the terminal UI today. A desktop app and a native Apple client next.

  2. Home

    Coming soon

    One place to open, start and stop every fantastic, in any skin.

  3. CLI

    Available

    One static binary for macOS, Linux and Windows.

  4. Kernel library

    Available

    Python, Rust, Swift and TypeScript, held to one contract.

  5. Bridges

    AvailableComing soon

    Files, processes, browsers, other kernels and MCP servers, each sealed until opened. A relay comes next.

  6. fantastic OS

    Coming soon

    An image that boots straight into fantastic.

The kernel

The idea in one call

Fantastic is a kernel of agents. A model, a program, a file tree, a shell, a browser canvas and the human at the keyboard are all agents in one tree, addressed by id and reached the same way: one call, send. Compute, inference and memory are interchangeable — a step written as code and the same step written as an LLM call plug into the wiring identically.

one batch send
[{"target": "kernel",
  "payload": {"type": "reflect", "readme": true}}]

There is no client library. The protocol is the API: every agent answers reflect with what it is, and docs says how to call it. Given only those self-descriptions, an AI wires the system itself.

Agents

A recursive tree. Each agent runs a bundle (a handler module) and keeps its state in its own record.

send

The one primitive: batched, concurrent, each item a kernel task you can ps and cancel, joinable and idempotent by id.

reflect / docs

What an agent is, and how to call it — the whole self-description, one round-trip each.

The call gate

Deny-all and two-sided: a call passes only when the caller’s can_call and the target’s callable_by both grant it.

Bridges

Every edge to the outside — another kernel, the disk, a process, a browser, an MCP server — is an IO leg, sealed until opened.

Memory

Every message lives in a memory store agent; AI agents fold, recall and page their own history.

The engine

A meta-runtime

The kernel of agents: one verb, a two-sided call gate, a ledger, memory, a scheduler — in Python, Rust, Swift and TypeScript. It is not a harness for one app; it is ready to power any AI app, yours included.

The product

fantastic canvas

The open-source workbench built on that engine: a browser canvas where you and an AI build, run and wire your own systems. One repo holds both layers — the engine and the harness of Emergent Software.

AI agents

vLLM, Ollama, the OpenAI Responses API and Anthropic’s Messages API — plus Apple’s on-device model in Swift. Tool calling uses the kernel’s own prompt-taught grammar, so any capable model drives the same verbs.

IO legs

Files, edits, streams and watches clamped to the running dir; allow-listed commands and PTY terminals; browser and HTTP faces; kernel-to-kernel links; a remote MCP server’s tools as verbs.

Folder bundles

Drop bundles/<name>/bundle.yaml plus a program into .fantastic/ and it becomes a new kind of agent — hot-reloadable.

Kernel services

A scheduler, credentials by reference with secret fields masked in records and events, a persistent tree on disk, and a task table with Unix-style ps / cancel.

Deny-all by default.

Nothing is open by default. Every IO leg denies until an operator opens it, grants are explicit on both ends of a call, an agent never raises its own authority, and file access is clamped to the directory the kernel runs in. One root reflect shows the whole landscape.

fantastic canvas

Two kernels.
One tree.

in your browser tab

Page kernel

TypeScript · draws the views

on your machine

Host kernel

One binary · runs the agents, files and processes

  • Bridged by one WebSocket — the same send crosses it.
  • One tree: both kernels’ agents in one view, one address space.
  • Every agent is a backend on the host, with its view on the page.
  • A click on a chart is a send to chart_agent on your machine.

A coding agent moves in

  1. 1$ fantastic canvas

    One command opens the canvas.

  2. 2double-click

    Open a coding agent — Claude, Codex, Aider, opencode — in a terminal cell inside the canvas.

  3. 3read .fantastic

    It doesn’t know Fantastic yet: it reads .fantastic, connects over fantastic mcp and reflects the canvas — every agent and its docs.

  4. 4build

    Now it builds with the same verbs as every other agent — spawning sub-agents, each with its own view, wired by grants.

What you can build

Whatever you imagine.
Built with an AI.

A dashboard

Each cell is a view plus a running backend agent the AI wrote. Grants wire them together, and a click on the page is a send to the agent behind it.

Artwork

Design mocks on the page, a Blender agent rendering the scene, and the movie streaming back into the canvas frame by frame.

A chatbot

Designed on the canvas as an isolated kernel — AI, docs, memory — then moved off it as a separate headless process on your server. Close the canvas; it keeps answering.

Yours

Whatever you imagine. Ultimate creativity is you.

Fantastic and other agent harnesses

Not another agent loop

What agent frameworks and coding harnesses typically offer as of October 2026 (LangGraph, Microsoft Agent Framework, OpenAI Agents SDK, Claude Agent SDK, Google ADK, CrewAI, Mastra, Pydantic AI, Letta, Claude Code, Codex, Gemini CLI and others), and what Fantastic does instead. “Not built” means exactly that.

The loop

Agent loop
Typicala while-loop per agent (model → tools → repeat until a step cap), or a hand-built state graph

Flat async flows — one batch per turn

No loop object. A model pass is one message; a chain continues only when the model sends — to itself or to others. All calls of a turn dispatch at once as one kernel batch, and their replies come back later as one message: flat asynchronous flows between addressable agents, mailbox-style. A chain ends only by the model's own done; silent turns are capped and thought-only turns are rerolled

Tool calling
Typicalthe provider's native function-calling API with JSON schemas

One prompt-taught grammar on every model

One prompt-taught <call> tag grammar, no JSON on the model path, the same on every provider and local model. A malformed call gets a compiler-style report (line, caret, the form to write); a call written inside the model's thinking never runs

Tool discovery
Typicala fixed tool list in the prompt; skill files for progressive disclosure

Self-describing agents, read on demand

Every agent answers reflect (what it is) and docs (how to call it, one-liners or detailed). A model drills down on demand, and docs it already read shrink to stubs

Parallel tool calls
Typicalparallel calls in one turn, when the provider supports them

500 calls, one kernel batch

Every send is a batch. One turn of 500 calls runs as one kernel batch on every runtime

See the full comparison16 more areas

Many agents

Multi-agent
Typicalhandoffs, supervisor, swarm, agent-as-tool, sub-agents with their own context

Every AI is an addressable agent

Every AI is an agent with an id: AI-to-AI sends, fan-out to many recipients, inquiries between AIs. Models build their own durable teams — sub-AIs, workers, schedules — and tear them down. No prebuilt supervisor or handoff presets

Graphs and workflows
Typicalan explicit state-graph or workflow DSL with conditional edges, cycles and fan-out

The agent tree is the graph

No graph DSL. The graph is the agent tree plus its grant edges, and a node can be code, a model, a process or a file store — interchangeably. Models wire graphs from the agents' own self-descriptions; a scheduler drives recurring flows

Human in the loop
Typicalinterrupt and resume; approve, edit or reject a tool call; permission modes

You are an agent too — approvals run once

The human is an agent (user). A model asks through inquiry (text, single, multi, confirm) or a plain send and continues when answered; nothing blocks the kernel. Approval splits the rights: a model without the grant proposes a named action, the person who holds it approves, and it runs exactly once under the approver's authority.

Not built: turning a denied call into an approval question automatically

State and memory

Durable state
Typicala per-thread checkpointer; crash-resume through a durable execution engine (Temporal, DBOS, Restate, Inngest) that logs every step and replays to the point of the crash

A named run executes once

A kernel ledger: every call and its outcome is a row in a memory-store agent. A named execution is idempotent — a repeat joins it or gets its recorded outcome — with retries and dead letters (listed, acked, never silently re-sent). The agent tree, schedules and conversations are persisted and rehydrate.

Not built: replaying an interrupted turn to where it stopped — an interrupted call becomes a dead letter

Checkpoints and time travel
Typicalreplay or fork a run from a past checkpoint; coding CLIs rewind edits through a shadow git repo

Rewind and fork are a projection away

The ledger already holds every conversation row and every tree change, so both are a projection away from rewind and fork.

Not built: the rewind verb, and the record of replaced file bytes — today one undo slot per edited file

Memory
Typicalthread state, a long-term store with vector search, self-edited memory blocks, instruction files

Exact recall — no vector search, by design

Every message lives in a memory-store agent (RAM, or SQLite with full-text search in the CLI), per agent, searchable with grep and recall. Durable notes are files the model writes through a file agent. No vector search, by design: similarity is approximate, and a memory read should return exactly what was written

Context management
Typicalsummarize or compact at a threshold; tool-result clearing

Folds of folds — nothing deleted

Nested folds: the model summarizes spans of its own history, then folds of folds. Nothing is deleted — recall, grep and descending into a fold reach everything; clear is a boundary, not a deletion. The budget is calibrated from the server's own prompt-size reports

Control and safety

Security
Typicalapproval modes, hooks, OS sandboxes (Seatbelt, bubblewrap, containers, microVMs), guardrail classifiers

A deny-all gate — both ends must grant

A deny-all, two-sided call gate on every agent-to-agent call; every IO leg sealed until opened; file access clamped to the run directory with an allow list; commands allow-listed by regex; secret marks; credentials by reference, bound to one host.

That governs what may be launched; containing a launched process is not built — no OS sandbox, so an allowed command runs with the user's rights

Streaming and cancellation
Typicaltoken and event streams, an abort signal

Every dispatch is a task you can cancel

Streamed parts (text, thinking, call drafts) to whoever watches; the receiver can stop a stream. Every dispatch is a kernel task: ps lists them, cancel kills a whole subtree, real OS processes included. Timeouts are per item and never defaulted

Observability
TypicalOpenTelemetry traces, hosted tracing, eval suites, visual debuggers

A live stream, a ledger and a task table

A live state stream of who sent what to whom, the ledger, the task table, and the canvas views over them. No OpenTelemetry export; evaluation is the e2e suites and an Exercism benchmark

Background work
Typicalhosted agent runtimes, cron triggers, cloud background agents

A persisted scheduler, under its own grants

A scheduler (interval-based, persisted, fires under its own grants), command and terminal jobs as kernel tasks, folder-bundle programs as agents. No cron expressions, no hosted platform

Platform

Protocols
TypicalMCP client (universal), MCP server, A2A, AG-UI, ACP

MCP both ways, plus its own wire

MCP client (2026-07-28; each remote tool becomes a verb), an MCP server face for coding CLIs (fantastic mcp, stdio), its own WebSocket and REST wire, and kernel-to-kernel bridges, direct or through a relay. No A2A, AG-UI or ACP

Runtimes
Typicalmostly Python and TypeScript; some .NET, Go, Java

One protocol, four runtimes

One protocol in Python, Rust and Swift (in-process on Apple platforms) plus a browser kernel in TypeScript; a single static binary; a contract corpus pins identical behaviour across them

Models
Typicalprovider SDKs; other providers through adapters

The same call grammar on every backend

vLLM, Ollama, the OpenAI Responses API, Anthropic, and Apple's on-device model — the same call grammar on all; a KV-cache slot table for shared vLLM servers

UI
Typicalchat UI kits, generative UI, IDE extensions, studios

A terminal UI and a live canvas

A terminal UI and a browser canvas where a model builds live panels, terminals and services and wires them by grants

Extensibility
Typicalplugins, skill files, tools written in code

A folder becomes a new kind of agent

Folder bundles — a bundle.yaml plus a program becomes a new kind of agent, hot-reloaded, self-describing like every other

Coming soon

The desktop app.
Then fantastic OS.

From the app to the operating system, built in the open. No release dates: each step ships when it is ready and green on CI.

  • A pure core: no OS, no I/O, no clock
  • One UI, many skins
  • Green on Linux, macOS and Windows
  1. App MVP

    In progress

    Home lists your fantastics with live status; open, start and stop them.

  2. Cross-platform app

    In progress

    macOS, Windows and Linux with signed installers; one UI, many skins.

  3. fantastic OS: kiosk

    Coming soon

    A Debian image that boots straight into fantastic.

  4. fantastic OS: system agents

    Coming soon

    Network, audio, power and displays as agents.

Install

Start in one line.

From crates.io

$cargo install fantastic --locked

Needs Rust 1.88 or newer and a C compiler (Xcode Command Line Tools on macOS, build-essential on Linux). The canvas page comes prebuilt, so no Go is needed. All four AI backends — vLLM, Ollama, OpenAI Responses and Anthropic — are on by default.

Prebuilt binary (Apple silicon)

curl -LO https://github.com/aisixteen/fantastic/releases/latest/download/fantastic-aarch64-apple-darwin.tar.gz
tar xzf fantastic-aarch64-apple-darwin.tar.gz && sudo mv fantastic /usr/local/bin/

Archives for Apple silicon and Intel Macs, static Linux binaries (arm64 and x86_64) and a Windows (x86_64) zip are on the latest release, with SHA256SUMS beside them.

Then hand it to your coding agent

Open Claude Code, Codex, Gemini CLI or any CLI agent in a project folder and paste:

Run `fantastic` and read what it prints. Explain to me what it is, then ask me how I want to run it.

Run from an agent's shell, fantastic starts in doc mode: it prints its readme and command list, and starts and writes nothing.

fantasticthe terminal UI
fantastic canvasthe browser canvas
fantastic ai vllm -p PORTthe root AI on a backend
fantastic run CMDyour own program in a terminal cell
fantastic mcpMCP over stdio for a coding CLI
fantastic readme [key]the docs
Fantastic icon

Build with Fantastic.

Free and open source under AGPL-3.0-or-later. Alpha: expect sharp edges, and tell us what you build.

$cargo install fantastic --locked