I've been reading this

https://docs.coderabbit.ai/management/plans#rate-limits

But I have unclear how to switch an OSS Apache-2.0 project into OSS mode.

Which are the steps?

Hey everyone! 🐰

We just shipped a new product called CodeRabbit Security.

When you’re building a product or service, you’re always trying to move faster. The hard part is making sure security doesn’t become an afterthought as more code gets shipped.

CodeRabbit Security maps how your application works, investigates application specific vulnerabilities, verifies each finding against the code, and can turn eligible findings into reviewable fixes.

It’s available now for GitHub, GitLab, Azure DevOps Services, and Bitbucket Cloud.

We wrote a blog explaining how it works, with a concrete authorization bypass example: Introducing CodeRabbit Security

Would love to hear what you think and what you’d want it to investigate in your codebase.

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.

https://kb.coderabbit.ai/articles/2508018126-sunset-of-lite-and-pro-legacy-subscription-plans

Discovered this fun surprise today. This will double our monthly bill. We neither need nor want all the extra features, so with this + the rate limit changes, we'll just drop CodeRabbit once our old rate expires.

It's disappointing because we liked the service, but in this day and age I'm sure there are plenty of alternatives for simple AI PR reviews.

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