Qodo, or code review that happens by itself

Qodo, or code review that happens by itself

Qodo automates two things developers dislike doing and that decide a project's quality over time: reviewing pull requests and writing tests. It works inside the repository and inside the editor, and alongside the product there is an open review engine you can run yourself.

The tool works in two places. In the repository it comments on pull requests, summarises changes, and flags problems at specific lines. In the editor it helps write code and generates tests, checking along the way whether a function does what its name promises.

The project ran under a different name earlier and changed it in late 2024. That change causes confusion when searching for material, since older posts and some links still use the former name.

The open core, the most interesting part

There is an open engine for reviewing pull requests, released under a permissive licence and run on your own infrastructure. Before counting savings on it, though, you need to understand what it is today, because its relationship to the product has changed.

The project was moved out from under the company and is now community maintained as a legacy solution, with the company appearing only as a sponsor. Its maintainers state plainly that this is not the free tier of the product but a separate project. The paid offering rests on a different, more feature rich engine, so comparing the two variants means comparing two different tools rather than two ways of deploying the same one.

The managed variant runs as an application connected to your repository, paid by plan. The open variant runs in a container with your own model keys, and you pay only for model usage.

The second is often noticeably cheaper, while upkeep falls to you: updates, handling repository events, and infrastructure. With two people on the team that work costs more than a subscription; with two hundred the proportion reverses.

Price both variants against your own traffic. A hundred pull requests a month is a different calculation from a thousand, and open source projects have a separate free access path available.

Choosing the model is yours too on the self hosted variant, and it is the model that drives the bill. It is set in the same configuration file, along with a fallback for when the primary one is unavailable.

[config]
model = "gpt-5.6"
fallback_models = ["gpt-5.6-terra"]
git_provider = "github"

This is where the largest cost difference between the variants sits. A stronger model raises accuracy on changes spanning many files and adds nothing but bill on small fixes, so dropping to a cheaper model for simple pull requests often beats any amount of rule tuning.

Self hosting also carries an argument that settles the matter for some companies regardless of cost: the code never leaves your infrastructure beyond the model call, and even that can be pointed at a locally run model.

Trying that variant needs nothing but a container and two keys, so the decision can rest on your own repository rather than on a description.

docker run --rm -it \
  -e OPENAI__KEY=$OPENAI_API_KEY \
  -e GITHUB__USER_TOKEN=$GITHUB_TOKEN \
  pragent/pr-agent:latest \
  --pr_url https://github.com/company/project/pull/128 review

Run it against a few already closed pull requests and compare its comments with what the human review actually caught. That is the only way to judge usefulness before rolling it out, and it costs about as much as a few model calls.

The trial and the billing model

There is no permanent free plan here, and that is the first thing to check, since older material describes a tier you will not find today. The vendor says so plainly in the questions beside its price list. Every workspace starts on a fourteen day trial with no card, unlimited reviews and unlimited credits, and once it ends reviews stop until you pick a paid plan.

Billing runs on credits drawn from one pool attached to the workspace rather than to a person, so headcount does not raise the bill directly. A credit costs 0.012 USD, and the packs line up like this: 2,500 credits for 30 USD a month, which the vendor estimates at roughly eighteen reviews, then 5,000 credits for about thirty six reviews and 20,000 credits for about a hundred and forty four. The Pro Team plan bills monthly with no annual commitment and is meant for teams of up to thirty people, above which the enterprise offering with a custom quote begins.

Two things in that model decide the bill and are easy to miss. First: unused credits expire at the end of each cycle, and each cycle starts fresh with a full pool, so a pack bought with a large margin is money thrown away. Second: once the pool runs out reviews do not halt, they move into overage charged at the same per credit rate with no penalty premium, against a monthly spending cap you set yourself. Only that cap stops reviews, and its size rather than the pack's decides the ceiling on the bill.

Separately there is a free programme for open source projects, which you apply to and must qualify for. That is the only path to permanent free access to the managed variant.

The self hosted variant bills differently and predictably: you pay for model calls. The cost of one review depends on the change's size and usually falls between a few and a few dozen cents, with large pull requests noticeably more expensive, since the whole context reaches the model.

From that follows a practical hint, useful regardless of tool. Small pull requests are cheaper to review automatically and better in human review, so splitting a large change into several smaller ones pays off twice.

Pull request review in practice

Once connected to a repository the tool reacts to new pull requests itself or on a command left in a comment.

/review
/describe
/improve
/ask does this change affect query performance?

The first command runs a review flagging problems at specific lines. The second generates a change description, often the most underrated feature, since a description written by the author usually reads "fixes" while one generated from the diff actually states what changed.

The third proposes concrete fixes as ready changes to accept. The fourth lets you ask a question about the change, a genuinely useful feature for a reviewer entering an unfamiliar part of the code.

Configuration describes what should happen automatically and what the tool should attend to.

[pr_reviewer]
require_security_review = true
num_max_findings = 3

[pr_code_suggestions]
num_code_suggestions_per_chunk = 3
max_number_of_calls = 3

[pr_description]
publish_labels = true

Volume is governed in two places, since the review and the fix proposals are separate commands with separate limits. The first key caps findings in a review, the next two cap suggestions, whose count in extended mode multiplies by the number of passes. Bring both down to the few most important items, because a review returning twenty comments on every pull request stops being read within a week, and that is the most common reason such a tool gets abandoned by a team.

The second reason is failing to establish whether comments are blocking. A tool commenting on a pull request without a clear rule about when you must act on it turns into noise everyone scrolls past. Picking one category, security for instance, as blocking and treating the rest as hints works better than pretending every comment carries equal weight.

Tests and the limits of this approach

The second half of the offering concerns tests, and here the matter deserves stating honestly.

The tool can generate test cases for a function, edge conditions included, the ones easily forgotten: an empty list, a negative value, a missing value, an out of range figure. That is real value, since those are precisely the cases that fall out of a human set.

The limitation is fundamental and follows from how such a tool works. A test generated from code checks that the code does what it does, not that it does what it should. If a discount function has a bug in its threshold, the generated test enshrines that bug as expected behaviour.

The practical conclusion is not "do not use it" but a statement of the right order. Write tests for business logic yourself, starting from requirements. Use generation to cover edge cases around already correct logic and for helper code, where expected behaviour follows directly from the implementation.

The same applies to pull request review. The tool catches missing error handling, absent validation, a query in a loop, and a typo in a condition well. It will not judge whether the thing should have been built at all or whether the solution fits the rest of the system, and those are questions a reviewer who knows the project answers.

Qodo against the alternatives

The first criterion is self hosting. If code cannot leave company infrastructure, an open core is an advantage the competition usually does not offer.

The second is context scope. A review based on the diff alone sees the change but does not see that the changed function is called in seven other places. Tools building a model of the whole repository handle that better, and that is sometimes decisive on a large project.

The third, the most practical: what you already have. If the team pays for a bundle including review, adding a second tool requires demonstrating the difference rather than merely asserting it is better.

Introducing it across a team

A tool commenting on somebody's work needs a more careful introduction than an ordinary dependency, since it touches how people work with each other.

Start with one repository and with a mode where review runs on request rather than automatically on every pull request. Over two weeks you will see how many comments land and how many are noise, and only then is it worth deciding about automation.

Establish clearly that the tool's comments are not orders. The pull request author decides what to accept and need not justify skipping a suggestion. Without that agreement automated review turns into a source of unnecessary disputes, and the team starts writing code for the tool rather than for readability.

Configure what the tool should not do as well. Formatting comments are pointless if you have automatic formatting, and naming style comments only make sense when the team has a written convention. Disabling categories you will not act on anyway raises the quality of the rest.

Measure one thing: how many comments got accepted. If after a month a few percent are accepted, the configuration needs narrowing or the tool does not suit this project. That is a simpler measure than any team survey and harder to game.

What such a review catches and what it does not

Breaking this into concrete categories pays off, since it determines what to expect from the tool and how to set a team's expectations.

It does well on local errors visible within one change. Missing handling of an empty value, an unchecked range, a condition inverted by a typo, a resource opened and never closed, an exception swallowed by an empty block. Those are things a human catches too, only less often, because they are reading their thirteenth review of the day.

It does reasonably on common performance traps, as long as they are visible in the changed fragment. A query inside a loop, loading a whole table into memory, a missing index on a column used for filtering in an added query.

It does poorly wherever knowledge of the system is required. It does not know the changed function has three other callers with different assumptions. It does not know the field you are removing is read by a job that runs once a month. It does not know this module is scheduled for deletion next quarter, making improvements to it a waste of time.

It does nothing at all on the questions that weigh most in a review: does this solve the right problem, does it fit the rest of the architecture, and could it be done more simply. Those are asked by somebody who knows the project, and no tool replaces that.

The honest conclusion runs like this: automation takes over the mechanical layer that consumed half a reviewer's attention, leaving that attention for things the automation will not touch. That is real value and something entirely different from a promise to replace review.

Common mistakes

The first is planning a rollout around a free plan the managed variant does not have. What exists is a fourteen day trial, after which a paid plan is required.

The second is buying a credit pack with a large margin. The unused part expires at the end of the cycle, and exceeding the pool costs the same per credit anyway, so the margin buys nothing but a larger invoice.

The third is generating tests for business logic. A test generated from code enshrines its bugs as expected behaviour.

The fourth is treating automated review as a substitute for human review. The tool will not judge whether a solution fits the rest of the system or whether it should have been built.

The fifth is submitting enormous pull requests. They cost more in automated review and fare worse in human review, so splitting pays off twice.

The sixth is self hosting without pricing the upkeep. On a small team that work costs more than a subscription.

FAQ

Is Qodo free?

The managed variant has no permanent free plan. You get a fourteen day trial with no card, then pay for credits starting at 30 USD a month for a 2,500 credit pack. Qualified open source projects get free access. The review engine is also available under a permissive licence for self hosting, where you pay only for model calls.

How does it differ from the former CodiumAI?

It is the same project after a rename carried out in late 2024. Older material and some links still use the former name, which misleads when searching for documentation.

Can generated tests be accepted without reading them?

No. A test generated from code checks that the code does what it does, not that it does what it should. Write tests for business logic yourself, starting from requirements, and use generation for edge cases around already correct logic.

Will it replace human review?

No, and that is not its purpose. It catches missing error handling, absent validation, and common performance traps well, while not judging whether a solution fits the system's architecture. It works best as a first pass ahead of human review.

Can I run it myself?

Yes, the open review engine runs in a container with your own model keys. Bear in mind that it is a community maintained project, separate from the paid offering, so it will not give you the same features as the managed variant. Price the upkeep too, since on a small team it can exceed a subscription, while on a large one the proportion reverses.

Documentation sits on the project site, and the open part's code in the GitHub repository.