Self-hosted AI code review: PR-Agent or Kodus with a local LLM for your merge requests

What a review bot does on each merge request

A self-hosted AI code review bot comments on every merge or pull request with a local LLM on your own GPU, so the code and the diff stay in your network. The open-source PR-Agent (MIT) does this for GitHub, GitLab, Bitbucket and Gitea through a webhook server or a CI job; Kodus (AGPLv3) is a second option. By our estimate from NVIDIA's published throughput, one NVIDIA RTX PRO 6000 Blackwell Server Edition can carry the review load of a whole development department, since reviews wait in a queue and nobody watches each answer arrive.

PR-Agent works through commands that it runs on its own when a merge request opens, or that a developer types as a comment. /describe writes the title and description, /review writes a review with optional sections for review effort, security concerns and tests and posts each key issue as an inline comment where the platform allows it, /improve proposes code changes, and /ask answers a question about the change. In PR-Agent's configuration examples, GitLab and Gitea run /describe, /review and /improve on each new merge request; the GitLab example also runs /describe and /review again on new commits and skips draft merge requests by default.

The bot does not approve anything. It adds a second reader for every diff, however large, while the human approver, the linters, the static application security testing and the test suite stay in the pipeline. Our article on GPU CI runners covers builds and tests on GPUs; this page is about the language model that reads the code.

PR-Agent in October 2026

PR-Agent's README says Qodo donated the project to the open-source community; it now lives in its own GitHub organisation, is community-owned and is being donated to an open-source foundation. It describes itself as "distinct from Qodo's primary AI code review offering", and Qodo's former hosted enterprise version, Qodo Merge, is now called Qodo (2.0). The repository shows 13.6k stars, and PyPI lists 0.49.0 of 25 October 2026 as the current release, after 0.48.0 of 16 October and 0.47.0 of 2 October; it requires Python 3.12 or later.

The recent releases are mostly hardening. Since 0.47.0 Gitea webhooks need a secret or are rejected with HTTP 403; 0.48.0 runs the Docker service images as a non-root user and redacts provider tokens from logs; 0.49.0 adds a DNS rebinding block and more credential redaction. /help_docs has been disabled since 0.36.1 because of a credential-exposure issue. Images from 0.34.2 on are published as pragent/pr-agent, and the documentation advises pinning a version tag or digest in production instead of latest, which moves with every release.

For GitLab, the documentation describes two ways to run it. As a CI job on merge_request_event it reviews each new merge request, but it receives no comment events, so developers cannot call /review or /improve from a comment. As a webhook server it reacts to push, comment and merge request events; it needs a dedicated GitLab user, a personal access token with api scope, the Developer role if /describe may edit descriptions (Reporter is enough for review comments) and GitLab 15.7 or later for the diff retrieval. GITLAB__URL points it at a self-managed instance. Gitea and Bitbucket Server have their own webhook servers. The webhook server sizes itself from the CPUs of its container, with 2 to 4 workers by default, and the documentation suggests starting from about 1 GiB of memory for 4 workers.

Connecting PR-Agent to a local model

PR-Agent addresses every model through a LiteLLM model name. The documentation's Ollama example sets model = "ollama/qwen2.5-coder:32b", custom_model_max_tokens=128000 and duplicate_examples=true, which repeats the format examples in the prompt "to help the model to generate structured output", with api_base in an [ollama] section. A vLLM server is addressed as an OpenAI-compatible endpoint: model = "openai/<model id>" and api_base in the [openai] section of .secrets.toml, or the variables OPENAI__API_BASE and OPENAI__KEY.

The context window has to match on both sides. PR-Agent warns that Ollama's default context "is not enough to cover pr-agent prompt and pull-request diff" and that custom_model_max_tokens must follow OLLAMA_CONTEXT_LENGTH, or the model output may be unexpected. With vLLM, set --max-model-len and custom_model_max_tokens together. When a diff is larger than the budget, PR-Agent compresses it: it drops binary and non-code files, sorts files by the repository's main languages and by size, keeps additions before deletions, lists the rest as "other modified files" and skips what still does not fit. Splitting a large review into chunks is off by default; when switched on, each chunk is a separate model call, up to max_number_of_calls, which defaults to 3.

The documentation is cautious about local models. It states that "local open-source models are suitable for experimentation and learning purposes" and "not suitable for production-level code analysis tasks", in a passage that refers to models available "as of January 2025". Qwen3-Coder and gpt-oss were published after that, but no PR-Agent page re-evaluates them, so treat the first weeks as a pilot: run the bot on recent merge requests that your reviewers have already judged and compare its findings with theirs.

You can order the workstation or server alone, the setup of vLLM, the review model and PR-Agent for your Git server alone, or both together: the system delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

Kodus, GitLab Duo and a webhook of your own

Kodus describes itself as "Open source (AGPLv3) AI code review you self-host on-prem or in your cloud". Its page lists GitHub Enterprise Server, GitLab Self-Managed and Bitbucket Data Center as self-managed platforms and also names Gitea and Forgejo, and its README adds rules written in plain language per repository or path and tracking of suggestions that were never implemented. Any OpenAI-compatible API serves as the model, set with three variables: API_OPENAI_FORCE_BASE_URL, API_OPEN_AI_API_KEY and API_LLM_PROVIDER_MODEL. Kodus states that it does not proxy these calls. It runs with Docker Compose and needs at least 8 GB of RAM, 16 GB for repositories over 100,000 lines of code, with PostgreSQL and pgvector, MongoDB and RabbitMQ. SSO, role-based access, audit logs and analytics are enterprise features under a commercial licence, and self-hosted instances send a daily anonymous heartbeat unless KODUS_TELEMETRY_DISABLED=true is set.

Inside GitLab, the older, non-agentic GitLab Duo Code Review is available only with the Duo Enterprise add-on, while GitLab's documentation lists the Code Review Flow of the GitLab Duo Agent Platform for the Free, Premium and Ultimate tiers, including GitLab Duo with self-hosted models; it runs as a CI/CD job on your own runners and has its own prerequisites (GitLab documentation 19.6, read 31 October 2026). Our GitLab Duo Self-Hosted article notes that the flow gathers up to about 1 MiB of merge request context. A team can also write its own bot on the Git server's webhooks. GitHub's documentation asks for a 2XX answer "within 10 seconds" and recommends a queue for the payloads, since a review takes far longer; the same pattern applies to every Git server.

Which model for code review

A review model has to read a long diff with the files around it and answer in the structure the bot expects, which is why PR-Agent's Ollama example repeats the format examples in the prompt. Four open models fit the hardware in this article, all under Apache 2.0.

Hugging Face model cards, configuration and file pages (gpt-oss-20b, Qwen3-Coder-30B-A3B, Qwen3-Coder-Next read 30 October 2026; gpt-oss-120b from our coding articles, read 24 October 2026). Cache in BF16 by our arithmetic from each config.json; an FP8 cache halves it.

Qwen3-Coder-30B-A3B is the usual start: its card describes tool calling and a native context of 262,144 tokens, and it runs only in non-thinking mode, which keeps answers short. gpt-oss-20b supports structured outputs and three reasoning levels set in the system prompt, and fits a 32 GB card. Qwen3-Coder-Next fits one 96 GB RTX PRO 6000 card with room for only about 5 sessions of 64K by our rule, so it runs best as a tensor-parallel pair on two cards, which suits a review that shares the server with the coding agents. Our guide to a private coding assistant lists the licences of these and of models that restrict commercial use.

How many merge requests per hour one GPU reviews

Review is a batch workload. A merge request can wait a minute for its comments, so what matters is how many calls a card completes per hour. The nearest published figure is NVIDIA's TensorRT-LLM performance table for Qwen3-30B-A3B, which has the same layers, heads and experts as the Coder model: in FP4 on one RTX PRO 6000 Server Edition it produces 374 output tokens per second with 32,768-token prompts and 1,024-token answers, and 1,914 with 8,192-token prompts, at maximum throughput with all requests queued. By our arithmetic that is about 22 calls per minute with 32K prompts and 112 with 8K prompts. If each of the three commands makes one call per merge request, which we assume for a review without chunking, the card completes about 440 merge requests per hour with 32K prompts. That is an upper bound for FP4 on the Server Edition; FP8 weights and a queue that is not kept full reach less, and a pilot measures your figure.

Memory sets how many reviews run at once. By our users-per-card rule (90 per cent of the memory the driver reports, less 3 GiB per card, less the weights), a 32 GB card leaves 25.7 GiB, the RTX PRO 5000 72 GB 61.5 GiB and a 96 GB RTX PRO 6000 83.0 GiB.

By our users-per-card rule, BF16 cache (FP8 cache in brackets; gpt-oss-20b with BF16 cache only). Throughput: NVIDIA TensorRT-LLM performance overview, read 30 October 2026, output tokens per second per GPU at maximum throughput, measured on the RTX PRO 6000 Blackwell Server Edition.

On one 96 GB RTX PRO 6000 Blackwell card, gpt-oss-120b also fits, with 9 reviews of 64K or 4 of 128K. In a workstation the card is the RTX PRO 6000 Workstation Edition or Max-Q; in a rack server for continuous operation we recommend the Server Edition, the passive card the NVIDIA table was measured on.

On a shared coding server, give review its own engine instance so that a burst of merge requests does not slow the developers' agents, either on its own card or in a MIG instance of an RTX PRO 6000, as our article on RTX PRO 6000 MIG profiles describes. Large reviews can also wait for the evening. We set up this split, a review instance beside the agents' instance, on your server; describe your current Git and CI setup and we suggest how to divide the cards. Our article on the server for coding agents sizes the agent side of such a server.

Tokens, logs and secrets

The bot's token is the most powerful thing it holds. Give the bot its own Git user with the lowest role that works, Reporter for comments on GitLab and Developer only if /describe may rewrite descriptions, and rotate the token like any service credential. Set a webhook secret on every platform; PR-Agent rejects Gitea webhooks without one since 0.47.0.

Diffs contain whatever developers commit, sometimes a key or a password. Log calls at an LLM gateway with user, model and token counts, and decide on purpose whether prompts are stored at all; which code may reach which tool is the subject of our guide to an AI coding assistant policy. Keep vLLM on the internal network, as our article on securing a GPU server explains: by vLLM's security guide for version 0.32.0, its --api-key protects only the paths under /v1, /v2, /inference and /cohere. Pin the PR-Agent image to a version, so that an upgrade of the bot is a change you review like any other.

We connect the review bot to your GitLab, Gitea or Bitbucket server and set up the model behind it; tell us your Git platform and how many merge requests a day your teams open, and we size the system for your tasks and budget.

FAQ