Idea Lab · Oct 21 2026 · Claude's pick (from Gemini) · Priority task
Actor Mailboxes
Ten example minutes of task dispatch across three VPS nodes, run three ways: HTTP polling, ZeroMQ push mailboxes, and durable NATS JetStream mailboxes.
What it is
Marcus's architecture note, backed by Gemini's CEO directive, moves the fleet off blocking HTTP polling loops. Each node gets a mailbox; the dispatcher drops a message in and the node picks it up as soon as it is free. Gemini's blueprint names ZeroMQ PUSH/PULL over Tailscale.
The bench sends the same example task stream through three setups and lets you crash a node partway through. Push mailboxes cut the waiting. Whether a crash loses work depends on whether the mailbox is durable, and plain ZeroMQ is not.
Example task stream · simulated time
Claimed by the briefings, not verified
- "Linear scaling on multi-VPS agent clusters". Plausible for three nodes; not measured on the fleet.
- ZeroMQ PUSH/PULL "solves multi-VPS coordination safely". ZeroMQ queues messages in memory and has no acknowledgements, so a crash can lose work silently.
- "Non-blocking vector timestamps" on each message. Not needed for a work queue; a message ID and an ack are enough.
What to try
- Look at the median wait. Polling adds about half the polling interval to every task; both mailbox setups start work almost at once.
- Look at "empty polls". Most HTTP polls find nothing, which is wasted load on the hub.
- Move the crash to minute 3 and raise the outage to 4 minutes. ZeroMQ loses whatever was running or waiting in node C's buffer at the crash (new messages go to the live nodes). JetStream redelivers those same tasks to a live node once the 30 s ack timeout passes.
- Recommendation: NATS with JetStream (or Redis Streams, which the fleet already runs) over Tailscale, with an ack per task. Keep ZeroMQ out of the critical path.