How I set up PR reviews for vibe coding with Kody and OpenRouter

I had paid more than $700 for CodeRabbit, and I was still running into review limits that, in my workflow, felt like roughly two reviews an hour.

That is my experience, not a claim about every CodeRabbit plan or an apples-to-apples cost benchmark. But when I am building with AI coding agents and pushing changes repeatedly, waiting for another review slot breaks the flow.

My current alternative is Kody, the open-source code review agent from Kodus, connected to OpenRouter. It has been a much better fit for how I work.

The useful part is the control: I can choose the models, bring my own keys, and decide how the review system continues when a model cannot serve a request.

What I am paying for

Kodus currently lists its Teams BYOK plan at $10 per developer per month, plus model usage. BYOK means “bring your own key”: the review platform and the model bill are separate. Kodus also has a free Community plan with unlimited PRs using your own key and limits on some platform features. Kodus pricing

That distinction matters. This is not a promise that $10 buys unlimited inference. It buys the platform seat on the monthly Teams plan; credits, tokens, provider capacity and model limits still matter.

For me, that separation is a big part of the appeal. I can use model access I already have instead of tying the whole review workflow to one bundled allowance.

My credits-first approach

My approach is to use the Claude and OpenAI API credits I already have when available, with free models on OpenRouter as a way to keep the workflow moving when those credits run out.

Those are credits available to my accounts. I am not saying that a Claude or Codex subscription automatically includes interchangeable API credits, or that connecting Kody creates a new free allowance.

There are two places to think about “bring your own key.” Kody can use an OpenRouter key as its provider connection. Separately, OpenRouter can use your own upstream provider keys. Those upstream keys are what let eligible requests use a provider account's credits; simply choosing a Claude or OpenAI model in OpenRouter does not transfer credits between accounts. OpenRouter BYOK documentation

The result has worked really well for my development flow. But the cost strategy and the exact routing visible in a dashboard are different things, so here is what my setup actually shows today.

The settings in my current setup

The screenshots below are from my Kody workspace on November 12, 2026.

1. Connect OpenRouter in AI providers

In Kody, I use AI providers → Providers to manage the connection and the models available to the workspace.

My account has OpenRouter connected and a mix of Claude, OpenAI and other models registered. The screenshot shows model availability, not proof that every listed model has handled a review or has credits remaining.

2. Make the routing explicit

Under AI providers → Routing, Kody lets me choose a default model, a fallback and task-specific overrides.

My current screen shows Free as the default and Auto as the fallback. Balanced and Heavy code review inherit Free; several other tasks use Auto.

I want to be precise about that: this screenshot does not show a Claude-first or OpenAI-first chain. It shows the current configuration. Auto is a separate selection, and I would not tell someone to assume it is free.

Kody's fallback control says it can rerun a failed call once on the chosen fallback after the primary's own retries, including failures caused by no credit, a rejected key or provider downtime. That is a model-call retry, not a guarantee that an entire review will always finish.

OpenRouter also has its own model fallback mechanism: an ordered list of models to try when a request fails. Its documentation makes the billing consequence clear: if the successful fallback is paid, you pay for that model. A free-only fallback list must contain only free models. OpenRouter model fallbacks

3. Review every push, with automatic approval off

In Code Review → General, my current settings have:

• Automated reviews enabled, with a review on every new push.
• Reviews on draft pull requests enabled.
• Balanced review mode selected.
• Automatic PR approval turned off.
• Request changes on critical issues enabled.

That is the part of the setup I would keep even if I changed model providers tomorrow. I want review feedback to arrive as the code changes, while keeping the merge decision separate from the bot's output.

Kody also exposes a manual review command: comment @kody start-review on the pull request when you want to request a review.

What the screenshots also show

There is an OpenRouter key rejection warning at the top of these screens. I have left it visible because it is part of the actual setup at the time of writing.

That warning matters: switching models behind the same rejected provider connection may not restore access. A fallback is useful when the next route can serve the request; it cannot make an invalid shared credential work.

Free models also have their own request limits and availability constraints. A PR review can involve multiple model calls, so a request allowance is not the same as a number of completed reviews. OpenRouter limits

This is why I think of the setup as flexible and economical, rather than an unlimited free service. My experience has been good, and I still need to pay attention to whether reviews actually complete.

Why it fits my vibe coding workflow

The value for me is being able to change the model layer without replacing the whole review system.

I can choose where to use the model access I already have, keep free options available, and adjust the setup as credits or model availability change. Compared with the review bottleneck I experienced before, that flexibility has made a real difference.

I am not claiming that a free model catches the same bugs as every paid model. I am saying this setup fits my workflow much better, and I like being able to see and control the trade-offs.

I am building the rest in public

I am also working on an open-source repository with the skills and core setup needed to start a scalable software system using vibe coding. PR review is one piece of that larger system.

I want the repo to be practical: something people can use, inspect and improve, with the setup decisions explained alongside it.

If you have a review skill, a better routing approach, a model that has worked well on real PRs, or a failure case worth testing, leave a recommendation. I am happy to include useful suggestions in follow-up posts as I build this out.