1. Two Anthropic models finish level on a refreshed test
Anthropic's Claude Fable 5.2 and Claude Opus 5.5 are tied for first place with a composite score of 58 in version 2.1 of the Artificial Analysis Coding Agent Index, the independent benchmark's latest edition as of November 13, 2026. The refresh updates the benchmarks behind the index, so Opus 5.5's earlier score of 61.7 on version 2.0 no longer compares directly.
Artificial Analysis is an independent firm that measures the performance, speed and cost of AI models and publishes the results as public leaderboards. Its rankings have become a common reference point for developers and companies choosing between competing systems, and its coding index in particular is watched by teams deciding which models to deploy for software work.
The headline result is unusual in two ways. It puts two models from the same developer in a shared top position, and it arrives alongside a revision to the test itself, which means the scores now on the board describe a somewhat different task than the ones published before.
Independent measurement carries particular weight in this market. Model developers publish their own evaluation results at launch, but those figures are chosen and run by the companies selling the product. A third-party index that applies the same tasks and scoring rules to every entrant gives buyers a consistent yardstick, even if no single benchmark can capture everything that matters in day-to-day use.
2. What does the Artificial Analysis Coding Agent Index measure?
The Artificial Analysis Coding Agent Index measures how well an AI model, paired with the software that lets it act, completes realistic programming work. Rather than scoring a model on isolated questions, it evaluates the combination of model and agent harness as a single system.
A harness is the scaffolding that turns a language model into a working agent. It gives the model the ability to open and read files, run commands, inspect the results and take a sequence of actions toward a goal, instead of simply producing text in response to a prompt. Coding assistants that edit real projects depend on this layer as much as on the model underneath.
Because the index scores the pair rather than the model alone, a result reflects both the reasoning ability of the model and the quality of the tooling around it. Two deployments of the same model can, in principle, land at different scores if they run inside different harnesses.
The composite figure is built from three separate benchmarks, each given equal weight. The design is meant to reward agents that are well rounded across the main kinds of work a software engineer does, rather than ones that excel at a single narrow skill.
3. The three benchmarks behind the composite score
The first component is FrontierCode, a software engineering benchmark built by Cognition. It sets agents loose on real open-source repositories and asks them to complete genuine development tasks within existing codebases, the kind of work a professional engineer would be assigned on a live project.
What sets FrontierCode apart is its standard of success. Tasks are judged by whether the project's maintainers would actually merge the submitted work. Code that technically runs but would be rejected in review, because it is messy, poorly structured or inconsistent with the project's conventions, does not count as a pass.
The second component is Terminal-Bench, developed by the Laude Institute. It focuses on agentic use of the command line: navigating a system, running tools, chaining commands and handling the output, all within a terminal environment. Much real engineering work happens in exactly this setting, from configuring builds to debugging deployments.
The third component is SWE-Atlas-QnA-AA, which tests repository question answering. Here the agent is handed an unfamiliar codebase and asked questions about it, and it is scored on whether it understands the project well enough to answer accurately. The skill is less visible than writing code, but it underpins almost everything else an engineer does, since changes made without understanding a system tend to break it.
4. Why Claude Opus 5.5's score fell without the model changing
Claude Opus 5.5 led the previous edition of the index with a score of 61.7. In version 2.1 it sits at 58, level with its newer sibling. On its face that looks like a decline, but the model being tested has not changed; the test has.
Version 2.0 introduced the current three-part structure. Version 2.1 keeps that framework intact while updating the underlying benchmarks, and harder or different tasks naturally move the numbers. A lower result on a revised exam says little on its own about whether the model got worse.
A useful comparison is a runner who records a slower time on a hilly trail course than on a flat road race of the same distance. The athlete's fitness has not changed; the course has. Benchmark scores work the same way, which is why comparisons are only meaningful between results produced on the same version of the same test.
For readers tracking AI progress, the practical lesson is to compare models within a single index release rather than across releases. The relative ordering at a given moment is informative. The absolute number, carried from one version to the next, often is not.
Benchmark maintainers revise their tests for good reason. As models improve, older task sets become easier to saturate, and a test on which every leading system scores near the top stops telling them apart. Periodic refreshes keep an index discriminating, at the cost of breaking continuity with earlier results.
5. How Claude Fable 5.2 matched its predecessor
Claude Fable 5.2 is Anthropic's newly released model, which the company has pitched specifically for complex coding and agentic work. The index result is effectively the first independent test of that positioning on a broad, multi-part coding benchmark.
The outcome is a tie rather than a clear win. Fable 5.2 matches Opus 5.5 at the top of the table, which supports Anthropic's claim that the new model is competitive at the highest level of coding performance, while stopping short of showing that it has moved beyond its predecessor on this measure.
For developers, a tie at the top shifts attention to other factors. When two models deliver the same composite score, choices tend to come down to cost, speed, availability and how each performs on the specific mix of tasks a team cares about, since an equal average can conceal differences in individual components.
The result also reflects how closely matched the leading models from a single developer can be. When a new release lands at the same level as an established one, teams already running the older model have little benchmark-driven pressure to switch, while those starting fresh can treat the two as comparable options on coding ability and decide on other grounds.
6. Why maintainer-standard scoring matters to engineering teams
The decision to judge FrontierCode tasks by whether maintainers would merge the result moves the benchmark closer to how software is actually evaluated in practice. In real projects, working code is only the starting point. It also has to be readable, maintainable and consistent with the rest of the codebase before anyone will accept it.
An agent that produces functioning but unreviewable code creates work rather than saving it, because a human engineer must then rewrite or clean up the contribution. By setting the bar at merge quality, the index rewards output that a team could genuinely use, which makes its scores more relevant to organizations weighing whether to rely on AI agents for production work.
This approach also makes the benchmark harder to game. Passing an automated test suite can sometimes be achieved with narrow or brittle fixes. Meeting the standard of a maintainer reviewing a change requires the kind of judgment and craftsmanship that tests alone do not capture.
7. What the harness effect and equal weighting reveal
Scoring the model and harness together carries an implication that is easy to overlook: the surrounding tooling can influence results as much as the model itself. Improvements to how an agent reads files, runs commands or recovers from errors can lift its score without any change to the underlying model.
That matters for anyone interpreting the leaderboard. A strong result belongs to a specific configuration, and teams that deploy the same model through different tooling should not assume they will see identical performance.
The equal weighting of the three benchmarks has a similarly practical effect. Because each component counts for a third of the composite, an agent cannot hide a weakness in one area behind strength in another. An agent that writes good code but struggles in the terminal, or that handles commands well but misreads unfamiliar codebases, will see that gap reflected directly in its overall score.
8. What the update means beyond the leaderboard
The refresh is best understood as an engineering milestone rather than a financial one. It changes how coding agents are measured and resets the baseline against which future models will be compared, but it does not carry a direct read-through to markets.
For the AI industry, the more lasting significance lies in the direction of the benchmark. By anchoring scores to real repositories, real terminal work and real code comprehension, and by holding output to the standard of a human reviewer, the index continues to push evaluation toward the conditions agents face in practice.
The next points to watch are how newly released models place on version 2.1, and whether any challenger can break the tie at the top. Because the scores are now set on a fresh baseline, each new entry will offer a cleaner view of where the leading coding agents stand against one another.