A practitioner's benchmark of live API costs shows why reasoning tokens, the hidden work models do before answering, make published per token prices understate what teams actually pay.
Reasoning tokens are billed at the output rate and never shown to the caller. One pricing choice, not ten model differences, explains the 10.6x real-cost spread that the practitioner "useweckr" measured on a 2x published-rate spread across GPT, Claude, Gemini, and Kimi.
The benchmark ran 10 realistic product tasks (classification, retrieval-augmented QA, multi-turn conversation, and agentic plan-then-execute) against each provider's cost-optimized API tier. Per-token list prices across the four models differ by roughly 2x. Total cost for the same ten tasks differs by 10.6x.
What is a reasoning token? When a modern model pauses to "think" before answering, it produces internal text that the user never sees. That text counts as output tokens on the bill. The user's question is input. The visible answer is a small slice of output. The hidden reasoning is most of the bill, charged at the higher output rate.
The cleanest illustration in the dataset is a one-word classification. The model returned a single label, the cheapest possible answer. To produce it, one provider burned 197 reasoning tokens first. The caller paid for one word of output and 197 words of work it never saw (useweckr.com/benchmark).
This is not a one-engine quirk. The CostBench paper at ACL 2026 finds that leading models routinely fail to pick the cost-optimal plan when given a choice, so users get billed for the over-engineering the model picks on its own. The TerminalWorld preprint reports a separate, complementary finding: failed agent attempts burn disproportionately more tokens than successful ones, and the data shows a negative correlation between success rate and token spend. Three independent artifacts (a practitioner's live API benchmark, a peer-reviewed cost-planning paper, and an agent-failure study) converge on the same mechanism. The work the model does before it answers is the line item, and the line item is missing from the receipt.
The mechanism is one pricing choice. Vendors bill reasoning tokens at the output rate, the most expensive tier on the price sheet, then omit them from the API response. Most client libraries do not surface them either. The published per-token rates are not wrong. They are an honest quote for the visible portion of the answer. They are a misleading quote for the work.
The 10.6x number is task-mix dependent, not universal. The benchmark covers 10 tasks, the tiers are the providers' "cost-optimized" SKUs, and the exact model behind each label is not pinned down in the public page. The Reddit thread that surfaced the work has drawn practitioner attention, but it is a discovery channel, not an authority. The author also links a GitHub repo with full methodology, raw results, and the 10 task prompts. As of writing that repo returns a 404, so the useweckr.com/benchmark page is the only verifiable artifact, and methodology-level claims should be anchored to it, not to a phantom repo.
The spread would collapse if vendors surfaced per-call reasoning accounting. That is the falsifier. The gap is mainly a disclosure problem. Disclosure problems have known fixes: per-call reasoning token counts on the response object, line items on usage dashboards, and a "thinking budget" parameter that callers can set instead of guessing.
For teams buying on sticker price, three questions worth asking any vendor before the next contract: how many reasoning tokens does the cost-optimized tier emit per typical call, and is that number published per task class; does the SDK surface a per-call token breakdown, or only the visible input and output counts; what happens to billed tokens when a call fails halfway, retries, or hits a multi-step agent loop. If the answer to any of those is "we don't surface that," the sticker price is a floor, not a quote. The 10.6x spread on a 2x list-price spread is the cost of treating the floor as a quote.