Choosing a model on quality score alone can miss two things the benchmark reports separately: how often it answers and how often it beats rivals. On claim continuity classification, Claude Opus 5.5 scores 8.64 out of 10 but answers only 19% of attempts [^1]. On topic section assignment, GLM-5.3 Flash ties with GLM-5.3 on score but was never chosen best in 46 judged occasions against rivals on the same inputs [^2].

The score covers only the answers a model returns

Answer rate is the share of attempts that come back with an answer, and the quality score applies only to those answers. For Claude Opus 5.5 on claim continuity classification, that leaves the 81% of attempts that do not come back outside the score [^1]. A high score paired with a low answer rate can be a poor production choice.

Answer rates on the same task vary widely. Moonshot Kimi K3 scores 8.66 when it answers, almost the same figure as Claude Opus 5.5, and answers on 70% of attempts [^1]. Xiaomi MiMo V2.6 Flash scores 8.27 but answers on 31%, while Tencent Hy4 Preview scores 7.57 and answers on 88% [^1].

Failures also take different forms. Qwen 3.7 Plus mostly produces terse output, whereas Meta Muse Spark 1.3 mostly assigns the wrong class [^1]. Terse output is visible and can be retried; a wrong class can pass unnoticed.

A score against a bar is not a win against rivals

One way to choose is to take the cheapest model whose score clears your bar. On topic section assignment, GLM-5.3 Flash scores 8.16 (±0.49) at $0.001 per run when called synchronously rather than in batch, and GLM-5.3 scores 7.93 (±0.46) at $0.01 [^2].

The ± figure is an interval, the range of uncertainty around each score. These two intervals overlap, so the models tie on quality and cost decides between them.

Win share complicates that choice. It measures how often a model beat the others on the same input. On that measure, Claude Opus 5.5 was judged best in 11 of 30 occasions on this task, or 36.7%, against none for GLM-5.3 Flash [^2].

The two numbers measure different things: a score describes quality against a bar, not against rival answers. For GLM-5.3 Flash the two point in different directions, so its score alone cannot settle the choice.

What to do with this

  • Track answer rate alongside quality in your own evaluations, and plan for the attempts that do not come back before a model reaches production.
  • Inspect failures on your own data, and add checks that catch wrong classes, not just terse output.
  • When models tie on score, look at win share before letting price decide; if the two disagree, test the candidates on your own inputs.

Use the live benchmark at https://fronset.ai/benchmark/ to set the quality bar your application needs and to compare models on the exact task you run.