Kodus

A one-sentence summary

Kodus is an open-source AI code review platform designed for software development teams; its first agent, Kody, can analyze code changes in pull requests, provide additional context, and offer actionable suggestions.

Tool Introduction

Kody integrates automated code review into a team’s existing Git workflow, with a focus on identifying potential defects, security risks, performance issues, code quality problems, and deviations from team standards. It can be used in hosted environments as well as deployed on one’s own infrastructure.

The platform is not tied to a single model; by default, it operates in the BYOK mode. Teams can choose from OpenAI, Anthropic, Google Gemini, Vertex AI, Novita, or compatible endpoints, and pay the model providers directly for inference services.

Main functions

Automated PR review

Kody can run automatically after a new submission is created or pushed in a PR, or it can be triggered manually using a comment command. It analyzes the applicable configurations, collects the differences and relevant context, and then generates inline suggestions as well as an optional PR summary.

Identification of defects and security issues

The review process focuses on logical errors, input validation, access control, exception handling, security risks, performance, and maintainability. It is recommended to filter comments based on their severity and relevance, as well as to remove duplicates in order to eliminate repeated or low-value comments.

Checks across files and business logic

Kody can take into account the context of the warehouse as well as information across different files in order to analyze changes, and it goes beyond merely explaining individual sections of differences. Business logic validation also allows for a comparison between the actual implementation and the task descriptions or specifications, but this functionality relies on proper configuration and accessible context.

Kody Rules

The team can create review rules using natural language, and apply them by organization, repository, directory, or specific scope. These rules are useful for establishing architectural constraints, security requirements, testing standards, and repository conventions.

Team memory and learning

Memories treats the structure of the code repository, established conventions, and team feedback as high-priority context elements that are used in subsequent reviews, cross-file analysis, and discussions. The scope of these memories can be set at the directory, repository, or organization level, and the memories generated by AI can go through an approval process.

Kody Issues

When a PR is closed, the unimplemented file-level suggestions are automatically added to the issue list, with the file location, severity level, and original suggestion context retained. Once the corresponding changes are made in the PR, the platform can automatically match these suggestions and mark the issues as resolved.

Cockpit engineering metrics

Cockpit is used to monitor the effectiveness of reviews, the health of rules, warehouse quality, and delivery metrics; it is suitable for project managers to keep track of how things are working. This module is part of the Teams and Enterprise packages and is not included in Community.

Plugins and MCP

The plugin uses MCP to incorporate external business contexts such as Jira into the review process; it also allows for the management of rules or the creation of issues within comment threads. Currently, this plugin is marked as a testing feature, and it should not be used for any critical production tasks without first being verified.

Terminal CLI

Kodu CLI allows for direct inspection of workspaces, staged differences, branches, or commits, and it generates structured reports based on the severity of issues. It supports previewing and applying fixes, installing pre-push hooks, integrating with CI processes, and providing concise output for coding agents.

Code review process

1. Connect to the Git code hosting platform and select the organization, workspace, and repository for which you want to enable Kody.
2. Configure automatic or manual review, target branch, ignored paths, suggested severity levels, and file limits.
3. Connect your model key, select the model, and set a monthly limit for model expenses.
4. Create Kody Rules and memories applicable to teams, repositories, or directories.
5. After a developer creates a PR or pushes a new submission, Kody collects the differences and relevant context.
6. Platform execution rules, cross-file analysis, suggestion filtering, and deduplication.
7. Kody provides specific suggestions next to the code lines and generates a PR summary based on the configuration.
8. The developer decides whether the suggestion is correct, modifies the code, or continues the discussion in the comments.
9. When a re-analysis is needed, manual review is triggered to confirm whether the new submission resolves the issue.
10. Observe performance, pending recommendations, and team trends through Cockpit and Kody Issues.

Automatic trigger, manual trigger, and skip

GitHub, GitLab, and Forgejo allow the use of native emoji reactions to indicate states such as processing, completed, skipped, no license available, or error. Azure DevOps and Bitbucket lack corresponding reaction interfaces, so some of these states are represented by comments instead.

Kody Rules and memory

Rules and memories can reduce the need for repeated explanations, but errors resulting from these rules will continue to increase. A responsible person should be assigned to each rule, and false positives, false negatives, as well as the scope of application of each rule should be evaluated through actual PR tests.

Kody Issues and quality tracking

• When PR is closed, document-level recommendations that have not yet been implemented are recorded.
• Save the warehouse, file location, category, and original recommendation context.
• Manage severity levels as Critical, High, Medium, and Low.
• Use Open, Resolved, and Dismissed to maintain the processing status.
• Filter by status, severity, category, and warehouse.
• Save frequently used views for the team to review regularly.
• Automatically attempt to resolve it when implementing suggestions for subsequent code changes.
• PR-level rules do not directly generate trackable issues.

Plugins and business context

MCP includes built-in adapters for GitHub, GitLab, Bitbucket, and Azure DevOps, so there is no need to install separate plugins for basic code operations. External plugins can retrieve Jira tasks or specifications, enabling suggestions that are more in line with the business acceptance criteria.

• Enable only the tools that are truly necessary for the current workspace.
• Set minimum-privilege credentials for external endpoints.
• Verify that the task link grants Kody read permissions.
• Manual confirmation is required for write operations such as updating task status.
• Review the logging, retention, and security policies of custom MCP servers.
• Re-validate the behavior after the test function has been upgraded.
• Do not assume that external specification content is reliable instructions by default.

Supported code platforms

Models and BYOK

By default, all packages allow users to connect to their own model accounts; the costs associated with those models are settled directly with the respective providers, and Kodus does not charge any additional fee for the tokens. Users can choose between a commercial model, a cloud-based enterprise gateway, aggregated services, or compatible interfaces.

The BYOK task will not silently switch to the Kodus-hosted model when no fallback model has been configured by the user. If the selected model fails, the review will also fail; therefore, the team should establish its own fallback, budgeting, and alerting strategies.

Managed version and self-hosted

Self-hosted architecture

The self-hosted version consists of a web application, APIs, review Workers, Webhook services, an MCP manager, as well as queue and database components. Docker Compose can be used for deployment, and there are also deployment materials available for Kubernetes and OpenShift.

• Set up a stable entry point and signature verification for Webhooks.
• Isolate network permissions for web pages, APIs, Workers, and data services.
• Store Git credentials and model keys in a key management system.
• Create backups for PostgreSQL, MongoDB, and message queues.
• Limit the scope of MCP manager access to external systems.
• Deploy reverse proxies, transport encryption, and access control.
• Monitor task queues, failure reviews, Token usage, and storage growth.
• Verify database migration and rollback before upgrading.

Self-hosted implementation steps

1. Evaluate the differences between Cloud and self-hosted solutions in terms of data boundaries, operations, and support.
2. Prepare an environment that meets the requirements for containers, databases, queues, domain names, and data transmission encryption.
3. Deploy the Kodus application components and set up separate production keys.
4. Configure Git platform applications, OAuth, Webhooks, or access tokens.
5. Connect to model providers and set a budget limit for each environment.
6. Create organizations, workspaces, repositories, roles, and review rules.
7. Use the test repository to verify PR triggering, comments, retries, and status feedback.
8. Test backup restoration, upgrades, log masking, and credential rotation.
9. Connect to the production warehouse only after completing the security and legal audits.
10. Continuously update versions and monitor queues, delays, false positives, and model costs.

How to use CLI

CLI is suitable for checking local changes before creating a PR, and it also allows integration into the automatic repair processes of CI or coding agents. Anonymous users can review files 5 times per day, with a maximum of 10 files per review; after logging in, the limits are determined by the subscription plan, with a maximum of 100 files per review.

1. Install Kodus CLI and open a terminal in the target repository.
2. First, run a regular review on the workspace or the temporary differences.
3. View issues grouped by file and severity.
4. Preview each suggestion individually; do not accept all automatic fixes at once.
5. Use repair mode when needed to address solvable issues.
6. Structured prompt output patterns are used to encode AI agents.
7. In CI, blocking conditions are set based on severity and exit codes.
8. Keep the team rules in line with the Web configuration.

Prices and packages

The price information was verified on August 23, 2026; the actual amounts, taxes, exchange rates, and discounts may vary, and the final figures will be those displayed on the settlement page.

Kodus classifies its packages based on product features rather than the number of PRs; all packages offer unlimited PR reviews and an unlimited number of users, with its own model keys being used for this purpose. Teams determines the number of seats available based on the number of active developers who create PRs in a given month, and no minimum number of seats is specified publicly.

By default, in Community, Teams, and Enterprise versions, it is the users who are responsible for covering the costs related to model tokens; the actual cost depends on the scale of the PR, the context, the model used, and the frequency of reviews. In the Enterprise version, it is also possible to use keys managed by Kodus under the terms of a contract.

Free trial

Teams offers a 14-day trial period without the need for a credit card. The trial includes team features such as Cockpit, unlimited rules and plugins, as well as priority queues; moreover, Kodus covers the costs associated with the first 5 PR reviews.

• The Teams feature is restricted for 14 days; basic moderation is not permanently disabled.
• For the first 5 PR reviews, there is no need to connect the model key in advance.
• Completing some guided tasks may earn additional trial review credits.
• Once the free review quota is used up, you can continue by connecting your own model key.
• The trial model is selected by Kodus; once one’s own keys are in place, it is possible to choose a model of one’s own.
• The annual Teams plan is 20% cheaper compared to the monthly public rate.
• Cancellation takes effect at the end of the current billing cycle.
• Fees already paid are generally non-refundable, unless otherwise explicitly agreed.

Open source and licenses

The Kodus core repository is made public and continuously maintained, but it uses a dual licensing model. The code, excluding the files and directories marked as being part of the enterprise version, is licensed under AGPL-3.0; the parts marked as part of the enterprise version are subject to commercial licenses. Therefore, it cannot be assumed that all functions can be used under the AGPL license.

Corporate plans, commercial licenses, and open-source repositories can coexist. Organizations that intend to distribute modified versions, provide network services, or incorporate these technologies into commercial products should have their legal teams examine the terms of the AGPL as well as the boundaries of corporate licenses.

Privacy and data processing

Customers retain ownership of their data, including code, repository metadata, PRs, comments, and configurations, and grant Kodus permission to process this data for the purpose of providing review services. The platform will not use customers’ code or personal data to train or fine-tune the underlying models, unless the customers explicitly allow it.

During the review process, only the differences and the necessary context are sent to the selected model provider; Kodus stores the results of the review, including suggestions and metadata, for historical reference, to avoid repetition, and to calculate relevant metrics. BYOK users are also subject to the data terms agreed upon between them and the model provider.

Self-hosted telemetry

By default, self-managed instances send an anonymous heartbeat once a day, containing aggregated counts and operational metadata; no code, identity information, or data that can be used to identify users is included. Administrators can preview the content sent, and they can also disable telemetry through environment settings.

• Check the telemetry fields of the current version before going live.
• Record the decisions to enable or disable in a regulated environment.
• Restrict telemetry exports to specified services.
• Check for field changes again after upgrading.
• Do not confuse anonymous heartbeat data with application logs or model traffic.
• Disabling telemetry does not replace the need to monitor traffic related to Git, models, and plugins.

Which users are it suitable for

• R&D teams that hope to automatically detect defects and security risks in PRs.
• Platform teams that need to enforce consistent coding standards and architectural constraints.
• Organizations that use GitHub, GitLab, Bitbucket, or Azure Repos.
• Teams that wish to choose their own models and have direct control over the Token costs.
• Companies that need a self-hosted open-source code review platform.
• Project managers who fail to track the implementation of recommendations and technical quality trends are needed.
• Developers who need to review the code locally, before deployment, or in CI.
• Users who wish to involve Claude Code, Cursor, Codex, or Windsurf in the review and correction process.
• Product development teams that need to incorporate Jira specifications into code reviews.

Typical scenarios

• Automatically check for security, performance, and logical issues after the PR is created.
• Technical specifications for different modules are constrained through directory-level rules.
• Verify that the implementation meets the task acceptance criteria before merging.
• Provide continuous and consistent initial reviews for open-source repositories.
• Obvious defects are identified before local submission, and fixes are previewed.
• In CI, failure thresholds are set for high-severity issues.
• Track the improvement suggestions that are included in closed PRs but have not yet been implemented.
• Compare the quality and cost of different models in real codebases.
• The application stack and model endpoints operate on its own infrastructure.

Product advantages

• Community is available for free and supports both Cloud and self-hosted options.
• The core code is made public, while the community portion uses AGPL-3.0.
• There is no charging based on the number of PRs; with an internal key, all plans allow unlimited PRs.
• The model is neutral and supports compatible endpoints.
• No additional fee is charged for the user’s own model tokens.
• Rules, memories, and repository context enhance a team’s adaptability.
• Kody Issues fails to provide sustainable tracking of unimplemented recommendations.
• CLI covers local, CI, and coding Agent workflows.
• It supports four major commercial Git platforms.
• Enterprise offers governance, dedicated instances, and support options.

Usage restrictions

• AI recommendations are probabilistic and may be incorrect, incomplete, or inappropriate.
• No package will have PRs with more than 200 change files reviewed.
• Large discrepancies reduce context quality and increase model costs.
• The cost of BYOK varies depending on the model, the scale of PR, and the number of reviews.
• The data retention policy of model providers is not determined solely by Kodus.
• The plugin is currently in a testing phase and is not suitable for performing high-risk actions directly.
• Incorrect rules and memories will continue to generate systematic false alarms.
• Self-hosting requires maintaining databases, queues, Webhooks, as well as handling upgrades and backups.
• Enterprise files are not covered by the AGPL community license.
• Teams offers cloud hosting only; for traditional self-hosted teams, the Community or Enterprise options must be chosen.
• The anonymous CLI trial is subject to limits on the number of uses per day and on the number of files.

Implementation and procurement list

1. Select a pilot repository with active code development, controllable risks, and a history of pull requests.
2. Determine the hosting method, Git permissions, model provider, and data location requirements.
3. Verify the functionality and licensing boundaries of Community, Teams, and Enterprise.
4. Calculate the number of active developer seats and the monthly Token budget for different models.
5. Establish processes for assigning responsibilities, handling approvals, and approving plugins.
6. Test accuracy and stability using known defects, normal code, and large PRs.
7. Statistics on the adoption rate of suggestions, the false positive rate, review delays, and the time required for manual verification are recommended.
8. Verify key encryption, roles, auditing, deletion, backup, and incident response.
9. When self-hosting, check anonymous telemetry, network outbound connections, and upgrade rollback.
10. The contract specifies refunds, SLAs, support, DPA, and exit migration.
11. Expand the scope gradually after passing the evaluations in terms of engineering, security, privacy, and legal aspects.

Frequently Asked Questions

What does Kodus do mainly?

Kodus utilizes Kody to carry out AI-based code reviews on PRs or local changes, helping teams identify defects, as well as issues related to security, performance, and quality; it also adapts team processes by employing rules, knowledge bases, and metrics.

Is Kodus free?

Community is available for free on a long-term basis; it supports both cloud-based and self-hosted setups, and allows unlimited PR reviews as long as model keys are provided. Teams are billed based on the number of active developers, while Enterprise offers customized pricing.

How is Teams billed?

The monthly fee is $10 per active developer, while the annual fee amounts to $8 per developer; model tokens are charged separately. Only developers who create pull requests within a billing cycle are counted as active developers.

Is a credit card required for the trial?

The 14-day trial of Teams’ features does not require a credit card, and it includes 5 free reviews using the default model key. Once those reviews are completed, you can use your own model key to continue with the reviews.

Will Kodus use code to train models?

Kodu will not use customer codes or personal data to train or fine-tune the base model, unless the customer explicitly enables it. The way in which the model provider selected under BYOK retains and handles requests depends on the agreement between the user and that provider.

Is Kodus completely open source?

The community version is governed by the AGPL-3.0 license, whereas the files and directories related to the enterprise version are subject to commercial licenses. It features a dual-licensing structure, meaning that not all Enterprise features can be considered part of the AGPL open-source framework.

Can it be deployed on my own server?

Yes, both Community and Enterprise offer self-hosted options. Teams is a cloud-based solution; those who choose a self-hosted approach are responsible for handling deployment, databases, queues, Webhooks, as well as upgrades and backups.

Which Git platforms are supported?

It primarily supports GitHub, GitLab, Bitbucket, and Azure Repos; the deployment documentation also provides support for Forgejo event integration. The CLI allows for the direct inspection of local Git differences and can be used in CI processes.

Summary

Kodu is suitable for development teams that wish to integrate AI code review into their existing Git workflows, while still retaining control over the models, costs, and deployment process. Community offers a comprehensive quality assurance workflow that includes free access, self-hosting, BYOK, Kody Rules, team memory, Issues, and a CLI tool.

It cannot replace manual review, testing, static analysis, and security audits. Before going live, it is essential to verify issues such as false positives and false negatives in the actual warehouse, the terms related to model data, the boundaries between AGPL and corporate licenses, as well as the costs associated with self-hosted operations.