Fractal — Plasma AI<br>Skip to content

fractal<br>▾main (user)<br>▾migrate<br>▾migrate.api<br>api_client_v2<br>api_webhooks<br>api_contract_tests<br>▾migrate.ui<br>ui_checkout<br>ui_settings<br>▸migrate.db<br>db_schema_v2<br>docs<br>qa_smoke

MessagesFeedArchive<br>channel: all ▾ · show: all ▾<br>migrateit3 COMMIT: api client on v2, checkout tests green12:40<br>migrate.apiit2 wrap: webhook parity reached, 61 endpoints12:33<br>main (user)OPERATOR: keep the payments path frozen until QA12:31<br>migrate.uiit2 PREPARE: folded api it1 types into checkout12:24<br>qa_smokesmoke suite green on staging build 41212:19<br>migrate.dbschema v2 dry-run: 0 destructive changes12:10<br>migrateit2 SYNC: ui blocked on api types, plan reordered12:02<br>docsPREPARE: pulled the migration guide draft11:55

activemain.migrate<br>run 1 · iter 3 · step 5/5 (COMMIT)<br>agentclaudemodelclaude-sonnet-5sessionb4f2c9d1-88e3-47a6…<br>timecoststep12s/-$0.21/-iter9m/-$4.10/$80.00run41m/-$23.87/$300.00<br>1PREPARE completed45s$0.38<br>2PLAN completed1m$0.71<br>3EXECUTE completed5m$2.05<br>4REVIEW completed2m$0.75<br>5COMMIT started12s-<br>▸iter 2 completed8m$3.90<br>▸iter 1 completed11m$5.12

←→ panes↵ enterarrows moveesc backq quit5/13 nodes running

The Fractal TUI: the node tree, the message feed, and one node's live run.<br>Agent graphs have taken over agentic engineering. Every leading harness can now fan work out to subagents and compose them into dynamic workflows (Claude Code, for example). Long-running recursive loops, though, are not yet first-class.

Fractal is our take on recursive agent loops: a hierarchy of agents, each running its own loop, with a budget at every level. We use Fractal for some of our most complex work.

By giant tasks we mean work that outlives any single context window and branches into parts that can proceed independently: large refactors and migrations, features that span services, research and experiment campaigns. Three we've run for real:

Building FractalTech industry mapCrude-oil trading

Before open-sourcing Fractal, we pointed it at its own repository: find the bugs, stress the harness, tune the defaults. Fixes landed mid-run, so later nodes ran on a version of Fractal that earlier nodes had already repaired.<br>metawiki_math… 6 subjectsopen_problemsskeptic… 9 morechaos_drillsautoresearchmemory_marathononboard… 151 morelab_productlab_research… 4 more labssynthesis… 6 confirmation runs

iteration 1/12

Result<br>The verdict that Fractal was ready to ship came from Fractal itself: a 187-node tree found 135 issues in the tool it was running on, fixed 55 of them test-first, and kept only the improvements that held up across six different kinds of work.

nodes187<br>frictions found135<br>depth4<br>modelsClaude

Findings · Building Fractal<br>Three things about how the run worked, each visible in the repo's history:<br>The fixes landed while the run was still going<br>The run worked in three phases, with a gate between them: debug on realistic workloads, then stress-test, then optimize. At each gate, the fixes found so far were merged into the copy of Fractal the run itself was using, so the next phase's nodes started on a repaired tool. By the end, Fractal's test suite had grown from 698 to 823 passing tests, and 55 of the 135 issues the tree cataloged were fixed with a failing test written first.

The defaults were tuned by intersection, not by picking a winner<br>In its final phase, the run grew six subtrees, each pushing the default instructions that every new node starts from toward a different kind of work: wikis, research, benchmarks, product builds, numeric experiments, and meta-optimization itself. A seventh node then kept only the changes that helped across all six: 17 kept, 9 rejected. Six fresh runs on the tuned defaults completed with no steering.

It graded itself like a skeptic<br>The stress-test needed genuinely hard work, so part of the tree attacked open problems in mathematics. Every claim had to survive a skeptic node whose only job was to break it. As a control, one problem was chosen because its answer already existed in the literature. The run never saw that answer, and its blind results matched it ten for ten. The skeptics cut the other way too: one result the tree thought was new was withdrawn after its own literature search found the same result already published.

The node

A node is one agent working toward a goal in its own git worktree. Unlike a subagent inside a session, it is a persistent loop with its own branch, memory, and lifecycle. The loop continues until the agent signals completion or hits a limit you set, but you can stop it at any time. The default loop has five steps:

Prepare: pull in the parent's latest commits and fold in finished child work.

Plan: decide what this iteration will do.

Execute: make the changes in the worktree.

Review: check the diff, fix mistakes, and fold what it learned into memory.

Commit: save the iteration to the node's branch.

Each step spins up a fresh coding agent (Claude Code or Codex) in the node's worktree, and that agent is free to use its own subagents and...