Developer's LLM spend cap failed 4.2x over budget under parallel load, exposes billing flaw

A developer built a local spending cap for LLM API calls after finding that provider-side limits are billing alerts rather than hard stops, with documented cases including a $250 cap resulting in a $10,138 overnight charge and an AWS Bedrock run costing $30,141 with no alert fired. The custom solution intercepted API calls by patching Node.js's global fetch before any SDK code loaded, blocking requests once a cost threshold was reached. During sequential testing the cap worked correctly, but running 20 parallel calls exposed a critical race condition: all requests read a zero-spend state before any completed, allowing all 20 to pass unchecked and exceeding a $0.05 cap with $0.21 in actual spend. The fix required reserving an estimated worst-case cost synchronously before each call rather than logging cost after the response, exploiting Node.js's single-threaded event loop to prevent interleaving. The key insight is that the reservation read-modify-write must contain no await statements, as any async yield point reopens the race condition the fix is designed to close.