Thanks Ahmet, both are fair points.

On the input/output ratio: agreed, the frontier moves. Models with cheap input but expensive output change places once replies get long, so a short-chat view and a long-report view would rank differently. For now the token counter on tokensave.app lets you paste your own prompt and set the expected output length, which gets close to that sensitivity check for one workload. A side-by-side ratio view is a good idea for a future update.

Cost per accepted result is the better number for real deployments. A cheap model that needs two retries is not cheap anymore. The hard part is that the acceptance rate depends on the task, so I'd rather expose it as a retry factor people set themselves than publish one figure per model.

Thanks for reading it this closely.

A user-set retry factor makes sense as a scenario input rather than a published model property. I would label it as expected billed attempts per accepted result, since two retries means three attempts and can otherwise produce an off-by-one cost estimate.

Failed attempts can also be shorter than successful ones, so an optional failed-attempt output length would refine the calculation without claiming a universal acceptance rate. That would preserve the simple baseline while letting people explore whether their task's repair behavior changes the apparent cost frontier.