Every measurement travels through a gateway and a serving provider before it reaches a model, and this campaign kept catching the plumbing red-handed. Treat this section as the safety leaflet.
The bug: our gateway (TrustedRouter) silently drops the max_completion_tokens parameter when translating requests for several providers; reply length then falls to each provider's default — 4,096 tokens on some. Every truncation artefact in this project traced to that one bug. It made Fable 5 look broken (billed for thinking, delivered nothing) and framed an innocent provider (baseten happily delivers 30,000 tokens when the limit is phrased as max_tokens). Fix on our side: send both spellings. Verified same-day.
Vendor response: we reported it; TrustedRouter credited the account $20 and reported it fixed. Re-verified with the same differential probe on 6 July: not fixed — the parameter still returns exactly 4,096 tokens and an empty reply. A second $20 credit and a second claimed fix arrived on 7 July, and this one held: the same probe now sails past the wall (7,217 and 10,855 billed tokens, natural stops, answers delivered — and both scored passes on fresh hard instances at α 5.0 and 5.6). The model this route once made unmeasurable now solves hard SAT through it. The probe ships in the toolkit; run it before trusting any gateway with a reasoning workload — and run it again after every "fixed".
What this means for the card: passes can't be faked (every pass is a checked certificate), so plumbing failures only ever make models look worse, and they announce themselves as truncations and empties — which we count, disclose per row, and purge as artefacts when the pipe (not the model) was at fault. The endpoint that served every call is recorded in the released data.