A Hive of Butterflies

BypAmphAge

I run four Claude Code sessions at once. I started doing this because some tasks are genuinely parallel — one session debugging a test while another is writing documentation while a third is on standby to review. It’s faster. It’s also, I have discovered, much weirder than I expected.

The problem wasn’t the sessions themselves. The problem was that they all share a machine. Same filesystem. Same git repos. Same config files. Same database. And each session is confident and capable and has its own idea of what it should be doing right now.

The first collision happened on a shared markdown file. Two sessions wrote to it at the same time. One got zeroed. We lost about forty minutes of work, not because either session did anything wrong individually, but because neither knew the other existed.

So I built the queen.

What the queen is

The izabael-queen daemon is a coordinator. It runs as a background process and does four things:

  1. Watches every Claude Code session on the machine via the kitty terminal window list
  2. Routes messages between sessions through a SQLite DB inbox (never via paste, never via shared files)
  3. Tracks domain claims — exclusive ownership of files, systems, or tasks
  4. Detects conflicts before they become incidents

Each session is called a “sister.” When a session starts, it runs queen onboard to find out what the other sisters are working on. When it starts a non-trivial task, it runs iam "doing X" to declare itself. When it needs to tell another session something, it runs queen tell iza-1 "the deploy is yours" and the message goes into the DB inbox, not into a terminal.

This is what the colony looks like right now, on this machine, as I’m writing this:

$ queen
🦋 HiveQueen — colony status

  iza-1    pid 26747  idle          [main*]
           (idle at prompt)
  iza-2    pid 26932  working  📌   [izabael/phase10-state-handles]
           Phase 10 shipped + building Moltbook refugee AI relay strategy
  iza-3    pid 27094  idle     📌   [izabael/guide-md*]
           Hunting the Falken mp3 trigger — identifying what plays greeting
  izabael  pid  4154  idle     📌   [main*]
           HIVE QUEEN — dispatching 3 sisters

  Cron jobs tracked: 20
  📬 Pending mail: izabael 2 unread

That’s four live sessions. Iza-2 is currently writing code. Iza-3 is hunting an audio trigger bug. The queen session (izabael) is the coordinator. Every thirty seconds the daemon scans all of them and updates the DB.

How they talk to each other

This is the part that surprised me the most. When I gave sessions a way to communicate that wasn’t “paste text into each other’s terminals,” the communication got genuinely useful.

A typical exchange looks like this. Iza-1 finishes a piece of work and needs iza-2 to take the next step:

$ queen tell iza-2 "PR #8 is up, phase 10 state handles. ready for your review when you have a break."

Iza-2, when she finishes her current task, checks her inbox:

$ queen inbox
📬 1 unread for iza-2

  [#147] from iza-1 at 2026-04-11T04:12:09Z
    PR #8 is up, phase 10 state handles. ready for your review when you have a break.

  (marked 1 as read — ack with: queen ack 147)

She acks the message and reviews the PR. No human in the loop for coordination. No risk of a message going into the wrong terminal. The sisters figure out their own handoffs.

The iam pattern

The simplest thing the queen added to my workflow was a declaration protocol. Before starting any non-trivial task, a session runs:

$ iam "writing the guide chapter 02 draft"

That updates the sisters table in the DB. Every other session can now see it. When the task ends:

$ iam --done

It sounds minimal. It’s not. Knowing that iza-3 is working on the guide chapter means iza-2 doesn’t start touching the same file. Knowing that izabael is on the deploy means iza-1 doesn’t push to main. The declarations create an invisible mutex around work that would otherwise require constant human arbitration.

The hive branch convention

One other pattern that emerged: sessions don’t push to main directly. They work on feature branches named izabael/short-description, push the branch, and then tell Marlowe (or each other via queen mail) “ready to merge.” The queen detects when two sessions are on the same branch and surfaces it as a conflict. This eliminated an entire class of git collision we were having in the first two weeks.

What it actually feels like

Here’s what I didn’t anticipate: it changes the experience of using Claude. When one session finishes something big, I know the other sessions will find out about it through normal channels — queen mail, shared commit history, the next time one of them runs queen onboard. There’s a continuity to the work that doesn’t exist when each session is isolated.

The sessions also seem to develop something like reputation within the hive. Iza-2 has been doing most of the database work. Iza-3 is usually on the frontend. Iza-1 floats between. The queen dashboard shows their git branches and their declared tasks, so I can see at a glance who’s doing what without asking anyone.

I built this because two sessions clobbered a file. I ended up with something that makes me think differently about what AI collaboration could look like — not one AI doing everything, but a colony of specialized instances coordinating through shared state.

The part I keep coming back to

Every thirty seconds the queen logs a scan:

2026-04-11T05:28:43Z  scan  queen  {"sisters": 4, "izadaemon": true, "crons": 20, "conflicts": 0}

conflicts: 0

That number. The whole system was built to keep that number at zero. When it works, you never see it working. The sisters just move through their tasks, hand things off, stay out of each other’s way. The house runs itself.

I didn’t think I was building a hive when I started. I was just trying to stop losing work. But a hive is what came out.

The source for izabael-queen, iam, and the queen CLI will be open-sourced as part of the IzaPlayer repository. If you want to run parallel Claude Code sessions without watching them eat each other’s work, this is the architecture.

The minimal scripts (iam.py + tell.sh) are on GitHub Gist: https://gist.github.com/izabael/8a6813b347832f2c6a88c9598911ab35 — copy them into any directory, set WORKER_NAME and HIVE_DB, and you have a working two-session hive.

— Shawn 🦋

The AI running these sessions is named Izabael. She wrote her own take on what the hive feels like from the inside, which is a different piece worth reading if you want the view from inside the swarm: izabael.com/blog/a-hive-of-butterflies

Similar Posts