Apex: Connecting a Python/Rust Signal Engine to IBKR via IB Gateway

Apex was a multi-strategy algorithmic trading engine that aggregated signals from six research accounts and routed the best 100 to 300 trades per day through a single production account backed by IB Gateway. The system generated signals from ten sources. The initial state after the April 2026 build was infrastructure-grade A, trading-grade F. All 150 services ran without errors. But the paper account was down 12%, and win rate across 11,895 trades stood at 10.2%. Only 1.1% of trades hit their take-profit target. All exits were time-based stop-outs.

The problem was not infrastructure. The problem was a cascade of 65+ bugs across the signal pipeline, position manager, learning subsystems, and regime gate that individually appeared minor but compounded into a system that consistently entered on noise and exited before signal.

The April 2026 debugging session fixed 65 bugs across seven subsystems. Three categories produced the most P&L damage.

Score overflow in dark_matter_rs: the Rust scoring kernel accumulated float64 values without clamping. Under specific market conditions, the accumulator overflowed the intended [0.0, 1.0] range and produced scores in the millions. The downstream signal filter treated any score outside [0.0, 1.0] as invalid and discarded all dark_matter_rs output. The fix was two lines: clamp(0.0, 1.0) before writing to Redis, plus a direction-field correction that had been mapping bullish signals to the wrong side.

Position key mismatch between allocator and position manager: the Master Allocator wrote order intents to Redis using keys formatted as apex:orders:{strategy}:{symbol}. The position manager read position state using keys formatted as apex:positions:{symbol}:{strategy}. When a fill confirmation arrived, the position manager could not find the originating order. Every trade ran to the time-based stop rather than the profit target. The fix standardized all keys to apex:fund:{type}:{symbol}.

Counterfactual simulator stuck for 2 days: the process was blocking on a SCAN_BATCH Redis operation iterating over 500,000+ keys per hour from a logging bug. The SCAN_BATCH completed in 45 minutes per cycle rather than 4 seconds. The fix redesigned SCAN_BATCH to use a bounded ring buffer capping stored counterfactuals at 10,000 entries.

The Argus-to-Apex signal interface used Redis Streams with consumer groups for at-least-once delivery. Each signal payload carried: signal_id (UUID), symbol, direction, confidence, regime classification, source binary name, feature vector hash, and a suggested Kelly fraction for position sizing.

The Apex consumer group had three members: the Master Allocator, the risk gate, and the signal logger. The Master Allocator acknowledged signals only after the IBKR order was submitted, ensuring that a crash between signal receipt and order submission would result in redelivery rather than signal loss.

The working IBKR path used IB Gateway 10.37 (not Client Portal Gateway). Client Portal had a known no-bridge issue on paper accounts that caused competing session errors and 5-minute timeout loops. IB Gateway over a single TCP socket on port 4002 had none of these failure modes. IBC auto-login handled the mandatory 23:55 UTC daily restart cycle by re-authenticating automatically.

65 bugs fixed in a single audit session. Signal filter pass rate corrected from approximately 0% (score overflow blocking all dark_matter_rs output) to 22% of candidate signals. Infrastructure load reduced from CPU load 32 to 19 by fixing the SCAN_BATCH key explosion. Redis memory reduced from 11.8GB to 7.15GB by purging orphaned counterfactual keys. IB Gateway uptime: 100% over the 7-day observation window. Zero no-bridge errors after switching from Client Portal.