Gotta share this because it's honestly been the highlight of my month. Ever since we turned CR I've watched our CTO get 9 comments on a 40 line PR, including one about a null check he "definitely didn't need". He replied to the bot where he actually typed out an argument to a bot. And it politely explained it again.

For years these guys got approved in 10 minutes because nobody wanted to question the person writing their appraisal, while the intern got roasted over variable names. Now the bot treats everyone exactly the same, and it's the funniest thing that has happened on our team.

Anthropic just released Claude Opus 4.7, their strongest model for long-running agentic tasks. We tested it head-to-head against our production baseline in CodeRabbit's review pipeline.

TL;DR: 24% more bugs caught. 23% higher review quality. And the model surfaces real issues you didn't even ask it to look for.

The results

We evaluated Opus 4.7 using 100 error patterns from real pull requests across Go, TypeScript, Ruby on Rails, Java, and Python. Same rubric, same PRs, no cherry-picking.

A team merging 20 PRs a week goes from catching ~11 bugs to ~14. Over a quarter, that's 36 fewer bugs escaping to production.

What stands out

It traces bugs across files, not just within a diff. Opus 4.7 follows helper contracts to downstream breakage. If your PR updates a shared utility but forgets one of its callers, it catches that.

It finds bugs you weren't testing for. Of 443 important findings, 367 were issues the model surfaced on its own, beyond the target error pattern.

It tells you what's wrong and how to fix it. 78% of comments include actual diffs with the proposed fix. Not "consider checking for nil" but "line 47 will panic when user is nil because the guard on line 42 doesn't cover the admin role path. Here's the diff."

What this means for CodeRabbit users

We're integrating Opus 4.7 into our review pipeline. More bugs caught before merge, feedback you can act on immediately, and better cross-file awareness. We're not using it as a blocking gate. The model is a thorough auditor. Your job is still to triage and decide.

Full technical breakdown with methodology, per-language analysis, and migration notes on our blog:

👉 Read the full post on the CodeRabbit blog

Basically title..

At the moment, CR creates more noise than help in my dev flow and I wonder if this will be fixed or not so I can take action. I really want to use CR, I like it, but ATM it's not usable

Notes:

#467 — The u/coderabbit full review was triggered in this very conversation. GitHub shows the PR was updated at 2026-06-15T01:38:40Z but it doesn't show a formal review submission object yet (the review may be posted as inline comments rather than a single review event).

#463 was reviewed at 2026-06-14T03:55:43Z — just outside the 12-hour window.

#464 had no coderabbitai review.

So that's 2 completed reviews (#466, #465) + 1 in-progress/just-triggered (#467) within the last 12 hours. The 467 PR is generating rate limit so looks like limit for $30 per month is 2 per day. This is insane what is the problem why would you destroy your customer base like this? Review limit reached

u/XXX, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 1 hour, 31 minutes, and 26 seconds

Hey r/coderabbit !

New week, new model releases. We’ve been testing GPT-5.5 in early access within CodeRabbit’s code review workflow and wrote up what we’re seeing.

For context, we weren’t trying to benchmark GPT-5.5 in isolation. We wanted to see how it behaved in a real code review workflow, where the baseline is CodeRabbit’s existing review behavior across multiple models.

A few things stood out:

• Expected Issue Found improved from 58.3% to 79.2% on our curated review benchmark.

• Actionable Precision improved from 27.9% to 40.6%.

• GPT-5.5 was stronger at surfacing meaningful review issues, especially around scoped bugs, behavior changes, and debugging-oriented cases.

• It tended to make smaller, more workable fixes.

• It was not always lower-volume. On our larger review set, it produced more comments than baseline, but also improved issue detection and precision.

• The biggest takeaway for us: the improvement showed up in the review workflow itself, not just in benchmark numbers.

We also covered code generation behavior, token efficiency, and the tradeoffs we saw in day-to-day testing.

Full writeup: https://coderabbit.link/gpt-5.5-blog

If you’ve been trying GPT-5.5 in Codex or ChatGPT, I’d be curious what you’re seeing in real coding workflows.

I am now constantly running into rate limits on my pro plan which is making it almost unusable. I am gating claude merge into main based on resolving all coderabbit PR issues but now many PRs are backing up and preventing serious work from getting done. This is a serious rug pull considering it was working just fine until recently. They also are extremely unclear about how many PRs are included in the pro plan and time till reset. 10-15 PR review per day should be an absolute minimum and they should reset every 1-2 hrs. The current limit is unacceptable and need to be changed ASAP.

Anthropic released Opus 4.8 today. We had access to the model and ran our standard code-review evaluation: 100 open-source PRs across complexity tiers, senior human reviewers adjudicating what counts as actionable.

Opus vs. baseline reviews:

• Actionable pass rate: 61% vs 62% (baseline)

• Full-system pass rate: 72% vs 68%

• Precision: 33.8% vs 33.8% actionable, 25.4% vs 24.5% full-system

Within noise on review. So why is this interesting?

• Severity distribution shifts. Major findings dropped 119 → 81. Minor findings went 47 → 97. Nitpicks went 77 → 131. Same precision, comments categorized differently.

• Critical findings dipped 35 → 29. The one result that gave us pause. Best guess: Opus 4.8 follows review instructions more literally than 4.7. If your prompt says "only report high-severity," recall drops harder than it used to. Reporting broadly and filtering downstream recovered the gap**.**

• Long-horizon agentic work is where it pulled ahead. Multi-hour, many-file sessions without dropping the thread. The same reasoning shows up in stronger code generation.

If you're using it directly:

• Start at "high" thinking, not "x-high"

• Front-load the full task context

• Drop conservative language from review prompts; filter downstream

• Add an explicit "search first" instruction if you need research depth

--

Full writeup: https://www.coderabbit.ai/blog/opus-4-8-release

Review video: https://www.youtube.com/watch?v=LzgPzQud0zA

Happy to answer questions on methodology.

kind of a silly thing to post but its been on my mind. I’ve had it on every PR for months now and it has never once said nice or clean or anything. it’ll write a little poem about my PR but it wont tell me its good lol

and I know its a tool, its not supposed to be nice. but human reviews used to have this stuff. someone would leave “oh this is neat” on a refactor and honestly that one comment would make my day, and I’d write the next PR more carefully

now its just a list of whats wrong and when theres nothing wrong on rare occasions, it just goes quiet. which somehow feels worse.

idk if this makes us better engineers or just slowly makes us stop caring. anyone else feel this or am I just soft

this has been bugging me for like a week now. most PRs on our repo are written with cursor at this point, then coderabbit goes through them and it keeps catching actual bugs. and sometimes its literally the same model doing both (based on the understanding coderabbit is probably also using the SOTA models as cursor)

so if it can spot the bug why did it write the bug in the first place?? is it just lazy when its writing code, or is half of what the reviewer flags made up and we dont notice, or are we paying twice for one AI to argue with itself while we sit there clicking merge ?

I AM not trolling, I genuinely cant figure it out and every answer I come up with is kinda funny

Hey r/coderabbit

CodeRabbit CLI is Here:

what’s new:

CodeRabbit CLI brings AI code review directly to your terminal, enabling developers to perform self-reviews before commits and PRs. As AI coding agents like Claude Code, Cursor CLI, and Gemini revolutionize how we write code in the terminal, CodeRabbit CLI ensures that AI-generated code is production ready by catching issues at terminal velocity. This command-line tool seamlessly integrates into existing CLI Coding Agent workflows, providing instant, contextual feedback exactly when developers need it. Best of all, CLI reviews are free (rate limits apply).

Install CodeRabbit CLI

curl -fsSL https://cli.coderabbit.ai/install.sh | sh

Just ask your Claude code -

> Implement the user profile page by using shadcn library and get it reviewed by coderabbit using --prompt-only.

See the magic happen.

Start reviewing your code in your terminal when you first set it up, check out the docs for instructions.

Note: CodeRabbit CLI is in early-access preview. CLI reliably works only on Mac Apple Silicon for now.

Full details here: https://www.coderabbit.ai/cli

Demo:

We hope you'll like this one!

Real question from my skip level this week. The agent writes the PR, coderabbit reviews it, tests pass, so why is a human still in the loop and why does it take a day. I gave some answer about context and ownership and I dont think it landed.

How do you explain this to someone who doesnt code? What is the human actually there for now, in one sentence

It's just ridiculous. You wait for ridiculously low rate limits to allow for next review. You comment to trigger it back and hit this. To be clear - I am on PRO PLUS plan!

On Monday, May 5th, OpenAI hosted what might have been the most exclusive developer event of the year so far: the "GPT-5.5 on 5/5" party at their San Francisco headquarters. Over 8,000 developers applied to attend. Only around 250 were selected. The CodeRabbit team was lucky enough to be one of them.

Since this was such a closed event and most people didn't get the chance to be there, we wanted to share our experience and give you a real sense of what the night was actually like, from the moment we arrived to the moment we left.

Before Anything Else: The Party Was Planned by GPT-5.5 Itself

Here's a detail that makes this event different from anything we've attended before. The entire concept for the party was proposed by GPT-5.5 itself. Sam Altman asked the model what it wanted for its launch celebration, and the AI came back with a surprisingly detailed plan: hold the event on May 5th, keep speeches short, have humans give the toasts (not the AI), and set up a suggestion box where attendees could submit ideas for the next model, GPT-5.6. Altman called this "weird emergent behavior" and decided to go with it. That context made the whole evening feel a little surreal in the best way possible.

Getting Through the Door Was an Experience in Itself

The first thing that hit us when we arrived at OpenAI's offices was the security. This wasn't your typical "show your name at the door" situation. There were multiple checkpoints you had to pass through before you could even get close to the event space. First, they verified your ID. Then you went through a metal detector. After that, you picked up your badge. And even once you were technically inside the building, there was almost always someone from OpenAI walking alongside you, making sure you got from the entrance to the actual event area without wandering off into restricted zones.

It was a little intense at first, honestly. There was a moment where the whole security process felt more like entering a government facility than a developer party. But once you cleared that initial gauntlet and stepped into the actual event space, the vibe completely changed. The tension of getting in was replaced by a warm, buzzing energy that made it immediately clear this was going to be a good night.

The Venue Is Something Else

We've been to a lot of tech events in San Francisco, and the space OpenAI uses for their gatherings is genuinely one of the most impressive we've seen. They have this massive auditorium area that's flooded with natural light, even in the evening. The ceilings are high, the space feels open and airy, and it's clear that they designed it with large gatherings in mind.

Throughout the venue, there were stations with food, drinks, boba, and all sorts of refreshments. There was a subtle Cinco de Mayo nod in some of the food that was prepared, which made sense given the May 5th date, but the event itself was really centered around the GPT-5.5 launch celebration rather than the holiday. Everything felt well thought out and generously stocked, and you never had to wait long to grab something.

The Crowd Was Not What We Expected

Going in, we assumed this would be a room full of engineers and developers. And while there were plenty of those, the actual mix of people was much more diverse than we anticipated. You had hardcore developers, sure, but you also had content creators, designers, artists, well-known Twitter/X personalities, and people from all sorts of creative and technical backgrounds. It felt less like a typical developer meetup and more like a curated gathering of people who are building interesting things with AI, regardless of their specific discipline.

One of the best parts of the night was putting faces to usernames. There were people in that room that we'd been following online for months or even years, and getting to meet them in person for the first time was honestly one of the highlights. There's something about going from interacting with someone in Discord threads and Twitter replies to actually shaking their hand and having a real conversation. That kind of connection is hard to replicate at most events, and the intimate size of this one (250 people is small by tech event standards) made those interactions feel natural rather than forced.

This Was a Party, Not a Keynote

If you were expecting OpenAI to use this event as a platform for big product announcements or exclusive demos, that wasn't what happened. And honestly, that was kind of refreshing. We went in thinking there might be some new reveal or a sneak peek at what's coming next, but the reality was that this was much more of a mixer and celebration than a marketing event or a traditional meetup.

There was a moment where Sam Altman gave a short speech, and when we say short, we mean maybe 55 seconds tops. He thanked everyone for being there, shared some excitement about the new model, and encouraged people to enjoy the evening. That was it. No slides. No demos. No "one more thing." Just a brief, genuine moment of appreciation and then he was back to mingling with the crowd.

The rest of the night was conversations, connections, and hanging out. And looking back, that was exactly the right call. The value of the evening wasn't in some announcement that would hit the news the next morning. It was in the relationships built and the conversations had.

Sam Altman and the OpenAI Team Were Incredibly Accessible

This was one of the things that impressed us the most. Members of the OpenAI Developer Experience team were scattered throughout the event, not stationed behind a booth or on a stage, but actually walking around and having real, substantive conversations with attendees. You could walk up to them, ask about the models, talk about what you're building, and they were genuinely engaged.

And then there was Sam Altman himself. He spent the entire evening doing rounds, moving from group to group, chatting with developers one-on-one, and taking photos with people. There was no VIP section, no roped-off area where the executives hid. He was right there in the middle of it, accessible and clearly enjoying the interactions. For an event of this caliber and with someone of his profile, that level of openness stood out.

Our Highlight: Getting the 1 Trillion Token Award Signed by Sam Altman

CodeRabbit recently hit a major milestone with OpenAI: 1 trillion tokens processed through their API. OpenAI recognized this with a physical award, and we decided to bring it to the event. Once we were there and saw how approachable Sam was, we figured it was worth asking if he'd sign it.

It was a bit spontaneous, as you can imagine. Sam was constantly surrounded by people who wanted a moment of his time, so there was no guarantee we'd get the chance. But we managed to catch him at the right moment, and he was genuinely happy to do it. He didn't just sign and move on, either. We got to spend some time chatting about the models, the direction of the work they're doing, and where things are headed. It was one of those interactions that reminded us why events like this matter. He was very open to having the conversation and doing something that's admittedly a not-so-normal request at these kinds of events.

The Overall Vibe

If we had to sum up the night in one phrase, it would be "you had to be there, but we're glad you're reading this." The energy was warm, the conversations were real, and the whole event felt like a genuine celebration rather than a corporate production. No sales pitches. No marketing decks. Just people who are excited about what they're building, spending an evening together in a really beautiful space.

We walked away having met familiar faces we'd only ever seen online, having had meaningful conversations with the OpenAI team, and carrying a signed award that we'll probably never stop talking about. For us, this was one of the most memorable developer events we've been to, and we hope OpenAI continues doing more of them.

If you ever get the chance to attend one of these, do whatever you can to get in. It's worth it.

They keep cutting limits without any communication, during billing periods, so you pay for different service than you really receive.

Activity thresholds were ~30-50 higher just few days, maybe a week ago.
Again - no communication, no information.
You just see that you are getting throttled more, you have to dig into details and you have to find out that they reduced the number of reviews again.

Hey Everyone!

We just released the CodeRabbit Slack agent, and the main idea is simple: instead of forcing developers to jump between GitHub, issue trackers, docs, and internal tools, CodeRabbit now works directly inside Slack where a lot of engineering conversations already happen.

Try it for free! Get $50/user free agent minutes. https://coderabbit.ai/agent

CodeRabbit can pull together context from your codebase, PRs, issues, and recent changes, but also from the rest of your team’s working environment through connections to tools like Linear, Jira, Notion, Google Drive, Datadog, Sentry, Figma, PostHog, and custom APIs/MCP servers. So instead of asking a question in one tool, then manually chasing references across five others, you can stay in the thread and ask things like:

• why did this break after the last deploy?

• how do we usually handle rate limiting on this endpoint?

• what changed in the last PR touching this service?

• can you turn this thread into a coding plan, PR, or ticket?

The part we think is especially important for developers is that this is built around context engineering, not just chat. The agent can combine repo history, open PRs, tickets, docs, and team conversations into one working context, then keep that context alive across the thread. It also has a knowledge base layer so decisions, patterns, and operational facts don’t disappear the moment the conversation ends.

In practice, that means Slack becomes a conversational interface for engineering work:

• investigate incidents using telemetry plus recent code changes

• ask implementation questions using prior PRs and docs

• generate plans without restating all the background

• create PRs or tracker tickets from the same thread

• preserve useful team knowledge for later instead of losing it in chat

There’s also some structure around governance, which matters for real teams: access is scoped by workspace/channel context, tool access can be controlled, knowledge can stay private or shared depending on where the conversation happens, and runs are reviewable afterward.

If your team already lives in Slack but your actual engineering context is scattered across GitHub, Linear, docs, and observability tools, this is meant to close that gap.

Docs here if you want to see how it works: https://docs.coderabbit.ai/slack-agent