Here is the sequence inside the per-case runner. It awaits `evalCase`, the API returns 400 with "your credit balance is too low", the promise rejects, the catch block runs, and the case is pushed onto the results array as `{ pass: false, raw: "ERROR: ..." }` [4]. Downstream, that row looks identical to a skill that answered and answered wrong. The aggregator divides passes by cases and gets 0 over 96 [1].
The reporting layer then does what reporting layers do with a rate: it thresholds it. Everything under 50 percent was listed for review, which was all 24 skills [7]. A threshold that fires on every row just echoes the input back at you; it tells you the count was low, not that anything was actually wrong.
The arithmetic that should have halted the report was already in the run. The bank is four cases per skill, 96 in total [11]. Every one of the 96 raw outputs was the same 400 [2]. So 24 times 4 gives 96 rows, and the count of rows that reached the model was zero, which means the denominator behind "0%" was never filled [16]. The same run printed total spend of US$0.0000 [3]. That figure sat a few hundred lines below the table [2].
What the runner needs is three counters instead of two. Classify at the boundary: transport failures, expired keys, rate limits and quota rejections are "could not measure"; a model response that fails its assertion is "failed". When the could-not-measure counter is non-zero, do not print a rate at all, and exit with a code distinct from the one a real failure uses. The vocabulary already existed in this developer's audit system: green means looked and clean, red means looked and found something, and blind means unable to look, where blind says this round's green light does not count rather than saying there is a problem [6]. The convention lived in the report layer, not in the catch block.
Two details make this worse than a one-off. The 0/96 line had printed in the audit round before the 24 descriptions were edited, and because the check is advisory and does not block the push, every round printed it and moved on [5]. And the report did offer advice, which was to review the 24 skills scoring under 50 percent.
Treat any pass rate as a claim about one account's credentials at one moment. For the number to transfer to your machine, the run has to report how many calls actually succeeded next to the score, because a 0 percent from a rejected key and a 0 percent from a broken prompt are the same string.
The finding that did survive came from a state change, not a score: a check flipped from pass to blind and took 100 seconds, and chasing it turned up the question bank [13]. A handoff doc had said most of those 24 skills had no test cases, but all 24 had cases [12].
