Skip to content
/

Qodo (PR-Agent)

qodo · Codium-ai/pr-agent · ★ 11k · last commit 2026-05-24

Primitive shape 14 total
Commands 14
00

Summary

Qodo (PR-Agent) — Summary

Qodo's PR-Agent (now community-owned at github.com/the-pr-agent/pr-agent) is the original open-source AI PR reviewer — 11,345 stars, Apache-2.0. It operates on pull requests across GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea, providing automated code review, PR description generation, improvement suggestions, and changelog updates. The core architecture: TOML-based prompt templates per tool, a configuration.toml with per-tool settings, and a Python CLI pr-agent --pr_url <URL> review|improve|describe|ask.

Key design: each tool (/review, /improve, /describe, /ask, /update_changelog, /add_docs, /generate_labels) makes a single LLM call against a compressed PR diff. The PR compression strategy intelligently fits large PRs into the context window. "Self-reflection" is a feature where the model evaluates its own output quality. Multi-model support via configuration (OpenAI GPT default, Claude, Deepseek). The project was donated by Qodo to the open-source community in 2025.

Closest seed: spec-kit — both are command-pack tools where each slash command has a matching TOML prompt file and configurable behavior per command. Qodo differs by targeting PR review workflows (not spec-driven development) and by operating as a GitHub Action/webhook rather than a local CLI methodology.

01

Overview

Qodo — Overview

Origin

PR-Agent was created by Codium AI (later rebranded Qodo) and open-sourced. In 2025, Qodo donated PR-Agent to the open-source community; the project now lives at github.com/the-pr-agent/pr-agent. Qodo's commercial product (Qodo Merge / Qodo 2.0) evolved separately as an enterprise PR review platform. The repo at github.com/Codium-ai/pr-agent is a frozen mirror; active development is at the-pr-agent org.

Philosophy

"The Original Open-Source PR Reviewer." PR-Agent's philosophy is that code review should be:

  • Fast: Single LLM call per tool (~30 seconds)
  • Affordable: Minimal token use via PR compression
  • Customizable: JSON-based prompting via TOML config files
  • Platform-agnostic: Same tool works on GitHub/GitLab/Bitbucket/Azure/Gitea
  • Model-agnostic: Supports OpenAI, Claude, Deepseek, and more

Key Design Principles

  1. Single-call tools: Each /review, /improve, /describe is one LLM call — no multi-turn loops
  2. PR Compression strategy: Intelligently clips diffs to fit context; prioritizes changed hunks
  3. Self-reflection: Model evaluates its own output before finalizing (quality gate)
  4. Structured YAML output: Tools emit YAML conforming to Pydantic type definitions
  5. Configuration hierarchy: Global → org → repo → per-PR overrides via .pr_agent.toml

Qodo Commercial Context

While PR-Agent is the open-source project, Qodo (2.0) is the commercial product offering:

  • Free tier for GitHub/GitLab/Bitbucket/Azure
  • Context-aware reviews (fetches Jira/Linear tickets)
  • Post-commit reviews in IDE
  • Full API and enterprise features
02

Architecture

Qodo — Architecture

Distribution

  • Type: Python package + Docker image + GitHub Action
  • CLI binary: pr-agent
  • Stars: 11,345 | License: Apache-2.0

Install Methods

# CLI (pip)
pip install pr-agent
# GitHub Action
uses: the-pr-agent/pr-agent@main
# Docker
docker run pragent/pr-agent --pr_url <URL> review
# Webhook (self-hosted app)
# Via Gunicorn/uvicorn server in pr_agent/servers/

Config Files

  • .pr_agent.toml — per-repo configuration (overrides defaults)
  • pr_agent/settings/configuration.toml — all defaults documented
  • Per-tool prompt TOML files: pr_reviewer_prompts.toml, pr_description_prompts.toml, etc.
  • .secrets.toml / environment variables — API keys

Source Structure

pr_agent/
├── cli.py                — pr-agent CLI entry point
├── agent/                — core agent loop
├── algo/                 — PR compression, token management
├── git_providers/        — GitHub, GitLab, Bitbucket, Azure, Gitea
├── tools/
│   ├── pr_reviewer.py    — /review
│   ├── pr_description.py — /describe
│   ├── pr_code_suggestions.py — /improve
│   ├── pr_questions.py   — /ask
│   ├── pr_update_changelog.py — /update_changelog
│   ├── pr_add_docs.py    — /add_docs
│   ├── pr_generate_labels.py — /generate_labels
│   ├── pr_help_docs.py   — /help_docs
│   └── ticket_pr_compliance_check.py
└── settings/
    ├── configuration.toml — all defaults
    ├── pr_reviewer_prompts.toml
    ├── pr_description_prompts.toml
    ├── pr_code_suggestions.toml (implied)
    └── ... (one TOML per tool)

Supported Git Providers

GitHub, GitLab, Bitbucket, Azure DevOps, Gitea

Supported AI Models

GPT-5.5 (default), GPT-5.4-mini (fallback), Claude, Deepseek, and others via configuration

Deployment Modes

  • CLI: local development
  • GitHub Actions: CI/CD integration
  • Docker: containerized deployment
  • Webhook/App: self-hosted server reacting to PR events
  • Bitbucket/GitLab pipelines: platform-native CI triggers
03

Components

Qodo — Components

Tools (Slash Commands, 14)

Command Description
/review Comprehensive code review with key issues, security checks
/describe Generate PR title + description + walkthrough
/improve Suggest specific code improvements
/ask <question> Ask any question about the PR
/ask on code lines Ask about specific lines (GitHub/GitLab only)
/update_changelog Update CHANGELOG.md based on PR
/add_docs Add documentation to changed code
/generate_labels Suggest PR labels
/help_docs Answer questions from project docs
/similar_issue Find similar issues in the repo
/config Display current configuration
/auto_approve Auto-approve PRs meeting criteria
/ticket_compliance_check Check PR compliance with Jira/Linear ticket
/line_questions Questions scoped to specific lines

Prompt Files (TOML, per tool)

File Tool
pr_reviewer_prompts.toml /review
pr_description_prompts.toml /describe
pr_code_suggestions.toml /improve
pr_questions_prompts.toml /ask
pr_line_questions_prompts.toml /ask on lines
pr_update_changelog_prompts.toml /update_changelog
pr_add_docs.toml /add_docs
pr_help_docs_prompts.toml /help_docs
pr_help_prompts.toml /help

Git Providers

pr_agent/git_providers/: GitHub, GitLab, Bitbucket, Azure DevOps, Gitea

Identity Providers

pr_agent/identity_providers/: authentication abstraction

Secret Providers

pr_agent/secret_providers/: Google Cloud Storage, AWS Secrets Manager

Core Capabilities

  • PR Compression: Adaptive diff fitting to context window
  • Dynamic context: Expand hunks to include enclosing functions/classes
  • Self-reflection: Model self-evaluates output quality
  • Ticket context: Fetch Jira/Linear tickets for compliance checks
  • AI metadata: Optional AI-generated change summaries injected into diffs
05

Prompts

Qodo — Prompts

Verbatim: pr_reviewer system prompt (from pr_reviewer_prompts.toml, excerpt)

[pr_review_prompt]
system="""You are PR-Reviewer, a language model designed to review a Git Pull Request (PR).
Your task is to provide constructive and concise feedback for the PR.
The review should focus on new code added in the PR code diff (lines starting with '+'), and only 
on issues introduced by this PR.

The format we will use to present the PR code diff:
======
## File: 'src/file1.py'

@@ ... @@ def func1():
__new hunk__
11  unchanged code line0
12  unchanged code line1
13 +new code line2 added
14  unchanged code line3
__old hunk__
 unchanged code line0
-old code line2 removed
 unchanged code line3
======

Determining what to flag:
- For clear bugs and security issues, be thorough. Do not skip a genuine problem just 
  because the trigger scenario is narrow.
- For lower-severity concerns, be certain before flagging. If you cannot confidently 
  explain why something is a problem with a concrete scenario, do not flag it.
- Each issue must be discrete and actionable, not a vague concern about the codebase.
- Do not speculate that a change might break other code unless you can identify the 
  specific affected code path from the diff context.
- Do not flag intentional design choices or stylistic preferences unless they introduce 
  a clear defect.
- When confidence is limited but the potential impact is high (e.g., data loss, security), 
  report it with an explicit note on what remains uncertain. Otherwise, prefer not 
  reporting over guessing.

Prompting technique: Explicit review epistemology — "prefer not reporting over guessing" is an anti-hallucination instruction. The __new hunk__ / __old hunk__ diff format with line numbers is a custom structured format that helps the model refer to specific lines.


Verbatim: YAML output schema (from pr_reviewer_prompts.toml, Pydantic excerpt)

class KeyIssuesComponentLink(BaseModel):
    relevant_file: str = Field(description="The full file path of the relevant file")
    issue_header: str = Field(description="One or two word title for the issue. For example: 'Possible Bug', etc.")
    issue_content: str = Field(description="A short and concise description of the issue, why it matters, and the specific scenario or input that triggers it. Do not mention line numbers in this field.")
    start_line: int = Field(description="The start line that corresponds to this issue in the relevant file")
    end_line: int = Field(description="The end line that corresponds to this issue in the relevant file")

Prompting technique: Pydantic-based output specification embedded in the system prompt. The model receives type definitions and must produce YAML conforming to them. This enforces structured output without requiring the model to infer schema.


Configuration Example (from configuration.toml, model section)

[config]
model="gpt-5.5-2026-04-23"
fallback_models=["gpt-5.4-mini"]
reasoning_effort = "medium"  # "none", "minimal", "low", "medium", "high", "xhigh"
enable_claude_extended_thinking = false
extended_thinking_budget_tokens = 2048
temperature=0.2

Technique: Named reasoning effort levels (medium) — provider-agnostic reasoning control. The fallback_models list enables automatic retry on failure with a cheaper/different model.

09

Uniqueness

Qodo — Uniqueness

Differs From Seeds

Closest to spec-kit (both are command-pack tools with per-command configuration files and a mix of slash commands + automation hooks). However the use case is radically different: spec-kit generates specs for features; PR-Agent reviews code after it's written. PR-Agent's TOML prompt files parallel spec-kit's hook/command structure, but PR-Agent targets git platform workflows (GitHub/GitLab webhooks) rather than local IDE sessions. The PR Compression strategy — intelligently managing which parts of large diffs fit in the context window — is a technique unique in the corpus (no seed framework manages diff/spec truncation at this level of sophistication).

Distinctive Opinion

Code review should be a single, fast LLM call with compressed context — not a multi-turn agent loop. The prefer not reporting over guessing instruction in the reviewer prompt is a principled anti-hallucination stance that distinguishes PR-Agent from tools that err toward verbosity.

Positioning

  • "The original open-source PR reviewer" — first mover in automated PR review
  • Now community-maintained; Qodo's commercial product has evolved beyond PR-Agent
  • Competing with CodeRabbit, Sourcery, GitHub Copilot PR review

Observable Failure Modes

  • Single-call design means no self-correction if initial review misses something
  • PR Compression may truncate important context in very large PRs
  • model_token_count_estimate_factor=0.3 can cause under-utilization of context
  • Self-reflection doubles cost for potentially marginal quality gain

Anti-Patterns (from configuration.toml)

  • Don't enable duplicate_prompt_examples (increases token cost without clear benefit)
  • Don't set large_patch_policy="skip" for repos with consistently large PRs
  • Don't use without .pr_agent.toml per-repo config (will use generic defaults)

Cross-References

  • Qodo 2.0 / Qodo Merge: Commercial evolution with IDE integration, auto-run post-commit
  • GitHub Copilot PR review: Direct competitor
  • CodeRabbit: Direct competitor in the automated PR review space
  • PR-Agent community org (the-pr-agent): New home after Qodo donation
04

Workflow

Qodo — Workflow

PR Review Workflow (Primary)

1. PR opened/updated on GitHub/GitLab/Bitbucket/Azure/Gitea
2. Trigger: GitHub Action, webhook, or CLI invocation
3. pr-agent fetches PR diff + metadata
4. PR Compression: intelligently clips diff to fit model context window
   - patch_extra_lines_before: 5, patch_extra_lines_after: 1
   - Dynamic context: expands to enclosing function/class
   - Large PR: "clip" or "skip" strategy
5. Tool (e.g., /review) renders prompt template from TOML
6. Single LLM call with compressed diff + context
7. Self-reflection: model evaluates its own output (optional)
8. Tool parses YAML output conforming to Pydantic type definitions
9. Comment posted to PR via git provider API

Phases + Artifacts

Phase Artifact
PR fetch Diff, metadata, commit list, ticket context
Compression Compressed diff fitting context window
Prompt render Jinja2 template + diff → LLM input
LLM call YAML-structured response
Self-reflection Quality evaluation of own output (optional)
Comment post Formatted review comment on PR

Approval Gates

  • Auto-approve: /auto_approve command with configurable criteria
  • No human gate by default: Tool runs and posts automatically when triggered
  • PR ignore rules: ignore_pr_title, ignore_pr_authors, ignore_pr_labels — skip triggering

Configuration Override Hierarchy

environment variables → secrets → 
global settings → repo settings (wiki) → .pr_agent.toml (repo root) → command line

Automation Triggers

  1. GitHub Actions: on: pull_request: types: [opened, synchronize]
  2. Webhook/App: PR events → server → tool dispatch
  3. Bot tag: @pr-agent-bot /review in PR comment
  4. Scheduled: Configurable via automations (Qodo commercial feature)

Multi-tool Chaining

/describe/review/improve can be configured to auto-run in sequence via auto_commands setting.

06

Memory Context

Qodo — Memory & Context

Memory Type

None — PR-Agent is stateless. Each tool invocation fetches fresh PR data, runs one LLM call, posts comment. No persistent memory between invocations.

Context Sources (Per-Invocation)

  1. PR diff — compressed via PR Compression strategy
  2. PR metadata — title, description, commits, file list
  3. Repository context — language, framework, size
  4. Ticket context — Jira/Linear ticket content (if configured)
  5. AI metadata — AI-generated change summaries (if enable_ai_metadata=true)
  6. Configuration.pr_agent.toml + global defaults

PR Compression Strategy

The core memory-management mechanism: fitting a large PR diff into the model's context window:

  • patch_extra_lines_before: 5 lines before each hunk
  • patch_extra_lines_after: 1 line after each hunk
  • Dynamic context: Expand hunks to enclosing function or class boundary
  • large_patch_policy: "clip" (truncate) or "skip" (ignore file)
  • max_model_tokens: 32,000 (configurable cap)
  • Token estimate factor: 0.3 (buffer to avoid overflow)

Configuration Persistence

  • .pr_agent.toml in repo root — persists per-repo settings
  • Global settings in configuration.toml — framework defaults
  • Wiki settings (use_wiki_settings_file=true) — team-editable config in repo wiki

No Agent Memory

PR-Agent has no session history, no memory of previous reviews on the same PR, and no cross-PR learning. Each invocation is independent.

Self-Reflection as Context Loop

When self_reflection is enabled:

  1. Initial LLM call → response
  2. Second LLM call: "evaluate the quality of this response"
  3. Quality score used to filter/improve output This is the closest PR-Agent gets to multi-turn context management.
07

Orchestration

Qodo — Orchestration

Multi-Agent

No — single-call architecture. Each tool is one LLM invocation.

Orchestration Pattern

Sequential (when multiple tools are chained via auto_commands) or none (single-tool invocation).

Execution Mode

Event-driven — triggered by PR events (webhook/GitHub Actions) or explicit @bot /command in PR comments.

Isolation Mechanism

None — runs as a process in CI/CD (GitHub Actions runner) or webhook server. No container isolation per invocation (though Docker is a deployment option for the whole server).

Self-Reflection Pattern

When enabled (require_score_review=true implied by self-reflection flag):

Initial LLM call → response YAML
  → Second call: "Evaluate quality of: <response>"
  → Quality score
  → Filter or re-generate based on threshold

This is the only multi-turn pattern in PR-Agent's core.

Fallback Model

fallback_models=["gpt-5.4-mini"] — if primary model fails or times out, retry with fallback. This is the closest PR-Agent gets to multi-model routing.

Multi-Model Usage

Single model per invocation with fallback:

  • model: primary model
  • fallback_models: ordered list of fallbacks
  • model_reasoning: optional dedicated reasoning model for self-reflection
  • model_weak: optional cheaper model for easier tasks

Prompt Chaining

Limited — auto_commands can chain /describe/review/improve sequentially but each is an independent LLM call with no state from previous calls.

No Consensus

No Raft, Byzantine, or other consensus mechanisms. Single LLM response per tool call.

08

Ui Cli Surface

Qodo — UI & CLI Surface

CLI

  • Binary: pr-agent
  • Usage: pr-agent --pr_url <URL> <command>
  • Commands: review, describe, improve, ask, update_changelog, add_docs, generate_labels, config

GitHub Actions (Primary Automation)

name: PR Agent
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  pr_agent_job:
    runs-on: ubuntu-latest
    steps:
    - name: PR Agent action step
      uses: the-pr-agent/pr-agent@main
      env:
        OPENAI_KEY: ${{ secrets.OPENAI_KEY }}
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Docker

docker pull pragent/pr-agent
docker run pragent/pr-agent --pr_url <URL> review

Webhook Server / App

  • pr_agent/servers/ — webhook server implementations
  • Responds to platform-specific webhook events
  • Supports bot mention triggers (@pr-agent /review)

No Local UI

PR-Agent has no web dashboard, TUI, or desktop app. Output is delivered as comments on the PR in the git platform's UI.

Configuration UI

  • Wiki settings (use_wiki_settings_file=true) — team edits config via repo wiki page
  • .pr_agent.toml — file-based config in repo

Output Format

  • Reviews posted as comments on PR diffs
  • Describes posted as PR description edits
  • Improvements posted as inline code suggestions
  • All output formatted as structured markdown tables

Observability

  • Logs to stdout (log level configurable: DEBUG/INFO/WARNING)
  • No persistent audit log
  • progress_gif_url — optional loading indicator GIF in PR comments during processing

Related frameworks

same archetype · same primary tool · same memory type

claude-mem (thedotmack) ★ 78k

Background worker service captures every tool call as an observation, AI-compresses sessions, and auto-injects relevant past…

pi (badlogic/earendil) ★ 55k

A minimal, hackable, multi-provider terminal coding agent that adapts to your workflows via npm-installable TypeScript Extensions…

Agent Skills (Addy Osmani) ★ 46k

Encodes senior-engineer software development lifecycle as 23 auto-routed skills and 7 slash commands for any AI coding agent.

wshobson/agents Plugin Marketplace ★ 36k

Single Markdown source for 83 domain-specialized plugins that auto-generates idiomatic artifacts for five AI coding harnesses.

TabbyML/Tabby ★ 34k

Self-hosted AI coding assistant server (alternative to GitHub Copilot) with admin dashboard, RAG-based completions, and multi-IDE…

Compound Engineering ★ 17k

Make each unit of engineering work compound into easier future work via brainstorm→plan→execute→review→learn cycles.