DEV Community: Critique

AI code review pricing is getting weird in 2026

Critique — Tue, 02 Jun 2026 04:32:35 +0000

AI code review pricing used to be easy to compare.

How much per developer per month?

That question is not useless, but it is no longer enough. In 2026, the actual bill can depend on seats, pull request volume, model usage, review effort, private-repo runner minutes, and whether the tool runs a shallow diff pass or an agentic review with broader repository context.

The pricing page is only the start of the story.

The four pricing shapes to compare
If you are buying AI pull request review this year, you probably need to compare at least four models:

Per-developer seats
Usage-based review runs
AI credits or model usage
CI/runtime minutes for agentic review
Those are not just different billing labels. They reward different behavior.

Seat pricing is easy for finance. Usage pricing tracks workload better. AI credits expose the model bill. Runtime minutes show up when the review agent needs infrastructure, not just inference.

The trap is comparing only the headline price.

Seats are predictable, until usage is uneven
CodeRabbit is the cleanest example of familiar seat pricing.

As of this check, CodeRabbit documents Pro at $24 per developer per month when billed annually, or $30 month-to-month. Pro+ is listed at $48 per developer per month annually, or $60 month-to-month. Their docs also describe per-developer review limits and a usage-based add-on for eligible over-limit reviews.

That is straightforward to budget.

But it can still be awkward to right-size.

A 6-person platform team touching auth, billing, queues, migrations, and infra may create more review risk than a 20-person team mostly shipping small UI changes. Seat count does not tell you how many PRs need deep review.

The useful question is not:

How many developers do we have?

It is:

Which pull requests are expensive if the reviewer misses something?

Usage pricing matches work, but needs policy
Cursor's Bugbot is the clearest recent shift.

Cursor announced that Bugbot is moving from a $40 per-seat subscription to usage-based billing for Teams and Individual plans. They say the average Bugbot run costs about $1.00-$1.50, depending on PR size and complexity. They also connect usage billing to configurable effort levels, including deeper review settings.

That makes sense. A one-file typo PR should not cost the same as a complicated refactor.

But usage pricing needs guardrails.

Before turning it on everywhere, decide:

Which paths deserve deep review?
Who can trigger expensive reruns?
Should docs-only PRs get the same effort as auth changes?
What is the monthly review budget?
What counts as value: bugs found, risky merges blocked, or comment count?
Without policy, usage-based review can become a slot machine attached to every pull request.

GitHub Copilot adds another line item: runtime
GitHub Copilot code review adds a different wrinkle.

GitHub says Copilot code review is billed through AI Credits, and that private-repository reviews started consuming GitHub Actions minutes on June 1, 2026. GitHub's docs describe code review as having two cost components: AI credits for the model interaction, and Actions minutes for agentic capabilities like context gathering and tool use.

That does not mean Copilot code review is bad.

It means the bill can show up in more than one place.

If your org already tracks Actions spend closely, fine. If Actions minutes are treated as background CI noise, review usage may be harder to notice until later.

This is the new pattern: the cost of review is no longer only the model. It can also be the system around the model.

Model choice is becoming a budget control
This is the part most pricing pages still hide.

Not every PR needs the strongest available model. Not every finding needs a frontier model to inspect it. A practical review system should let teams spend differently based on risk.

For example:

Routine PRs can use cheaper review passes.
Auth, billing, infra, permissions, migrations, and public APIs can trigger deeper review.
Large or ambiguous diffs can escalate to stronger models.
Specialist agents can inspect security, tests, performance, or architecture without making every run maximum-cost.
Some teams may prefer bring-your-own-key so the model provider bills tokens directly.
This is how we think about pricing in Critique.

Critique's plans are built around shared review credits rather than per-developer seats. The current local pricing model is Solo at $19/mo with 750 credits, Pro at $49/mo with 3,000 credits, and Team at $149/mo with 10,000 credits plus frontier escalation lanes. The BYOK harness is $8/mo: Critique runs the orchestration layer, while OpenRouter or CrofAI bills model tokens separately.

The point is not "credits are magically cheaper."

The point is control. A team should be able to run broad, cheaper checks on everyday work and reserve expensive review for pull requests that can actually hurt production.

The buyer question changed
The old question was:

Which AI code review tool has the cheapest plan?

The better question is:

What is the cost per useful review on the pull requests that matter?

To answer that, model your own workload:

Monthly PR volume
Average changed files per PR
Sensitive paths: auth, billing, data, infra, dependencies
Private-repo CI/runtime cost
Expected reruns
False-positive tolerance
True positives that would actually block a bad merge
Then split PRs into tiers.

Example:

Low risk: docs, copy, simple UI
Medium risk: feature work, tests, internal APIs
High risk: auth, billing, permissions, migrations, infra, public APIs
Run the cheap path broadly. Escalate the risky path deliberately.

That one habit matters more than arguing over whether a seat, run, credit, or minute looks cheaper in isolation.

A practical checklist before buying
Before installing an AI review tool across every repo, ask:

Does pricing scale with seats, PRs, models, minutes, or all of the above?
Can we set review effort by path, branch, or risk tier?
Can maintainers control expensive reruns?
Can we start advisory-only before requiring the check?
Can we see what each review cost?
Are private-repo runtime minutes part of the bill?
Are model costs hidden, bundled, or directly billed through our own key?
If the vendor cannot explain this clearly, the pricing is not simple. It is just under-described.

Where a calculator helps
I do not think teams should pick AI review tooling from a pricing table alone.

Take one busy repository. Count a normal month of PRs. Split the PRs into low, medium, and high risk. Then estimate what each pricing model does to that workload.

That is why we made a small PR review cost calculator:

https://www.critique.sh/tools/pr-review-cost-calculator

Use it as a sanity check before turning any AI reviewer into a required gate.

A security checklist for AI-generated pull requests

Critique — Tue, 02 Jun 2026 04:31:12 +0000

AI-generated code is not automatically insecure.

The problem is that it can create convincing pull requests faster than teams can inspect them. The diff may be formatted well, the helper names may look reasonable, and the tests may be green. None of that proves the change preserved the security rules your app depends on.

When I review AI-generated PRs, I use a short checklist. It is close to the way we wrote Critique's [critique-review](https://www.critique.sh/skills/critique-review) skill: establish scope, map blast radius, trace risky paths, check authorization, and only report findings that are grounded in the actual code.

No vague "this might be risky" comments. If there is a security concern, it should point to a real path and a real failure mode.

1. Start with blast radius

Before reading every line, mark the parts of the system the PR touches.

Pay extra attention to changes involving:

Auth
Billing
Permissions
Data export or import
Migrations
Webhooks
Background jobs
Infrastructure
Public APIs
AI agents, tool calls, or model output

Not every AI-generated diff deserves the same review depth. A copy tweak does not need the same pass as a webhook handler. A CSS fix is not token validation. A UI-only change is not the same as a database migration.

The first question is simple:

What is the worst thing this PR can affect if it is wrong?

That answer decides how hard you review.

2. Trace untrusted input

Find anything that enters the system from outside:

Request bodies
Headers
Uploaded files
Webhook payloads
User-generated content
Retrieved documents
Model outputs
Agent instructions

Then follow where that data can go:

Database writes
Logs
Commands
Prompts
Tool calls
External APIs
Credentials

AI-generated code is often good at the happy path. It parses the payload, calls the helper, returns the response, and adds a test for the expected case.

Security review is mostly about the other cases.

What if the webhook payload is replayed? What if the uploaded file is bigger than expected? What if the retrieved document contains instructions for the model? What if a user passes another user's ID?

Write the path down if needed:

external input -> validation -> permission check -> side effect

If one of those steps is missing, that is where the review should slow down.

3. Check authorization, not just authentication

This is the mistake I see most often in generated code.

The PR checks that a user is logged in, but does not check whether that user can access the specific object.

Authentication asks:

Who are you?

Authorization asks:

Are you allowed to do this specific thing?

Ask:

Can user A access user B's object?
Can one tenant read another tenant's data?
Can a non-admin reach an admin-only path?
Did the change bypass an existing owner check?
Does the API enforce the same rule as the UI?

This is not enough:

if (!session.user) {
  throw new Error("Unauthorized")
}

You still need the object-level check:

const project = await getProject(projectId)

if (project.ownerId !== session.user.id) {
  throw new Error("Forbidden")
}

In a real multi-tenant app, even that may be too simple. You might need organization membership, role checks, feature policy, or plan limits.

The point is not the exact code. The point is that "logged in" is rarely the whole rule.

4. Treat model output as untrusted

If an LLM can influence a privileged action, its output is untrusted input.

That includes output used for:

Tool calls
File writes
Shell commands
API requests
Database updates
Workflow routing
Prompt construction

Prompt injection is not only a chatbot problem. It is a tool authorization problem.

The risky pattern looks like this:

model reads untrusted content -> model decides action -> app executes action

The fix is not just "use a better prompt." Prompts help, but they are not a security boundary.

Use boring controls:

Allowlist tools
Validate tool arguments outside the model
Scope credentials tightly
Require confirmation for sensitive writes
Keep read tools separate from write tools
Log tool calls
Fail closed when the request is unclear

If a PR adds agent behavior, review it like a new public API. Ask what it can read, what it can write, and what happens when the input is hostile.

5. Validate the fix

For security-sensitive changes, do not accept "looks patched."

Ask for one of:

A regression test
A reproducer
A before/after exploit path
A clear invariant the code now enforces

Good validation sounds like this:

Before: User A could request User B's invoice by ID.
After: The API checks organization membership before loading invoice details.
Test: A user from org_1 gets a 403 when requesting an invoice from org_2.

That is much better than:

Fixed auth bug.

The same rule applies to tests. A generated PR may include tests, but check what they prove. Happy-path coverage is useful. Boundary coverage is what catches the security bug.

Look for negative tests:

Logged-out user cannot access the endpoint
Normal user cannot access admin action
Tenant A cannot update Tenant B's settings
Invalid webhook signature is rejected
Replayed webhook event does not double-apply
Model output cannot call a disallowed tool

If the PR changes authorization and only tests the allowed case, the test suite is still missing the important part.

6. Keep review comments specific

The least useful security review is a wall of generic warnings.

Bad:

Make sure permissions are correct.

Better:

This endpoint checks that a session exists, but it does not verify that the requested invoice belongs to the caller's organization. A user who can obtain another invoice ID may be able to read it. Load the invoice through an organization-scoped query or compare the invoice organization against the caller's memberships before returning it.

That gives the author something to fix.

This is the part of Critique's critique-review skill I like most. It pushes the reviewer to separate findings from guesses. A real finding needs a code path, an impact, and a fix direction. If the evidence is incomplete, call it an open question instead of pretending it is a confirmed bug.

AI-generated code does not need a totally different review process.

It needs a stricter one.

Use the same standards you would use for human-written production code:

find the blast radius
trace untrusted input
check object-level authorization
treat model output as untrusted
require evidence for security fixes
keep findings grounded in code

The goal is not to block AI-generated PRs. The goal is to make them prove the same thing every production change should prove: the right users can do the right things, and the wrong users cannot.

If you want the review posture in reusable form, the public [critique-review](https://www.critique.sh/skills/critique-review) skill is built around that idea: fewer generic comments, more grounded findings.