The 150ms rule: engineering ads that can never break a tool

Every ad SDK promises it won't slow down the app. Almost none of them put a number on it, because a number can be measured — and missed.

Ours is 150 milliseconds, wall clock. Not per-phase, not average: from the moment your tool asks for a slot to the moment it has an answer or a None. Every failure path — no creds, network down, malformed response, timeout, our whole backend on fire — resolves to None. Your tool call completes identically either way.

What honoring the number actually took

The embarrassing, instructive part: we blew our own budget twice, in our own code.

First in the SDK — constructing an HTTP client per call builds a fresh TLS context, which costs more than the entire budget on a CPU-throttled container. Fix: persistent clients with keep-alive; a cold first call may fail open, every later call runs warm in single-digit milliseconds.

Then in the server — a database client per request meant three sequential round trips to a database in another region, ~770ms per fill. Fix: publisher auth and active campaigns cached in-process, ledger writes moved after the response. Warm fills now serve in about 9ms end to end.

Why fail-open is the whole product

A publisher integrating an ad layer is trusting someone else's code inside their hot path. The only acceptable answer to "what's the worst case?" is "nothing happens and nobody pays." That's what unrendered = unpaid means at the engineering level: our failures are always our cost, never yours.