A Connectome-Driven Fruit Fly on Your macOS Desktop

The moment your desktop starts reacting

Picture this: you move your mouse toward a corner of your screen and—without any “AI” scripts you can see—the desktop overlay suddenly behaves like it has nerves. It doesn’t track your clicks in a normal UI way. Instead, a 3D fruit fly paces along window edges, grooms itself, and only does the big “flee” response when its internal giant-fiber pathway spikes.

That’s the vibe behind DesktopFly, a macOS project that turns real FlyWire connectome data into a live, spiking simulation. The result is weird (in a good way): a desktop toy where cursor motion becomes looming input to a neuron circuit, and the circuit’s spikes become motion.

How can real synapse counts end up deciding whether a cursor gets escaped from? The short answer is that the project builds a loop:

• cursor + window geometry → sensory values (looming, wind, taps)
• sensory values → a fast spiking neural network (leaky integrate-and-fire)
• spikes → behavior modules (walk, groom, backward scoot, escape)

Let’s unpack how that loop works, starting with the “real” part.

What’s “real” here: FlyWire’s connectome → a 668-neuron circuit

A connectome is a map of neural connections: which neurons connect to which, and how strongly. In FlyWire, those connections come from large-scale reconstructions of the Drosophila (fruit fly) adult brain.

DesktopFly doesn’t try to simulate the whole brain. Instead, it extracts an escape/locomotion circuit centered around the neurons that drive turning, walking, grooming, and the famous escape pathway.

The project’s README describes the mapping in concrete numbers:

• FlyWire FAFB v783 provides 23,210 neuron soma positions (cell body locations) out of 139,255 neurons for the live brain visualization.
• The live circuit is a 668-neuron spiking network with ~19,000 real synaptic connections.

Most importantly for the “flee” behavior, the circuit includes the Giant Fiber (GF). In drosophila neurobiology, the GF is a command-like neuron population involved in escape triggering.

In DesktopFly, escape is not scripted. The code routes looming input (cursor proximity/approach) into the looming-detector neurons, and the fly takes off only when the giant fiber actually spikes. The README even highlights a timing intuition: fast approaches trigger escape in roughly a few milliseconds, mirroring the idea that inhibition and delays shape when the command neuron fires.

That’s a key modeling theme you can carry forward: the toy isn’t “controlling” a fly with a hand-built state machine. It’s running a neural circuit where behavior emerges from spike timing.

Spiking neurons in plain language: leaky integrate-and-fire (LIF)

To make a connectome “do something” in code, DesktopFly uses a classic neuron model: leaky integrate-and-fire (often abbreviated LIF).

Here’s the beginner-friendly version.

Membrane potential, but simplified

Each neuron has a value called a membrane potential. Think of it like an “electrical pressure” that rises when inputs arrive and slowly falls away over time.

• Integrate: add incoming synaptic effects into the membrane potential.
• Fire: when membrane potential crosses a threshold, the neuron produces a spike.
• Leak: between spikes, membrane potential decays back down.

Refractory period: why neurons don’t fire continuously

After a spike, a neuron enters a refractory period. During that time, it can’t immediately spike again. This is essential for realistic-looking dynamics—and for preventing the whole network from melting into constant activity.

Inhibitory synapses: signed connections

A major detail in DesktopFly is that synapse weights are signed (positive or negative), reflecting neurotransmitter predictions. In practice:

• Positive weights excite the target neuron.
• Negative weights inhibit the target neuron.

In the code, inhibition isn’t applied as an instantaneous “minus.” Instead it is often implemented via a delayed inhibitory queue (more on that in the timing section).

A small LIF sketch (not copied from the project)

The project’s implementation updates the LIF state at millisecond steps, but the core logic looks like this conceptually:

for each ms step:
 for each neuron i:
 if neuron i is refractory: decrement refractory; apply decay
 else:
 v[i] = v[i] * decay + baseline[i]
 if random() < noise_rate: v[i] += noise_kick
 if inputs arrive: v[i] += input_strength

 if v[i] >= threshold:
 neuron i spikes
 v[i] = 0
 refractory[i] = refractory_time
 schedule post-spike synaptic effects

Once you see LIF this way, the connectome part becomes much less mysterious: the connectome determines who talks to whom and with what strength/sign. The LIF model determines how that conversation turns into spike timing.

From spikes to motion: the neuron-to-behavior “translation layer”

Even with a realistic spiking circuit, a fly needs a body. DesktopFly bridges that gap with a mapping from neuron populations to motion signals.

Think of this as a translation layer:

• spikes become population activity estimates (rates, thresholds, moving averages)
• rates become drives like “walk” or “groom”
• drives enter a body controller that handles grounding, gait, and posture

Hysteresis: why state changes feel animal-like

A subtle detail in any behavior controller is that raw neural activity is noisy. To prevent flickering between states (walking → idle → walking every frame), the project uses hysteresis.

In plain terms, hysteresis means you don’t use one threshold. You use two conditions:

• enter walking only when activity is high enough
• stay walking until activity drops below a lower “off” threshold

The project’s CLAUDE notes explicitly call out hysteresis for forward walking and grooming, and they include minimum dwell times (tracked via a stateAge concept) so that transitions don’t happen too quickly.

Specific roles in the circuit

DesktopFly’s CLAUDE document lays out a current mapping (using role slugs like lc4, lplc2, gf, dna01, etc.). A simplified reading looks like:

• Looming detector populations produce nervous darting and feed the escape pathway.
• Giant Fiber (GF) spikes correspond to escape takeoff.
• Steering neurons bias left vs right turning.
• Walking neurons provide a walk/rest drive.
• Grooming neurons create a grooming drive with hysteresis.
• Backward-walking neurons trigger a burst-driven backward scoot.

The key narrative point is that behavior isn’t a direct “if GF spike then escape now” only. The system also has rhythm and gating: walking couples into proprioceptive inputs, sleep or circadian modulation changes thresholds, and sensory inputs have their own scaling.

That’s how you get something that looks like a living creature instead of a blinking LED.

Real-time on macOS: stepping 1 kHz logic inside a render loop

Now for the part developers actually have to sweat: timing.

The LIF circuit runs as a 1 kHz simulation—meaning it advances in one-millisecond steps. Meanwhile, the 3D rendering loop runs at the display frame rate (often around 60 frames per second).

Reconciling those two clocks is where many real-time projects fall apart.

DesktopFly handles it with a clear threading model.

A multi-thread handoff (and why it matters)

The CLAUDE notes describe three important categories of work:

• A SceneKit render thread calls a coordinator render/update method that advances the simulation and updates the fly.
• The main thread handles timers, menu actions, and a click monitor.
• The brain window has its own rendering delegate, and spikes cross via a SpikeBus.

Cross-thread mutation is funneled through a queued mechanism: other threads “enqueue” pending actions, and the render thread drains them once per frame. The SpikeBus uses a lock to safely pass spike events across threads.

Delivering delayed inhibition

A detail that makes the simulation feel less like toy math is delayed inhibitory action. The LIF step logic includes an inhibition delay (the project uses an inhDelayMs concept), and inhibition effects are stored in a ring buffer or queue indexed by time slots.

This matters because inhibition timing strongly shapes when threshold crossings happen. In escape circuits, “command neuron” spikes often depend on whether excitation arrives before inhibition arrives—or vice versa.

“Burst” and noise: keeping dynamics from going dead

The LIF dynamics include baseline excitability per neuron, plus a noise process (random probability of small kicks). The code also uses a burst-like mechanism to temporarily increase spiking variability.

This is the realism hack that prevents the circuit from staying in the same quiet regime forever.

The design philosophy: wiring is real, physiology is modeled

There’s an important honesty line in the README philosophy: connectomes give wiring, not full physiology.

So DesktopFly treats the connectome as the source of which neurons connect and how strongly/sign they connect. Then it overlays standard modeling assumptions:

• LIF dynamics for spiking
• neurotransmitter sign conventions (excitatory vs inhibitory effects)
• synaptic delays and inhibition timing
• sensory transduction that converts cursor behavior into “looming” values

That separation is what lets a connectome become an embodied behavior demo without claiming the toy is a perfect biophysical replica.

In other words: the wiring is borrowed from reality; the “electrical physics” is a controlled simulation choice.

If you wanted to extend it

DesktopFly’s CLAUDE notes include a “recipe” mindset for adding new neuron populations. While the project doesn’t invite casual hacking, the process illustrates a general pattern:

1. Confirm the neuron type exists in the v783 dataset metadata.
2. Update ETL scripts that classify neurons into role groups.
3. Ensure the new population has enough in-circuit synaptic partners to drive meaningful activity.
4. Wire the new population into the sim’s aggregation of rates.
5. Map the resulting activity into a behavior signal, usually with hysteresis and gating.
6. Add tests: stimulate → observe neuron-level invariants, and stimulate → observe end-to-end behavior.

That last step is the best lesson for anyone building neuromorphic demos: without invariants and behavioral tests, you can’t tell whether the network is acting because it’s correct or because it’s coincidentally noisy.

Wrapping up: a desktop that behaves like a circuit

DesktopFly is compelling because it makes a neural circuit feel tangible. Cursor motion doesn’t directly push the fly around; it becomes input to looming detector neurons. A chain of signed synaptic interactions turns that input into spike timing. The giant fiber spikes become the moment of escape.

In the end, the project is less about “a fruit fly on your desktop” and more about a developer’s translation of connectomics into real-time spiking simulation.

And once you’ve built that mental model—sensory input → LIF network → spikes → hysteretic behavior—you start seeing all the design decisions differently: thresholds, delays, refractory periods, rate estimation, and the careful bridging of 1 kHz neural time with human-visible rendering.

That’s the kind of systems thinking that turns a flashy demo into something you can actually learn from.