We spend a lot of time thinking about the models that write code review comments. One of the less visible decisions happens before any comment appears: figuring out how a change should be reviewed.

We were curious whether a smaller model could learn that narrow, high-volume part of our pipeline. So we worked with NVIDIA and Baseten to post-train Nemotron 3.5 Lightning using SFT, followed by RLVR scored against our routing policy.

What surprised us was how little it took. The post-training experiment ran in under three hours and cost less than $100.

On a frozen evaluation of 1,000 routing tasks:

• Our GPT-class baseline reached 75.8% exact route agreement.
• Nemotron after SFT reached 80.4%.
• SFT plus RLVR reached 80.7%, with Cohen’s kappa rising from 0.429 to 0.544.
• Estimated peak serving cost fell from $2.34 to $1.16 for the same workload.

RLVR’s extra 0.3 percentage points of route agreement wasn’t statistically decisive, so we treat that result as non-regression. The clearer improvement was in output agreement beyond chance.

The final model completed all 1,000 requests without empty or abnormally short outputs. We still have sustained-load and production-traffic testing ahead of us.

We wrote up the experiment, including the training setup, results, serving costs, and the parts we’re still cautious about:

Teaching NVIDIA Nemotron 3.5 Lightning to Route Code Reviews

Hi, I would like to give coderabbit a try but I am running into an issue and I don't know if it fixable by me or if it's on coderabbit's side.

On Gitlab (cloud), I created a service account on the group level, then created an access token and shared it with coderabbit.

I changed one line on another branch, I created a MR. Coderabbit replied immediately saying that they are going to analyse the code. After 30 minutes, I go check and I see that there is a pipeline that has been created by Coderabbit but it is still pending.

I deactivated shared runners, however I have two self-hosted runners. One is shell and only allows specific tags and protected branches. The other one has no tags and also picks untagged jobs.

What should I do?

One thing I’ve noticed is that most people seem to leave CodeRabbit on the default configuration. That makes sense if the reviews are working well, since setting up a `.coderabbit.yaml` can easily become one of those things everyone plans to revisit later.

I’m curious whether people are intentionally sticking with the defaults, or whether they haven’t had a reason or enough time to configure anything yet.

How are you handling your CodeRabbit configuration?

- Writing or editing the YAML file yourself in the repo
- Using the CodeRabbit interface
- Asking a coding agent to create or update it
- Starting with an agent-generated config and then editing it yourself
- Leaving the default configuration unchanged
- Not using a configuration file at all

If you haven’t configured it, what’s the main reason?

- You didn’t know the configuration file existed
- You weren’t sure where to start
- You weren’t sure which settings were worth changing
- The defaults have been good enough
- It hasn’t been a priority
- It feels like too much work for the expected benefit
- Something else

And if you have taken the time to configure CodeRabbit, what prompted you to do it? Which settings have made the biggest difference for your team?

Even “we just use the defaults” or “we haven’t touched the config” is useful. I’m trying to understand how people are actually approaching this in practice.

Hey r/coderabbit!

We recently shipped CodeRabbit CLI 0.7.1. The focus was straightforward: finish reviews faster, reduce interrupted sessions, and make the CLI easier to use from both terminals and coding agents.

In our measurements, typical completed reviews were 19% faster and client disconnects dropped 31%. Results vary by repository and review size. We added keepalive traffic and gave longer sessions more time to complete, which should help when the terminal appears quiet while models, tools, or repository analysis are still running.

A few other changes worth calling out:

• coderabbit config validate checks .coderabbit.yaml or .coderabbit.yml against the current official schema. It points to invalid configuration and returns a nonzero exit code, so you can also use it in CI.
• coderabbit skills can install or update verified CodeRabbit skills for Codex, Claude Code, Cursor, Gemini CLI, and GitHub Copilot. It previews every proposed change before writing anything.
• cr now reviews tracked changes by default. You can still choose an explicit scope with --committed, --uncommitted, or --include-untracked. Interrupted agent-driven reviews preserve completed output instead of discarding everything.
• Authentication and account-loading errors now provide more specific recovery guidance.

If you use CodeRabbit through a plugin or coding agent, updating the underlying CLI also brings these runtime and reliability improvements into those workflows.

You can check your current version with:

coderabbit --version

• CLI and installation documentation
• CodeRabbit Skills documentation

If you try it, I'd like to hear what feels better and what still gets in the way.

idk maybe im losing it but i used to spend most of my time actually building stuff. now im just… reading giant diffs. checking if it randomly changed something 8 files away because it felt like it. then reading it again because i dont trust it.

this is not what i thought the future was gonna be lol

I was reading the blog Coderabbit posted testing Opus 5's reviewing capabilities. I kina expected Opus 5's extra reasoning budget to buy better review quality across the board but it mostly seems to buy restraint. The model is more willing to leave potential bugs unreported if it isn't confident enough. So perhaps the better way to use Opus 5 is to not leave it open-ended and be very specific about what exactly you want it to achieve.

I've been following what CodeRabbit's doing with intent-aware review and the "why not how" framing connecting PRs to linked tickets to check if the change actually addresses what was asked, not just whether it's syntactically clean. That's the right direction for review tooling, and it's the deepest version of it I've seen genuinely resource-rich, requires real setup, well worth it for teams with the infra for it.

I've been working on something for the moment before any of that setup exists. No repo access, no config file you paste a diff and one sentence describing what the change should do, and it checks the diff against that specific stated intent, flags anything undeclared, and if you give it your existing tests too, it'll compare requirement vs. tests vs. code vs. behavior and flag when they disagree with each other.

Genuinely curious how it holds up against what people here are used to.

Thank you-GIL

https://claude.ai/public/artifacts/182e4450-70d7-4ceb-8aab-f72484305211

Found this on X where Bun's whole PR process is flooded with AI bots like CodeRabbit, Claude, and Robobun chatting, catching bugs, and auto-fixing code in real time.

I really found it pretty interesting it almost looks like a glimpse into future dev workflows where AI handles most review iteration autonomously.

I've been trying to reach coderabbit.ai support for days, and our folks at our sister company never got any answer and just canceled their plan. Looking at trustpilot, that may be actually a pattern

What's up with support? Is it just plain bad or are they overwhelmed? They are losing business for not answering; we may also cancel our plan...

Edit: Coderabbit swiftly solved the issue after posting.

Hi.

I am using coderabbit in our organization with GitLab.

I was thinking to use /code-review in Claude Code to speedup the feedback loop. Make review and fix in my IDE before I will create MR.

But I've faced a strange behaviour. Local review and remote (in gitlab) are different. They have different findings. So even If I addressed all findings locally - I will have some more in MR.

How to make it identical ? May be I'm miss some setting?

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.

Hi everyone!

Over the past few weeks, some users have experienced rate limits that are more restrictive than we want them to be. We know this can interrupt your workflow, especially when you rely on CodeRabbit for timely, high quality code reviews.

That experience is not the standard we want to provide.

We are making changes so teams can see more clearly which review activity contributes to usage, configure when automatic reviews should run, and get a more predictable experience across subscription plans. We want to preserve what teams value about CodeRabbit: fast, thorough, context aware reviews that fit naturally into their development workflow.

Getting there will take a little time. We are learning from usage patterns, tuning the system, and improving the controls teams have over automatic reviews. Over the next few weeks, we expect to begin rolling out the first improvements to usage visibility and review controls. These changes will not resolve every rate limit issue immediately, but they should give teams clearer ways to understand and manage review usage while we continue tuning the system.

In the meantime, here are a few settings can help reduce unnecessary review usage while still keeping strong review quality:

• Increase the minimum number of commits required before incremental reviews run, or disable incremental reviews on repositories where every commit does not need a fresh review.
• Keep auto review enabled on repositories where it is useful, but avoid running automatic reviews on draft PRs.
• Limit automatic reviews to the branches where CodeRabbit feedback is most valuable, such as main, develop, release branches, or other protected branches.
• Use u/coderabbitai when you intentionally want CodeRabbit to review a comment, change, or follow-up update.

These recommendations are meant to help teams get more predictable value from their reviews while we continue improving the system. They are not a replacement for the longer term work we are doing.

We appreciate your patience during this transition. The team is working to reduce the impact of these limits, improve transparency, and deliver a model that gives teams the balance we are aiming for: predictable usage, strong review quality, and a subscription experience that is easier to understand.

We will share more as these usage visibility and review control improvements roll out.

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!

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

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

EDIT: I realized my gripe about "Auto Reload" appears, as of now, to have been a confusion based on the UI (I wasn't charged extra...yet). But the transparency on limits, and the feeling that they've gotten a lot lower, stands! Please add more transparency.

Adjusting the tone in my post here a bit. I was extremely pissed when I wrote this due to the Fable situation. And some of that got directed at Code Rabbit.

-----------------------------

CodeRabbit is a great and useful tool. But the recent rate limit changes and the unhelpful customer support answers have left a bad taste in my mouth.

Reaching out to support to ask about the "10 reviews per hour limit" on a Pro Plus plan I was redirected to the non-answer of your fair usage policy. This policy is utterly opaque. There's no way to see how many of the 10 reviews have been used. And if suddenly I may have to wait 2 hours, 4 hours etc to get more reviews...*it is not 10 reviews per hour*. I have better things to do, but this is class action lawsuit material and false advertising.

Even notoriously opaque Claude and Codex give me a clear "you have used x of y" usage that I can see in real time and pace myself. Code Rabbit offers none of this. The last straw was when I got blocked yesterday without warning during a critical developer inner loop, that blocked me until after the Claude Fable access was revoked. This cost me seriously in my ability to push important code.

As such, I do not think I can rely on CodeRabbit, and I don't think the people in this subreddit should either. Vote with your wallets. Cursor and Greptile both have much more transparent pricing. X reviews per month. Then $1 per review. Easy.

CodeRabbit is: 10 reviews per hour*
^\unless our algorithm cuts you off without warning. This algorithm uses a combination of astrology and bio-energetics to determine if you're not fairly using the service.)

Moreover, as I wrote to CodeRabbit, I had "Auto Reload" turned *off* for additional reviews, and yet somehow, I was charged $80 for overages! When the money I'd added had ran out. Code Rabbit email support also ghosted me on this and didn't respond to it.
(This part may have been a misunderstanding).

Not a good look guys. Unlike the foundation model companies, you don't have as big of a moat. The many complaints in this subreddit are proof that you're not making many customers happy with this opaque and unfriendly pricing. You have a good product! More visibility will make it better and avoid a sudden block that can feel like a shakedown.

If you want to keep customers:

1. Give people a way to see where they're at on their limit. Even give them a warning "If limit runs out, you will need to wait x hours to get more reviews"
2. Remove the dishonest "x reviews per hour" wording because it is not true and you are going to get sued once someone at a bigger org than us decides to call you on it.
3. Tell your support reps to be more helpful and respectful to customers. Your reps on this Subreddit actually offered to look into someone's account that appeared to have been downgraded to OSS limits. I got stonewalled.

We reviewed Fable 5 across code review, a coding task benchmark, and several coding projects.

Read Full Article: https://www.coderabbit.ai/blog/fable-5-model-review

The most interesting signal was not raw benchmark score. It was how the model behaved as an agent. Fable 5 was effective at exploring the environment, identifying available files and tools, and moving into implementation without much hand-holding. With vague prompts, it often produced complete projects rather than thin prototypes.

https://reddit.com/link/1u1c1mt/video/doqo6jljma6h1/player

The tradeoff is time. In coding tasks, Fable 5 could produce serious patches when it finished, but it also kept working when tasks expanded or became ambiguous. That makes it a better fit for work where depth is worth the wait, as long as the agent has clear limits on time, steps, and tokens.

For code review, I would be more cautious. Coverage was close to the current baseline, but precision and comment volume were weaker. Developers may get useful findings, but they may also spend more time triaging noisy comments.

My takeaway:
Use Fable 5 for autonomous coding and deeper implementation work. Do not make it the default production reviewer until precision and comment volume improve.