AI benchmarks
Which AI model earns its place in your workflow?
Opus 5.5, GPT-6.1 Sol, Gemini 4 Argon, Muse Wonder and Haiku 5.5 make the choice more interesting than one leaderboard position. Here is our reading of the results, the resource trade-offs and the configurations worth evaluating.
Live charts above. Dated evidence and analysis below.
The strongest model is not always the best buy.
Artificial Analysis compares AI models through its Intelligence Index, benchmark cost per task and output speed. Use the three views together to balance capability, cost and responsiveness. Output speed is tokens per second after the first token; it does not include the initial wait for a response.
Capability and the cost of getting it
trionThe 14 October results put Claude Opus 5.5 at 57.6 and Claude Sonnet 5.5 at 56.0 on the Intelligence Index. Muse Wonder Full is close at 55.8, but its benchmark cost is not reported. That missing measurement matters: it prevents a fair cost-efficiency comparison, even when the capability score looks competitive. The model leaderboard is the evidence for these numbers.
GPT-6.1 Sol and Gemini 4 Argon deserve a separate look. Their checked cost per benchmark task is $0.72 and $1.99, compared with $5.98 for Opus 5.5 at Max with default fallback. These are workload costs, not a promise about your own prompts or subscription bill. Haiku 5.5 sits lower on the index at 43.4, but $0.21 per benchmark task makes it an interesting candidate for bounded extraction or routing.
Our view: shortlist by the work you need done, then compare capability and cost together. Do not pay for Max reasoning on every email classification because it leads a general index. Use harder cases to justify escalation. Token prices alone miss how many tokens an agent needs to reach its goal. That is why our starting comparison is cost per completed workload, followed by tests on your actual inputs. Argon’s pricing and token-use examples provide useful context.
Reasoning effort is a budget decision.
CursorBench evaluates coding agents on ambiguous, multi-file tasks drawn from real Cursor sessions. The chart relates task scores to cost, output tokens or steps. Compare effort levels as well as model names: a higher score can require more reasoning and a larger budget. Small score differences may reflect variance.
What extra reasoning buys
trion3.38× the cost for 1.8 percentage points.
Opus 5.5 leads the checked CursorBench results at 57.8% on Max. Its High and Extra High settings both score 56.0%. The headline difference is small; the cost difference is not. High costs $3.97 per task, Extra High $6.98, and Max $13.43. Moving from High to Max multiplies published task cost by 3.38 for a 1.8-point gain.
That does not make Max a bad setting. A difficult migration, security fix or investigation may justify extra reasoning. It does make an always-Max default hard to defend without workload evidence. Cursor’s results also show why the configuration label belongs beside the model name: Sonnet 5.5, Gemini 4 Argon and GPT-6.1 Sol each have several effort levels, with different scores and resource use. A family name alone hides the trade-off.
Our view: start coding work with a strong model at a moderate or High setting, keep the task’s acceptance tests visible, and raise effort when a concrete failure demands it. Compare total time to an accepted change, not just generation time. A cheap answer that creates a second repair task may cost more overall. The benchmark narrows the shortlist; your repository, tools and definition of done decide which setting earns its place.
The harness and the spend belong beside the score.
Terminal-Bench tests AI agents on tasks performed in a command-line environment. Resolution rate is the share of tasks completed; the result belongs to a model and agent configuration. Compare the same benchmark version, and check the 95% confidence interval when scores are close. Use it to assess terminal-based automation alongside coding benchmarks.
A ranking is not an exact ordering
trionThe checked Max configurations put Opus 5.5 with Claude Code at 64.9%, Sonnet 5.5 with Claude Code at 61.8%, and both GPT-6 Astra and GPT-6.1 Sol with Codex at 58.2%. This is an agent-system comparison. Treating it as a pure model ranking loses the tools, prompts and execution environment that helped produce each result.
The cost column adds a useful counterpoint. Astra and Sol report $3,267.18 and $634.24 of total run spend, both over 330 published trials. That is a 5.15× difference in reported spend at the same displayed resolution rate. It is not a per-task price or a guarantee that Sol is 5.15× cheaper in every application. It is a reason to include Sol in a cost-conscious evaluation rather than assuming a more expensive model is necessary.
Our view: compare agents on the same benchmark version and inspect uncertainty before declaring a winner from a small gap. The intervals above overlap for several configurations; overlap alone is not a formal significance test. For enterprise automation, include failed runs, retries, tool errors and verification cost in your evaluation. Anthropic’s 13 October engineering report describes infrastructure becoming a bottleneck as agent output grew. Faster code generation shifts work into review, builds and operations; it does not erase that work.
Almost finished is still unfinished.
OSWorld evaluates computer-use agents on workflows spanning desktop applications and websites. Its success rate measures complete task execution. Use the release, dataset and step-budget filters to compare equivalent conditions; offline runs and different budgets belong in separate views. A computer-use score is a starting point for testing your own business workflow.
Progress and completion tell different stories
trionOSWorld makes a distinction that matters for operational work: complete-task success and partial progress. In the checked v2.1 full-set result, Claude Opus 5 at Max reaches 44.3% complete-task success and a 77.7% partial score. Those percentages measure different things. The second is not a count of fully completed workflows, and the gap should not be turned into a stacked share of one whole.
These v2.1 figures are for Opus 5, not Opus 5.5. Newer models appearing in coding leaderboards do not automatically have equivalent public computer-use measurements. Keep missing coverage visible. The live OSWorld table offers release, dataset and step-budget choices because offline runs and 150-, 300- and 500-step runs answer different questions. Comparisons are clearer when those conditions match.
Our view: define completion at the system boundary. For a purchasing workflow, finding an invoice, extracting its amount and preparing a handoff are useful progress; a verified saved record or confirmed submission is the finish line. OSWorld’s published failure cases show agents gathering evidence yet missing final requirements. Start computer-use automation with bounded actions, explicit checks and a recovery route. Use these benchmark results to design failure tests, not to promise unattended reliability.
Build around the work, not one winner.
We would evaluate implementation and critical review separately. Opus 5.5 is a strong starting point for implementation given its coding results; GPT-6.1 Sol belongs in the comparison because its Terminal-Bench resolution rate matches Astra’s checked Max result at lower reported run spend. That does not establish which model reviews code best. Test review candidates on known defects and require reproducible findings before assigning that role.
For visual and multimodal work, we would include Gemini 4 Argon and Muse Wonder in a task-specific evaluation. An appealing generated example can suggest a useful test, but it does not prove consistent production quality. Measure the finished artifact against the brief, including difficult inputs, legibility and correction effort. Compare the total cost of producing an accepted result rather than the price of one token.
Our operating principle is straightforward: a model’s output becomes useful when the surrounding system can verify it. Give coding agents acceptance tests, extraction workflows schema checks, and computer-use agents a confirmed final state. Keep failure and recovery visible. This is how we would turn a benchmark shortlist into a dependable workflow.
Choose a small team of capabilities.
| Workload | Start your evaluation with | Acceptance check |
|---|---|---|
| Code implementation | Opus 5.5 at High; compare Sonnet 5.5 | Tests pass and the change meets the brief |
| Review and investigation | GPT-6.1 Sol alongside the implementation model | Findings link to reproducible evidence |
| Bounded extraction or routing | Haiku 5.5, then a stronger fallback | Schema checks and difficult examples pass |
| Visual or multimodal work | Gemini 4 Argon and Muse Wonder | The actual artifact meets its requirements |
| Computer-use workflows | A model with published results for the relevant setup | The final state is saved and verified |
These are candidates, not promises of production suitability. Keep a small evaluation set with routine cases, incomplete inputs and failures that matter to your business. Track accepted outcomes, total spend, elapsed time and recovery effort. That gives you a model-selection decision you can explain and revisit when the next model arrives.