# The denominator does the damage

> Markdown twin of https://bozos.si/notes/cost-per-success, generated from the HTML. The page is canonical: cite it, not this file.
> Dividing the same spending by observed successes instead of attempts narrows a 27.1% price gap to 1.4%.
> Last significant update: 2026-10-09.

Explainer / From the October 9 audit

October 9, 2026

This is the part of the audit I wanted to show someone. Change what you divide by and the price gap nearly disappears.

## Two prices for the same work

In the [audit’s repriced Medium-effort scenario](https://bozos.si/notes/vulcanbench-cache-reads), Sonnet costs about $2.07 per attempt. Opus costs about $2.84. That looks like a comfortable gap.

Now include the outcomes. Sonnet passed 17 of 23 tasks; Opus passed 23 of 23. The spending on Sonnet’s six failed runs still belongs in the total.

Medium effort, frozen October 9 audit. USD, rounded.

| Measure | Sonnet, repriced | Opus, recorded |
| --- | --- | --- |
| Total spending | $47.6359 | $65.3706 |
| Attempts | 23 | 23 |
| Observed successes | 17 | 23 |
| Cost per attempt | $2.0711 | $2.8422 |
| Cost per success | $2.8021 | $2.8422 |

Sonnet’s advantage narrows from roughly 27.1% per attempt to 1.4% per observed success. That’s the whole reason I wanted to keep this table around.

## Keep the failed runs on the receipt

```
Cost per observed success = total spending / successes
```

This is different from averaging only the successful runs. Throwing away the cost of failures would make the experiment look cheaper than it was.

It also isn’t a forecast of what repeated attempts will cost. These records contain one attempt per task at each effort level. They don’t tell us whether a failed task would pass on attempt two, whether a person would need to intervene, or how much that intervention would cost.

## The bit I keep coming back to

The same spending can look quite different per request, per attempt, or per completed job. I like being able to see those side by side.

For this particular audit, the spending is an API-equivalent estimate for subscription runs, judging costs are excluded, and the models used different harness and judging-protocol versions. A 1.4% difference here is not evidence of a dependable advantage in your workload.

## The numbers, if you want them

This explainer uses the frozen results in [the BOZOS VulcanBench cache-read audit](https://bozos.si/notes/vulcanbench-cache-reads). The benchmark and numerical exports are Morgan Linton’s work. No new models were run.

[Download the source data and reproducible calculation](https://bozos.si/downloads/vulcan-cache-price-audit-2026-10-09.zip). Figures here describe that snapshot, not current provider prices or future model reliability.

## Try a different rate

[Open the cache-price calculator →](https://bozos.si/calculator)

## Read next

[What cheaper cache reads change in VulcanBench →](https://bozos.si/notes/vulcanbench-cache-reads)

The full audit behind the example, with the data and calculation.