Check the arithmetic in that worked example before you reuse it. One thousand users times three calls is three thousand calls, and the author prices it as 3,000 calls per second at peak [2]. Ten minutes at that rate is 1.8 million calls, so the figures agree with each other [18]. They agree on one condition: every user's pipeline finishes and fires again inside a second, with three sequential calls each returning 200 output tokens [2]. Treat 1.8 million as the ceiling for that test shape, not a forecast.
No rate card is named for that scenario [3]. An earlier one in the same post is priced: 100,000 requests, $3,000 [4], which is 3 cents a request [15]. Splice the two and the ten-minute run lands near $54,000 [16]. I would not take that number to a finance team, because the two scenarios were written for different purposes, but it establishes the shape. At roughly 1.8 billion tokens [14], your negotiated rate decides the invoice, not your harness.
The measured part of the post is the part worth borrowing. Anthropic's web_search tool injects 30,000 to 40,000 tokens of retrieved content into the context window per call [5]. Set that against the 800 input tokens in the worked scenario and the provider is supplying 37 to 50 times the context you authored [17]. The two per-lead figures divide to 1.95, so the 2x label is rounding, not hand-waving [19]. On that pipeline the Researcher node ended up costing more than the Judge node, which the team says surprised them [7]. For the 2x to transfer to your load run, your scenario has to contain tool-augmented calls where the provider injects content you do not control. If it does not, your estimate is wrong for some other reason. And if your mock pins tool output to a recorded fixture [10], you have deleted the exact variance that produced the overrun.
What a stub cannot produce is the provider's rate limiting. The post is direct about the tradeoff: a local proxy built on WireMock or a FastAPI stub gives zero spend, controlled response shapes and reproducible runs, at the price of wrong latency profiles and no provider-side limiting, which is often the behaviour you wanted to stress [9]. Everything else on the validation list (queue depth, retry backoff, circuit breakers, timeout handling) is your own code, and it needs only real HTTP round trips and plausible latency [8]. So the honest budget has two lines, a stub for the deterministic half and a short capped run against the live endpoint for the half the stub invents. Capped accounts get called the most honest and the least reproducible option in the same passage [11]. A run that halts at $500 has measured your billing configuration [11].
Underneath all of it sits one premise: no provider ships the flag [1]. That is asserted by the author on dev.to, with no citation to any provider's API reference [20][21]. It is the premise a mocking budget rests on, and it is the one thing the piece does not evidence. The cost figures are presented as measured on the author's own pipeline [6]; the provider-coverage claim carries no such backing [21]. Read your own provider's docs for a dry-run or validate-only parameter before you fund a fixture corpus, and note that if your correctness depends on response content rather than response shape, the post says mocking will not help you at all [12].
The failure mode in recorded replay is organisational rather than technical. The post describes teams maintaining a parallel corpus of fixtures that nobody owns and everybody depends on, drifting every time a provider schema or a prompt changes [10]. Budget the mock layer as infrastructure and it gets a named owner and a drift check; budget it as a testing chore and your load results quietly stop describing the system you ship.
