Plasma opens Fractal Apache-2.0 CLI for recursive coding agents

• Fractal shipped as an Apache-2.0, local CLI for recursive coding-agent trees, and rohanpaul_ai's launch thread says there is no hosted server.
• Each agent node owns a worktree, branch, memory, lifecycle, and reviewable Git history; the launch post describes the loop as Prepare, Plan, Execute, Review, Commit.
• The control plane is budgeted at the tree level: the budget note says the root budget gets allocated to children, with caps for depth, fan-out, iterations, and wall-clock time.
• Backend coverage is wider than the headline Claude Code/Codex framing, because the backend note lists Grok Build, OpenCode, and Oh My Pi too.

Plasma's getting-started guide buries a packaging gotcha: fractal on PyPI is a metadata-only pointer to plasma-fractal. The architecture doc defines each node as four objects at once: branch, worktree, tmux loop, and data directory. The loop page says default step files are discovered live from steps/NN-.md, so the workflow itself is file-editable.

Plasma's GitHub repo describes Fractal as “hierarchical agent loops with recursive self-organization,” with Apache-2.0 licensing and Python as the main implementation language. The PyPI page lists plasma-fractal v1.0.0, Python 3.12 to 3.14 support, and install paths through pip, pipx, or uv.

rohanpaul_ai also pointed readers to the repo in the GitHub follow-up, while the plugin marketplace note said the Fractal skill can be installed for Claude Code and Codex. The same launch surfaced in rohanpaul_ai's newsletter as a tool that organizes agents into “a self-managing tree.”

Install is intentionally plain: the getting-started guide gives pip install plasma-fractal, and says pip install fractal resolves to the same package through the pointer distribution.

Plasma's architecture doc gives the compact model: a Fractal node is a git branch, a checked-out worktree, an iteration loop running in tmux, and a data directory holding task contract and config.

The structure is Git-native:

• Root: the user node starts from the branch checked out at fractal init.
• Children: agent nodes branch from parent tips and get dotted lineage names, such as main.parser.lexer.
• Isolation: node work happens in separate worktrees, so parallel agents do not share one dirty checkout.
• History: node branches keep full commit history; merges into the parent land as reviewable Git history.
• Limits: tree growth is constrained by depth, child, descendant, and budget caps.

The developer shorthand was “every coding agent gets its own branch, memory, budget, and children,” as rohanpaul_ai put it. Worktrees had already become the folk primitive for multi-agent coding, with code_star saying they probably should have used them even before agents.

rohanpaul_ai's loop note says each node cycles through five steps:

1. Prepare
2. Plan
3. Execute
4. Review
5. Commit

The official iteration-loop doc maps those to seed step files: 00-PREPARE, 01-PLAN, 02-EXECUTE, 03-REVIEW, and 04-COMMIT. A run is one fractal node start or --continue relaunch; an iteration is one pass through the step files; a step is one agent invocation.

During Prepare, parents merge ready child branches, and the same loop note says Fractal Radio provides the built-in message channel.

Memory lives as topic-based Markdown files on the node's branch, the memory note says. That makes accumulated findings versioned with the code instead of trapped in one terminal transcript.

That pairs with commit discipline: rohanpaul_ai's launch thread says every iteration ends in a Git commit, and every run, cost, and signal lands in a local SQLite database that can be watched live.

Recursive agents need boring kill switches. rohanpaul_ai's budget note lists the control surface:

• one root budget
• per-node ceilings
• depth caps
• fan-out caps
• iteration caps
• wall-clock caps

The iteration-loop doc adds one operational detail: budgets and iteration counts are per run, so every fractal node start or --continue relaunch arms the cost ceiling again. The Radio doc says every node, including the user node, gets a mailbox in the central SQLite database, with messages, read receipts, reactions, and subscriptions stored there.

Underneath, the tmux and SQLite note describes the runtime as git worktrees, tmux sessions, and a local SQLite file.

Plasma's agent-backends doc says every node runs a coding-agent CLI headlessly as a subprocess in its worktree. Fractal assembles the prompt, starts the agent, parses output, and records session, model, and cost on the step row.

The built-in backend list matches rohanpaul_ai's backend note:

• claude, Claude Code
• codex, Codex CLI
• grok, Grok Build CLI
• opencode, OpenCode
• omp, Oh My Pi

Agent, provider route, model, and reasoning effort are node configuration, according to Plasma's backend doc. Children inherit parent agent configuration by default, and step-level overrides can change the axis for a specific invocation.

Fractal landed amid a broader push to name the outer loop, which addyosmani compressed into “loops, harnesses, factories and why engineers need to own the outer loop.” A link-only post from addyosmani pointed at the same discussion.

_lopopolo's critique focused on signal: producing the thing exposes under-specification faster than getting agents to agree on a plan. Accepting a plan that later fails in execution adds another high-dimensional confounder to the failure analysis, _lopopolo's follow-up argued.

Scaling agent teams depends on grounding them in the operator's priors, acceptance criteria, and nonfunctional requirements, according to _lopopolo's agent-team reply. His preferred shape was a single agent close over the task, with misaligned code rejected statically by the codebase.