Kodus AI: Self-Hostable Code Review With Your Own Model Keys
AI Code Review with Full Control Over Model Choice and Costs.
At a glance
- What is it?
- Kodus is a TypeScript code review platform that runs against pull requests on GitHub, GitLab, Bitbucket and Azure Repos, or from a CLI. Its proposition is model choice and direct provider billing, not a hosted-only SaaS. The interesting question is what you take on when you self-host it.
- Who is it for?
- Adopt Kodus if you already pay a model provider directly and want review rules expressed in plain language across repositories, or if you want `kodus review --staged` in a pipeline without a hosted reviewer. Do not adopt it if you need a permissively licensed drop-in: the README badge says AGPLv3 while the repository metadata says NOASSERTION, and that gap is the first thing to resolve with your own legal reading of license.md.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Kodus Targets: Review Cost and Model Lock-In
Most AI review tools sell you a subscription that bundles model access. You cannot see the multiplier between the provider's token price and what you are charged, and you cannot switch models when a cheaper or better one appears. Kodus takes the opposite position. The README's first two selling points are model agnosticism and zero markup on LLM costs: you connect your own provider credentials and pay the provider directly. The supported list named in the README is OpenAI, Anthropic, Google Gemini, Vertex AI, Novita, plus any OpenAI-compatible endpoint. That last clause matters more than the named providers, because it is the escape hatch for self-hosted models or a gateway in front of several vendors.
The second problem is review consistency. Teams repeat the same comments on pull requests: do not log this, validate that tenant ID, add a test for this branch. Kody Rules exist to move that repetition out of human reviewers. Rules are written in plain language and scoped to an organization, a repository, a path, or a specific review scope. The audience is therefore a platform or DevEx team that already runs its own infrastructure and wants review policy to be configuration rather than tribal knowledge.
How Kody Rules and Review Scope Fit Together
The mechanism described in the README is context injection rather than fine-tuning. Kody Rules are stored as review instructions, and when a pull request is reviewed, Kody uses those rules as context. There is no claim that a model is trained on your code; the README explicitly states source code is not used to train models. So the rule set is prompt-side configuration, and the quality of a review depends on how precisely those rules are written and scoped.
Scoping is the part worth studying before you write rules. A rule attached to an entire organization applies everywhere, which is convenient until it fires on a repository where it does not belong. Path-scoped rules are the finer instrument: a rule about database migrations can be attached to the migration directory rather than to every file. The README does not publish the rule syntax, so the exact matching semantics (glob versus prefix, whether nested paths inherit) have to be read from the docs rather than assumed. The worked example in the README shows Kody flagging an IDOR risk where an `organizationId` query parameter could bypass tenant protection when passed as an array, and suggesting explicit runtime validation. That is a pattern-level catch, not a style nit, and it is the kind of finding a path-scoped or security-scoped rule is meant to make repeatable.
Running a Review From the Terminal
The CLI is the lowest-commitment entry point and the one with the most concrete commands in the README. Three forms are given: `kodus review` against a working tree, `kodus review --staged` against the staged diff, and `kodus review --prompt-only`. The README also says reviews can target a branch or a commit, and links a command reference at docs.kodus.io/how_to_use/en/cli/commands for the full flag set. `--prompt-only` is the interesting one for teams that want the review text without Kody posting anything, though the README does not spell out the output format, so treat that as something to confirm by running it.
For pipelines, the README points to docs.kodus.io/how_to_use/en/cli/ci_cd. The natural shape is `kodus review --staged` in a job that has already checked out the diff, but the CI page is where the exit-code behaviour and any required token configuration would live. Nothing in the supplied material describes authentication for the CLI, so do not assume it runs unauthenticated against a self-hosted instance. The git-host integrations are separate from the CLI: the README lists GitHub, GitLab, Bitbucket and Azure Repos as native PR integrations, which is the path where Kody comments directly on the pull request.
Self-Hosting, Telemetry and the AGPLv3 Question
Self-hosting is a first-class option here, not an afterthought. The README links a generic VM deployment guide and describes self-hosted runners as supported. It also discloses one behaviour that deserves attention before you deploy: a self-hosted instance sends one anonymous heartbeat per day, described as aggregated counters only, with no code, names or identifiers. The opt-out is a single environment variable, `KODUS_TELEMETRY_DISABLED=true`. Set it during provisioning rather than after, because the first heartbeat otherwise leaves before anyone remembers.
The licence situation is the sharpest edge in the repository. The README badge says AGPLv3 and links to license.md, while the repository metadata reports NOASSERTION, meaning GitHub could not map the licence file to a known identifier. Those two signals are not contradictory in a technical sense, but they are contradictory enough that you should read license.md yourself. AGPLv3 carries network-copyleft obligations: if you modify Kodus and expose it to users over a network, the licence family generally expects you to offer the corresponding source. That is a materially different posture from a permissive licence, and it matters most for anyone planning to embed Kodus inside a commercial product. This is not legal advice; it is a reason to route license.md past whoever handles licensing at your company before the first production deploy.
Where Kodus Is the Wrong Tool
The clearest mismatch is a team that wants a permissive licence and no operational surface. Kodus is offered as a cloud product, so you can avoid the infrastructure entirely, but the self-hosted path is the one with the control story. If you self-host, you own the deployment, the provider credentials, the rule set, and the upgrade cadence.
A second mismatch is expecting the tool to replace reviewers. The README frames Kody as flagging risks by severity and suggesting fixes, and Kody Issues as tracking unimplemented suggestions from closed pull requests so they can be resolved when a fix appears in a future PR. That is an assistive loop, not an approval gate. A team that wants a hard merge block still has to build that from the review signal.
The third is cost predictability without measurement. The zero-markup claim means you pay the provider directly, which also means token spend is yours to watch. The README offers a token usage view and a Cockpit for review effectiveness and delivery metrics, but the supplied material gives no figures, no rate limits, and no guidance on what a large monorepo review costs. If your budget needs a number before you commit, you will have to produce that number yourself.
Alternatives and the Actual Difference in Approach
The obvious comparison is the hosted AI reviewer category, where the vendor supplies both the model and the review logic. The difference is not quality, since the supplied material contains no benchmark. The difference is where the model relationship lives. A hosted reviewer bundles model access into the subscription; Kodus expects you to bring credentials for OpenAI, Anthropic, Gemini, Vertex AI, Novita, or an OpenAI-compatible endpoint and to hold the provider account yourself. If your organization has already negotiated provider rates or runs an internal gateway, that is a real advantage. If you have no provider account and no desire to manage one, the bundled model of a hosted reviewer is less work.
The second comparison is running your own review prompts against a general-purpose agent. The difference is persistence and scope. A one-off prompt is not a rule set. Kody Rules are stored, scoped to organizations, repositories, paths or review scopes, and applied automatically when a pull request is reviewed. That is the part a script cannot easily reproduce, and it is the reason the tool exists as a platform rather than a wrapper. The trade-off is that stored rules need maintenance: a rule that no longer matches the codebase will produce noise, and the README's Cockpit includes Kody Rule health as a metric, which implies rules are expected to decay.
Maintenance, Releases and What to Verify First
The release cadence visible in the supplied material is tight: 2.2.1 on 2026-09-04, then 2.2.2 and web-1.2.2 on 2026-09-08, with the last push to main on 2026-09-10. Two patch releases four days apart, plus a separately versioned web component, tells you the project ships often and that the web surface versions independently of the core. For a self-hosted deployment that means planning upgrades rather than treating the install as static, and reading release notes before each jump because patch releases at that frequency can carry behaviour changes.
The versioning split is also a deployment detail: if you pin one version, pin both, or you may run a core and a web layer that were not tested together. The README does not describe a migration procedure for the database or configuration between versions, so the upgrade path is something to confirm from the self-host guide rather than infer.
Before adopting, verify in this order. First, read license.md and reconcile it with the AGPLv3 badge. Second, confirm your chosen provider works, specifically whether it is one of the named providers or whether you are relying on the OpenAI-compatible endpoint path. Third, run `kodus review --staged` on a repository you know well and judge the findings yourself, since no accuracy data is published. Fourth, set `KODUS_TELEMETRY_DISABLED=true` if the daily heartbeat is not acceptable. Fifth, write one path-scoped Kody Rule and watch whether it fires where you intended.
Editorial conclusion
Adopt Kodus if you already pay a model provider directly and want review rules expressed in plain language across repositories, or if you want `kodus review --staged` in a pipeline without a hosted reviewer. Do not adopt it if you need a permissively licensed drop-in: the README badge says AGPLv3 while the repository metadata says NOASSERTION, and that gap is the first thing to resolve with your own legal reading of license.md. Verify two things before rollout: that your chosen provider works through the OpenAI-compatible endpoint path, and that `KODUS_TELEMETRY_DISABLED=true` is set on every self-hosted instance if the daily heartbeat is not acceptable. The deployment guide at docs.kodus.io/how_to_deploy is the only supported path the README points to.
Community notes