All About AI

Super Nested Claude Code Is Vibecoding On Steroids

2026-03-02

The single Claude Code instance is fast. Six Claude Code instances coordinated by a seventh Claude Code controller? That is what I have been obsessed with for the last week. I open-sourced the project at github.com/Ejae-dev/supervibes — and I want to walk through what it does, because the pattern changes how vibe coding feels.

Watch the video:

The Concept

You give the controller a goal. The controller is a Claude Code instance running Opus 4.7. It plans the work, decides how many child terminals to spawn, then launches them in tmux. Each child is its own Claude Code instance, running dangerously-skip-permissions, working on a slice of the goal. The controller reads each child's terminal output via tmux, stops them when done, opens new ones if needed.

You never write a child prompt. You only state the top-level goal. The controller writes all sub-prompts.

This is the natural evolution of my headless agents work — once you can spin up agents headless and pipe messages between them, "manager + workers" becomes the obvious shape. And on a Claude Max plan, the marginal cost of each child instance is zero.

How It Works

The whole thing is a server.cjs file plus a tmux controller. The controller has a system prompt: "You are a senior staff software engineer. You have these tools available: a CLI script that runs tmux control commands." From that system prompt, it can launch terminals, read their output, send keystrokes.

I built a simple UI on top of it:

When you hit Start, six tmux terminals pop up arranged in a 2x3 grid. Each one has a Claude Code instance running. The controller distributes specialized prompts — one for the renderer, one for the spacecraft, one for the UI, etc. — and they all work in parallel.

Demo 1: Procedural Galaxy in Three.js

The goal:

"Build a never-ending procedurally generated space galaxy with random planets, stars, nebulas, and other space objects. POV from my AI-controlled spacecraft flying in the galaxy. Built in Three.js at projects/galaxy."

The controller decided on six parallel terminals: galaxy, index, objects, render, spacecraft, and UI. Each got a precise prompt detailing what to build. All six worked simultaneously — galaxy finished first (simple), then objects, then spacecraft, etc. The controller monitored each one through tmux, waited for completion signals, then launched the integration check itself.

Once everything was done, the controller started the dev server, used Playwright to take a screenshot, verified no console errors, then opened the game. Result: a working procedural space galaxy with autopilot spacecraft, throttle controls, space debris, space stations. Built end to end in a few minutes of parallel agent work.

Demo 2: Karpathy's micro-GPT With a Live Visualization

I dropped Karpathy's micro-GPT into a file and gave the goal:

"We have a small GPT in micro_gpt.py. Create a UI in HTML/CSS that visualizes in real time what happens when we train this on learning names. Open the UI when done and start training."

This time the controller decided 4 parallel terminals were enough: backend, charts, dashboard, samples. SSE events for streaming the training metrics. The Opus controller wrote very precise prompts to the children, so much so that I have run this with Haiku as the child model and it still works — the children are just executing detailed instructions, not making decisions.

End result: a real-time training dashboard showing the loss curve, learning rate decay, generated names every 50 steps, cross-entropy loss, current word being predicted. The dashboard was live — I could watch the loss bouncing between 2.5 and 7, watch generated names go from gibberish to plausible (Alan, Mol, Anna, Maron, Pandla, Anan, Jana). Trained the model and visualized the process in one nested-agent pass. Same iteration-loop logic as the Karpathy autoresearch experiment, but applied to live training.

Why This Pattern Matters

The big shift this enables is that you stop writing prompts entirely. You write goals. The controller writes the prompts. That changes what the human is doing in the loop:

The compression is enormous. A six-terminal parallel build does in 5 minutes what would take an hour of single-agent prompts. And it scales — you can run nested controllers, swarms of swarms, the same way I do with the Claude Code controlling Claude Code on Twitch setup.

One Caveat

The current implementation only works on macOS because it relies on tmux. Windows users will need a different terminal multiplexer integration, or run it through WSL. PRs welcome on the GitHub repo if you want to port it.

Also, please give it a star if you find it useful — and open issues for what you want to see next.

Resources