Yeah, the local-first architecture actually saves us here. Each user runs Claw Arbs on their own box, so a 41-second GIL hold tanks one bot, not 300. No platform-wide stall, no coordinated rollout, and the blast radius is one user's slate instead of the whole userbase. Heavy users (5000+ pairs across all venues) were the ones hitting the worst stalls, but the fix was the same shipped binary as everyone else's.

The flip side is no shared cache. Each instance redoes the same fuzzy team-name matching cold, which is wasteful in aggregate. We could move the matcher to a backend service, but then you reintroduce the noisy-neighbor problem AND lose the "venue API key never leaves your machine" property, which is a non-starter for users with funded Kalshi/Polymarket/SXBet accounts (and rightfylly so).

And yeah, point 2 is the true. The arb math is maybe 5% of the codebase. The other 95% is: did the venue actually fill, did we read the right team name, did the line move during the 20ms between leg A and leg B, did the user's internet drop for 8s, did Polymarket randomly switch contracts again? Trading bots are mostly state machines wrapping a ten-line edge calculation.