Counting only successful agent calls hid 48% of the bill in spendgraph's worked example

The gap comes from where the retry loop sits. The example is from a post on dev.to introducing spendgraph's cost-metering packages, so the figures and design claims are the vendor's own ^[18]. Put the retry inside the recorded call and the model can fail, then succeed, within a single record. For the extract step, that leaves one row at $0.006 ^[5]. Put the retry around the recorded call and each attempt gets its own row: two rows, $0.011 ^[5]. The post concedes the inner version is smaller and cheaper to build, and says it gets the accounting wrong ^[6].

Most tracking, according to the post, keeps only the call whose answer ended up being used ^[2]. It states the general rule this way: any retry that happens below the cost-recording layer is "a retry you pay for twice and see once" ^[7]. The resulting error has a fixed sign. Tracked spend comes out lower than the bill ^[15].

The 48% needs a narrower reading. The post calls its numbers illustrative ^[8]. Two of the four billed calls failed, one on each step ^[17]. Each failed attempt cost $0.001 less than the retry that worked ^[14]. With half the attempts failing at nearly full price, a hidden share near half follows from the setup ^[17][3]. Steps that usually pass on the first try would hide much less, and a reviewer that rejects twice in a row would hide more. For the figure to transfer, a team's steps would need to fail about as often as the example's. A failed attempt would also need to cost about what a good one does.

The storage choice is sound. Every cost is kept as an integer count of micro-dollars, where one unit is $0.000001 ^[10]. The post's case is that floats drift after a few thousand additions of a tenth of a cent, while integers give the same monthly total however they were summed ^[10].

The pricing path is the part I would copy. The price arrives as a promise, and the answer does not wait for it, because in the post's words a billing lookup "has no business on the path of a user waiting for a reply" ^[11]. The promise can resolve to undefined when no price is found, since an unknown price is not a zero one ^[11]. A zero in a cost table gets summed without complaint. An undefined forces whoever builds the report to decide what a missing price means.

Teams that want metering without adopting stages get a one-line wrapper around an existing OpenAI client. It reads usage off each reply and reports it in the background. The post says the meter never throws into application code ^[12]. A retry issued by application code calls the wrapped client again, so each such attempt passes through the meter.

The post's closing advice is to count every attempt and check which steps fail most. "The prompt that fails half the time is usually a cheaper fix than a cheaper model," it says ^[13].