The Bot That Doesn't Blink: Zero-Downtime Hot Reload for Live Trading Systems

The worst time to touch a live trading system is when it's working. The second worst time is every other moment — because positions don't pause while you deploy.

Foresight runs 24/7 on Tesseract, monitoring 16 active market slots across 8 crypto assets on 5-minute and 15-minute timeframes, placing $5 consecutive bets on Polymarket binary options. 91.3% win rate across the last 100 live trades. The system generates real revenue on a continuous asyncio event loop — 5-second market scanner polls, Binance WebSocket candle feeds, and parallel market evaluation running in lockstep. Shutting it down to deploy a code update means missing market windows, dropping WebSocket state, and rehydrating context that the system spent cycles accumulating. The cost of a restart isn't just downtime. It's lost position awareness.

So we shipped zero-downtime hot reload on March 2nd, 2026. The bot now accepts code updates without stopping. What made it hard wasn't the mechanism — it was understanding what "stopping" actually means inside an async trading loop.

A Restart Isn't a Reboot — It's an Amnesia Event

The instinct when you need to update a running process is to stop it cleanly, swap the code, and bring it back up. That logic comes from stateless services — web servers, API handlers, anything that treats each request as independent. Foresight is not that.

The bot maintains live state across its execution: open position tracking, candle feed buffers, signal history used for momentum confirmation, and the contents of control.json and status.json — the shared files that Mission Control uses to send runtime commands and read system health. A clean shutdown flushes that context. A restart means the system wakes up blind — no candle history, no momentum baseline, no awareness of positions it opened before the restart.

The deeper issue: the 5-second scanner loop doesn't run in isolation. Each evaluation cycle reads from buffers that were built across previous cycles. Candle data streams in via WebSocket and accumulates into rolling windows. Cut the process and you cut the thread. When you restart, those windows are empty — and the first N evaluations after restart are running on incomplete signal data. At 91.3% win rate, the edge lives in the quality of those signals. A context-blind entry is exactly how you give that edge back.

The conventional restart approach wasn't just inconvenient. It was architecturally incorrect for this system.

The File-Based Control Layer Made Hot Reload Possible — Not the Other Way Around

PR #81 (the bot control panel, merged March 1st) introduced the mechanism that made hot reload achievable the next day. That ordering matters and the causation runs in a direction most engineers wouldn't expect.

The control panel added a backend router with 8 endpoints that communicate with the bot through shared JSON files — control.json for commands, status.json for state broadcast. Mission Control writes to control.json; the bot reads it on each scanner tick. No direct process signaling, no IPC socket, no message queue. Just file I/O that the bot already had to check.

That file-based contract became the reload mechanism. Rather than signaling the process to stop and restart, we signal it through the same channel it already polls: write a reload command to control.json, the scanner loop picks it up on the next tick, and the bot handles the code swap internally — preserving its runtime state because the process never stopped.

This is the head-fake in most hot reload implementations: engineers reach for process orchestration tools — supervisord, systemd, Kubernetes rolling updates — because those are the canonical answers for "how do I update a running service." Those tools work by replacing the process. Foresight needed to update within the process, because the process was the state store. The file-based control layer, which looked like a simple UI integration, was actually a stateful inversion boundary — and that's what you build hot reload on top of.

The design that looked auxiliary turned out to be load-bearing.

What "Hot" Actually Means at the Module Level

Python's importlib.reload() exists. It also has well-documented failure modes that make it dangerous in production without explicit architecture to support it. Module-level state doesn't reset. Existing references to old objects persist. Circular imports behave unpredictably. The naive implementation of "reload the module" in a running asyncio loop will corrupt state in ways that are hard to detect and harder to debug.

What we shipped instead: on reload signal receipt, the bot completes its current evaluation cycle, snapshots the critical runtime state (open positions, candle buffer references, active slot assignments), tears down only the strategy layer (the code most likely to change), and reconstructs it against the preserved state. The asyncio event loop stays running. The WebSocket connections stay open. The scanner resumes on the next tick as if nothing happened — because from the loop's perspective, nothing did.

The constraint that shaped this design: strategy files change frequently. Infrastructure files — the scanner loop, the WebSocket handlers, the position tracker — change rarely. Hot reload optimized for the high-frequency change surface, not the full system. That's why it works cleanly. A system that tries to hot-reload everything hot-reloads nothing reliably.

The scope discipline is the mechanism. Broad hot reload is a liability. Narrow hot reload, scoped to the layer that actually changes, is a surgical capability.

The Pattern That Survives Past This System

The principle Foresight exposed isn't about trading bots. It's about any long-running stateful process where the cost of restart exceeds the cost of reload complexity.

Most systems get built with the implicit assumption that restarting is free. That assumption holds when state is external — when everything important lives in a database or a cache and the process itself is disposable. When the process accumulates context that's expensive or impossible to rebuild — momentum signal history, open WebSocket streams, sequential evaluation state — restart has a hidden cost that never shows up in deployment metrics.

The key to victory lies in being able to operate at a faster tempo or rhythm than your adversary.

— John Boyd · Destruction and Creation

Boyd's observation about tempo applies directly here. A trading system that must pause to update operates at a slower cycle than the market. Hot reload is a tempo advantage — the system adapts without conceding ground. The market doesn't wait for your deployment pipeline.

The generalizable pattern: identify the inversion boundary in your system — the layer where external signals enter and internal state is exposed. Build your operational controls at that boundary. When you need to modify the system, modify through the boundary rather than around it. The boundary that already exists is cheaper and safer than the new mechanism you'd build from scratch.

Foresight's file-based control layer was designed for a UI dashboard. It became the foundation for zero-downtime deployment. That's not an accident — it's what happens when you build control surfaces at the right architectural layer from the start.

The systems that adapt fastest aren't the ones with the best restart procedures. They're the ones that never had to stop.