Opus 5.5 is here, and we've put it through CodeRabbit's review pipeline to see what changed. In our Opus 5 evaluation, higher precision came at the expense of catching fewer known bugs. For 5.5, the story is a little different: it edges past our production baseline on bug coverage in the open-source test and shows larger gains in both coverage and precision on a smaller set of harder cases.
Those gains come with more comments and higher reported token usage. The adoption question is whether the additional catches justify the extra work, and which bugs the model misses in return.
What's new in Opus 5.5
Opus 5.5 brings lower token prices, changes to reasoning and tool use, and reported improvements in coding and communication. Compared with Opus 5, five changes are important for teams building code-review workflows:
- Stronger coding performance at lower effort. Opus 5.5 at medium effort matched or beat Opus 5 at high effort on multi-step coding tasks, using roughly half the tokens.
- Lower prices per token. Input pricing falls from $5 to $4 per 1 million tokens, and output pricing from $25 to $20, a 20% reduction. Cache reads drop 60%, to $0.20 per 1 million tokens. That lowers the price of equivalent usage, but the cost of a completed review still depends on how many tokens and calls it takes.
- Thinking is always adaptive. Opus 5.5 rejects requests that explicitly enable or disable thinking. Effort becomes the main control over deliberation, latency, and cost. The recommendation is to start at medium and test low and high alongside it. At the same effort setting, 5.5 can think more per turn than Opus 5, especially at x-high and max.
- Forced tool calls are retired. Applications can no longer require the next response to call a particular tool. Workflows that depend on a tool result must check that the call occurred and handle cases where it did not. Schema enforcement still constrains a tool call's arguments. However, it does not guarantee the call.
- Deployment options and safeguards change. Fast mode is available, and the model does not require data retention. Cybersecurity safeguards remain, while a biology classifier is new relative to Opus 5. These are integration considerations. Our benchmarks do not measure their impact.
What we tested
We tested two Opus 5.5 configurations inside CodeRabbit's review pipeline against our production model mix. We call them Standard and Max. Standard combines lower reasoning-effort settings, while Max combines higher settings. These are configurations across the pipeline, rather than a single API effort value or Anthropic's default configuration.
The evaluation covered 80 known bug patterns shared by all three configurations in our OSS August benchmark, plus 13 harder cases in a separate benchmark called Signal.
We measured known issues caught, actionable precision and reported comment volume after verification, deduplication and filtering. Precision measures the share of comments that pass the benchmark judge for the target issue, rather than developer acceptance. We also examined findings outside the changed lines, which can contain valid catches excluded from the actionable-only results.
What Opus 5.5 means for your code reviews
In our Opus 5 evaluation, the x-high configuration produced more precise actionable comments than its production baseline but caught fewer known bugs. In this evaluation, both Opus 5.5 configurations caught slightly more OSS issues than their baseline, with slightly lower precision. Different test sets and configurations make this historical context, not a direct measurement of improvement between versions.
You may catch bugs your current reviewer overlooks
The strongest reason to try Opus 5.5 is that it finds a different mix of bugs. Standard caught 11 open-source issues that the baseline missed, but missed nine that the baseline caught. Switching reviewers therefore changes which bugs slip through, even when the overall score improves.
These differences include concrete correctness problems. In the Cal.com benchmark, overlapping jobs could overwrite each other's retry-count updates:
Both Opus 5.5 configurations identified this race and proposed the atomic increment. The production baseline missed it.
When evaluating a replacement, compare the bugs only your current reviewer catches with those only the replacement catches, and weigh their impact on your application. These differences also make it worth testing a second reviewer alongside the first, but these runs do not establish the quality, cost or comment volume of using both together.
Start your evaluation with Standard
Standard offers the better starting point in these runs. On the open-source benchmark, it caught slightly more known issues than Max, produced fewer reported comments and had higher actionable precision. Turning up effort did not consistently produce a better review.
Comment volume matters because someone still has to assess the findings. The counts offer a rough indication of review workload, making it important to weigh additional bug coverage against the reading and investigation those findings require.
| OSS August · 80 common patterns | Actionable recall | Actionable precision | Reported comments |
|---|---|---|---|
| Production baseline | 49/80 · 61.3% | 39.3% | 116 |
| Opus 5.5 Standard | 51/80 · 63.8% | 38.6% | 127 |
| Opus 5.5 Max | 50/80 · 62.5% | 35.7% | 140 |
Inspect prioritization as well as volume. Max labeled a larger share of its OSS comments “minor,” but that label does not mean a finding is invalid or unhelpful. Before rollout, check whether important findings are easy to identify and act on. The benchmark scores do not measure that developer experience.
Test what higher effort changes
The harder Signal cases give more reason to experiment with Max. It caught 10 of 13 issues through regular actionable comments, compared with eight for Standard and five for the baseline. Once findings outside the changed lines were included, both Opus configurations reached 10, compared with seven for the baseline.
| Signal · 13 patterns | Known issues caught | Actionable precision | Comments | Major | Minor |
|---|---|---|---|---|---|
| Production baseline | 5/13 · 38.5% | 29.4% | 17 | 11 | 6 |
| Opus 5.5 Standard | 8/13 · 61.5% | 66.7% | 21 | 14 | 7 |
| Opus 5.5 Max | 10/13 · 76.9% | 52.0% | 25 | 13 | 12 |
Major and minor are model-assigned severity labels on reported comments, not counts of distinct bugs.
Higher effort did not consistently find more bugs. Looking at the complete review, including comments outside the changed lines, Standard and Max each caught 10 of the 13 Signal issues, but they missed different ones.
For your team, the useful test is whether higher effort catches important bugs your usual setting misses, and whether it loses other valuable catches in return. Start with the lower-effort configuration, compare both on representative pull requests, and increase effort where the additional findings justify the extra token usage and review work.
What will it cost to use?
Review costs depend on both token prices and token usage. The supplied pricing guidance lists $4 per 1 million input tokens and $20 per 1 million output tokens, down from $5 and $25 for Opus 5. Cache reads fall from $0.50 to $0.20 per 1 million tokens. Those are base rates. Use the rates for the model and mode you actually deploy.
Our evaluation team reported higher token usage than the production model mix in every tested configuration:
| Reported token usage vs. production baseline | OSS August | Signal |
|---|---|---|
| Opus 5.5 Standard | +49.2% | +40.6% |
| Opus 5.5 Max | +57.6% | +60.1% |
These figures come from the team's run summary. They do not isolate input from output tokens or establish dollar cost or latency. The token increase is also a different comparison from the price reduction relative to Opus 5.
For your own evaluation, track input, output, cache-read and cache-write usage separately across the completed review, including retries, verification calls and fallback models. A short visible answer can still use substantial tokens because thinking also consumes the model's token budget. Ask for concise findings to control what developers must read, then check actual usage rather than assuming a shorter comment means a cheaper call.
Pair the bill with elapsed time, useful findings, lost catches and the comments a developer must assess. A configuration is worth using when its additional findings are worth the compute and the human review work in your use case.
Long-running coding tasks
In our podcast conversation, Gowtham, who worked on these evaluations, described giving Opus 5.5 a goal for a personal coding project and letting it work overnight. The results impressed both him and the team, reinforcing his positive assessment of its ability to handle longer coding tasks. That experience adds another dimension to the review results: some of our strongest impressions came from giving the model a substantial objective and time to work through it.
Visual game development and automation
Alongside the review benchmarks, we explored game development with three GTA: San Andreas-style projects: Opus 5.5's Palmera Bay, Astra's Westline and Fable 5.1's Sunhaven. Opus's version impressed us with its detailed environment and range of gameplay features, although it took longer to build than our Fable example. We then had Opus 5.5 build bots to demonstrate all three games: completing a coastal mission in Westline, combining stunt driving and combat in Palmera Bay, and attempting a street race before fleeing police in Sunhaven. The video shows selected runs of those bots, which read live game state and issue keyboard and mouse inputs. It's a hands-on demonstration of coding and automation, with the model writing the gameplay logic.
Our verdict
Opus 5.5 impressed us most when the work became more demanding. It showed stronger coverage and precision on our smaller, harder Signal benchmark, and our hands-on coding experiments produced substantial results on tasks that ran for hours. Those coding impressions are separate from the review benchmarks, but they reinforce our positive assessment of the model's ability to carry a complex task through.
For code review, the gains were more selective. The broader open-source benchmark showed a modest increase in coverage, with valuable new catches alongside bugs our production reviewer caught and Opus missed. Standard delivered the better overall balance; Max's additional effort did not consistently produce a better complete review.
The tradeoff is the amount of work the model does to get there. Our review runs used more tokens and produced more comments, while the more detailed coding demo also took longer. We're impressed by Opus 5.5's capability on demanding tasks. Its efficiency, including whether lower token prices translate into cheaper production reviews, remains an open question.
— Hendrik