Opus 5.5 is here, and we 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. Opus 5.5 produced a different result. It edged past our production baseline on bug coverage in the open-source test and made larger gains in both coverage and precision on a smaller set of harder cases. Those gains also brought more comments and higher reported token usage. The adoption question for teams is whether the additional catches justify the extra review work, and which bugs the model misses in return.
We also explored Opus 5.5’s coding abilities through an overnight project and hands-on gaming experiments inspired by Grand Theft Auto: San Andreas.
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:
// BEFORE: both jobs read retryCount = 0.
await prisma.workflowReminder.update({
where: { id: reminder.id },
data: { retryCount: reminder.retryCount + 1 },
});
// Job A writes 1. Job B writes 1.
// Two increments attempted → counter ends at 1.
// AFTER: the database increments its current value.
await prisma.workflowReminder.update({
where: { id: reminder.id },
data: { retryCount: { increment: 1 } },
});
// Job A increments to 1. Job B increments to 2.
// Both increments are preserved.
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. The differing catches make it worth testing a second reviewer alongside the first, although these runs do not establish the quality, cost, or comment volume of running 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 |
Max labeled a larger share of its OSS comments as “minor,” but that label does not mean a finding is invalid or unhelpful.
Test what higher effort changes
The harder Signal cases present a stronger 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 | Reported 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. Compare that cost with elapsed time, useful findings, lost catches, and the comments a developer must assess. A configuration is worth using when its additional findings justify the compute and the human review work for your team.
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
We also explored game development with three projects inspired by Grand Theft Auto: San Andreas. These were 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. The bots combined stunt driving and combat in Palmera Bay, completed a coastal mission in Westline, and attempted 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, while Max’s additional effort produced mixed results across complete reviews.
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 remains an open question, so teams should verify whether its lower token prices actually translate into lower production-review costs.
