I Turned a Fruit Fly Connectome Into an Interactive Sandbox

On September 3, 2026, a complete connectome of the male fruit fly’s brain and central nervous system was released.

A wiring diagram that large is fascinating on its own, but I kept coming back to a different question:

What would it feel like to actually experiment with it?

Not just inspect a static graph. Not just query cell types.

I wanted to place the connectome inside a world, stimulate it, perturb it, fork its state, compare what happens next, and make the whole thing accessible through a browser.

That became FlyBoxLab.

FlyBoxLab is an open-source interactive sandbox built around a FlyBrain simulation graph containing 166,700 neurons and roughly 25.6 million retained connections.

It combines a Python simulation backend, a real-time browser interface, controlled neural interventions, reproducible experiment tooling, SDKs, and a 3D activity viewer.

The result is less “digital fly” and more connectome debugger.

First: what FlyBoxLab is not#

There is an important line I wanted the project to keep visible from the beginning.

The neuroscience data is not mine. The MaleCNS connectome comes from published research, and the core FlyBrain simulation is an upstream open-source project.

FlyBoxLab also does not claim that a fruit fly has been recreated, that the system is conscious, or that every movement inside the sandbox represents biological ground truth.

A connectome tells us who is connected to whom.

It does not automatically give us a complete model of membrane dynamics, sensory transduction, muscles, biomechanics, learning, internal state, or behavior.

So FlyBoxLab explicitly separates five layers:

1. Source connectome data
2. Simulated neural dynamics
3. Experimental sensory encoders
4. Experimental motor decoders
5. Game and sandbox mechanics

That distinction became one of the most important design decisions in the entire project.

From a graph to a closed loop#

The core architecture is deliberately simple to describe:

WORLD
  ↓
experimental sensory encoder
  ↓
FlyBrain connectome simulation
  ↓
descending-neuron readout
  ↓
experimental body decoder
  ↓
WORLD

Something happens in the sandbox: food appears, a visual target moves, a looming stimulus approaches, a light changes, or an obstacle enters the environment.

The sensory encoder converts that event into stimulation for selected neural populations.

Activity then propagates through the simulated connectome.

FlyBoxLab reads selected descending-neuron populations, converts those signals through an experimental motor decoder, updates the body, and feeds the new world state back into the next simulation step.

I do not script a fixed trajectory saying “turn left now” or “move toward this coordinate.”

But the sensory and motor mappings are still engineered mappings, so I treat them as experimental interfaces rather than claiming they are complete biological models.

That closed loop is what turns the connectome from a dataset into something you can interrogate.

The scale changes the interface#

A graph with 166,700 neurons and tens of millions of connections is not something you casually dump into a browser every frame.

The first engineering problem was deciding what not to transmit.

Instead of attempting to render every neural event, the live interface exposes bounded, useful views of activity:

• firing counts;
• firing fractions;
• selected population activity;
• descending-neuron traces;
• intervention state;
• neural divergence;
• trajectory divergence.

The 3D viewer uses MaleCNS soma coordinates to give neural activity spatial context, while live spike overlays are intentionally bounded so the visualization remains useful instead of becoming a particle storm.

The goal is not to show everything.

The goal is to make the right things inspectable.

Experiments needed to be reproducible#

Once the sandbox could stimulate the network, I wanted interventions to behave like experiments rather than one-off visual effects.

FlyBoxLab can:

• stimulate named neural populations;
• silence and restore populations;
• modify sensory gain;
• introduce deterministic seeded synapse lesions;
• fork exact CPU or mock neural state;
• rewind to in-session checkpoints;
• compare multiple agents from controlled starting states;
• export and import experiment data.

The seeded lesion system is especially useful.

If two runs are supposed to compare the effect of a lesion against a control, “random damage” cannot mean a different random graph every time.

A seed makes the perturbation reproducible.

State forking solves a related problem.

Instead of running two agents that merely start in similar conditions, the system can clone the exact simulation state and then apply different interventions.

That turns a visual sandbox into something much closer to an experimental workbench.

Building a world around the nervous system#

The environment currently supports things such as:

• food and odor fields;
• visual targets;
• looming threats;
• predators;
• sound and light sources;
• walls and obstacles.

Structured experiment modes build on those primitives: food seeking, threat avoidance, races, mazes, intervention comparisons, limited-budget stimulation, hidden-intervention inference, and state-dependence experiments.

One of the most interesting parts for me is that the sandbox makes neural interventions visible at the behavioral layer.

You can modify the simulated nervous system, watch the neural telemetry change, and observe how the virtual body’s trajectory diverges from a control.

That connection between:

intervention → neural state → body → environment

is the entire reason I built the project.

The backend and frontend had to behave like one system#

FlyBoxLab’s backend is built with Python and FastAPI.

The browser application uses React and Vite.

A WebSocket protocol connects the two so simulation updates and sandbox events can move continuously between the neural backend and the interactive client.

The repository also includes Python and JavaScript SDKs, which means experiments do not have to happen through the UI.

The same environment can be controlled programmatically.

For development, I also added an explicit mock simulation mode.

It is never silently substituted for the real simulation in production. If the system is running mock state, the interface says so.

That sounds like a small detail, but for a project mixing scientific source data and experimental simulation, provenance has to remain visible.

The hardest part was not the 3D view#

The hardest problem was deciding what the software should claim.

It is very easy to build something visually convincing and accidentally imply more than the underlying model supports.

A wiring diagram is real data.

Simulated firing is modeled dynamics.

A mapping from a looming object to a neural population is an experimental encoder.

A mapping from descending-neuron activity to movement is an experimental decoder.

Those are not interchangeable facts.

So FlyBoxLab treats scientific provenance as part of the product architecture rather than a disclaimer hidden at the bottom of a page.

I think that makes the project more interesting, not less.

Once the boundaries are explicit, you can experiment aggressively without pretending that every result is a biological discovery.

What I actually built#

The connectome and simulation engine were the foundation.

My work was building the infrastructure around them:

• the closed-loop sandbox;
• FastAPI services and experiment APIs;
• the WebSocket live-simulation protocol;
• the React/Vite application;
• 3D neural activity inspection;
• stimulation, silencing, lesions, checkpoints, and state forking;
• experiment comparison and import/export;
• Python and JavaScript SDKs;
• developer tooling;
• documentation;
• automated backend tests and frontend validation;
• deployment of the frontend, API, WebSocket service, and simulation data together.

The project is open source under Apache 2.0.

Where I want to take it next#

There is a lot left to explore.

I want stronger experiment recording and timeline analysis, better circuit exploration, richer morphology rendering, improved population search, more validated sensory and motor interfaces, and easier ways for researchers or students to define repeatable protocols.

The most useful version of FlyBoxLab would not try to convince anyone that it is a perfect virtual fly.

It would make it unusually easy to ask precise questions of a very large nervous-system graph.

That is the direction I care about most.

FlyBoxLab is a playground, an experiment interface, and a connectome debugger — not a claim that I recreated a conscious fruit fly.