What Opus 4.5's Benchmarks Actually Measure — and Why Vending-Bench Matters
A week's worth of headlines about Claude Opus 4.5 have leaned on a handful of benchmark names — SWE-bench, Aider Polyglot, Vending-Bench — without always explaining what each one is actually testing. On a quiet Saturday, it's worth slowing down and reading the model card the way you'd read any other evaluation: for what it measures, not just the number attached to it.
Four different things, four different signals
- SWE-bench Verified — real GitHub issues from real repositories, checked against the actual merged fix. Opus 4.5 posts state-of-the-art results here among frontier models, which speaks to how well it handles the messy, underspecified bug reports developers actually file, not clean textbook problems.
- Aider Polyglot — multi-language code editing across a spread of programming languages in one benchmark. Opus 4.5 improves on Sonnet 4.5 by 10.6% here, a signal about breadth rather than depth in any single language.
- Vending-Bench — a long-horizon agentic test where the model runs a simulated vending-machine business over many simulated days: ordering stock, pricing, restocking, staying solvent. Opus 4.5 scores 29% higher than Sonnet 4.5, which matters because it's testing coherence over a long task, not just single-shot correctness.
- The take-home exam — an internal engineering exam given to human candidates under a strict two-hour limit. Opus 4.5 outperformed every human who sat the same test in the same time.
No single benchmark tells you how a model will behave on your actual workload. A model that's state-of-the-art on SWE-bench but mediocre on Vending-Bench is telling you it's better at fixing an isolated bug than at running a long, stateful process unsupervised. Match the benchmark to the shape of the task you're actually planning to hand it, and treat the rest as context.