lgtm-ai is your AI-powered code review companion. It generates code reviews using your favorite LLMs and helps human reviewers with detailed, context-aware reviewer guides. Supports GitHub, GitLab, and major AI models including GPT-4, Claude, Gemini, and more.
Table of Contents
- Quick Usage
- Installation
- How it works
- Contributing
- Contributors ✨
lgtm review --pr-url "https://gitlab.com/your-repo/-/merge-requests/42" \
--ai-api-key $OPENAI_API_KEY \
--git-api-key $GITLAB_TOKEN \
--model gpt-4.1 \
--publish
This will generate a review like this one:
lgtm guide --pr-url "https://gitlab.com/your-repo/-/merge-requests/42" \
--ai-api-key $OPENAI_API_KEY \
--git-api-key $GITLAB_TOKEN \
--model gpt-4.1 \
--publish
This will generate a reviewer guide like this one:
pip install lgtm-ai
Or you can use the official Docker image:
docker pull elementsinteractive/lgtm-ai
lgtm reads the given pull request and feeds it to several AI agents to generate a code review or a reviewer guide. The philosophy of lgtm is to keep the models out of the picture and totally configurable, so that you can choose which model to use based on pricing, security, data privacy, or whatever is important to you.
If instructed (with the option --publish
), lgtm will publish the review or guide to the pull request page as comments.
Reviews generated by lgtm will be assigned a score, using the following scale:
Score | Description |
---|---|
LGTM 👍 | The PR is generally ready to be merged. |
Nitpicks 🤓 | There are some minor issues, but the PR is almost ready to be merged. |
Needs Work 🔧 | There are some issues with the PR, and it is not ready to be merged. The approach is generally good, the fundamental structure is there, but there are some issues that need to be fixed. |
Needs a Lot of Work 🚨 | Issues are major, overarching, and/or numerous. However, the approach taken is not necessarily wrong. |
Abandon ❌ | The approach taken is wrong, and the author needs to start from scratch. The PR is not ready to be merged as is at all. |
For each review, lgtm may create several inline comments, pointing out specific issues within the PR. These comments belong to a category and have a severity. You can configure which categories you want lgtm to take a look at (see the configuration section below). The available categories are:
Category | Description |
---|---|
Correctness 🎯 | Does the code behave as intended? Identifies logical errors, bugs, incorrect algorithms, broken functionality, or deviations from requirements. |
Quality ✨ | Is the code clean, readable, and maintainable? Evaluates naming, structure, modularity, and adherence to clean code principles (e.g., SOLID, DRY, KISS). |
Testing 🧪 | Are there sufficient and appropriate tests? Includes checking for meaningful test coverage, especially for edge cases and critical paths. Are tests isolated, reliable, and aligned with the behavior being verified? |
Security 🔒 | Does the code follow secure programming practices? Looks for common vulnerabilities such as injection attacks, insecure data handling, improper access control, hardcoded credentials, or lack of input validation. |
There are three available severities for comments:
- LOW 🔵
- MEDIUM 🟡
- HIGH 🔴
lgtm aims to work with as many services as possible, and that includes remote repository providers. At the moment, lgtm supports:
lgtm will autodetect the url of the pull request passed to --pr-url
.
lgtm-ai can enhance code reviews by including context from linked issues or user stories (e.g., GitHub/GitLab issues). This helps the AI understand the purpose and requirements of the PR.
How to use:
- Provide the following options to the
lgtm review
command:--issues-url
: The base URL of the issues or user story page.--issues-source
: The platform for the issues (e.g.,github
,gitlab
).--issues-regex
: (Optional) A regex pattern to extract the issue ID from the PR title or description.--issues-api-key
: (Optional) API key for the issues service (if different from--git-api-key
).
Example:
lgtm review \
--pr-url "https://github.com/your-org/your-repo/pull/42" \
--issues-url "https://github.com/your-org/your-repo/issues" \
--issues-source github \
--issues-regex "(?:Fixes|Resolves) #(\d+)" \
--issues-api-key $GITHUB_TOKEN \
...
- These options can also be set in the
lgtm.toml
configuration file, see more in the configuration section. - lgtm will automatically extract the issue ID from the PR metadata using the provided regex, fetch the issue content, and include it as additional context for the review.
Notes:
- Only GitHub and GitLab issues are supported for now.
- If
--issues-api-key
is not provided, lgtm will use--git-api-key
for authentication. - If no issue is found, the review will proceed without issue context.
- lgtm provides a default regex for extracting issue IDs that works with conventional commits. This means you often do not need to specify
--issues-regex
if your PR titles or commit messages follow the conventional commit format (e.g.,feat(#123): add new feature
), or if your PR descriptions contain mentions to issues like:refs: #123
orcloses: #123
.
lgtm supports several AI models so you can hook up your preferred LLM to perform reviews for you.
This is the full list of supported models:
Provider | Example Models | API Key Setup |
---|---|---|
OpenAI | gpt-5 , gpt-4.1 , gpt-4o-mini , o1-preview |
Generate API key |
Google Gemini | gemini-2.5-pro , gemini-2.5-flash |
Get API key |
Anthropic (Claude) | claude-3.5-sonnet-latest , claude-3-opus-latest |
Anthropic Console |
Mistral | mistral-large-latest , mistral-small , codestral-latest |
Mistral Platform |
DeepSeek | deepseek-chat , deepseek-reasoner |
DeepSeek Platform |
Local / Custom | Any OpenAI-compatible model (e.g. llama3 ) |
Run with --model-url http://localhost:11434/v1 |
Check out the OpenAI platform page to see all available models provided by OpenAI.
To use OpenAI LLMs, you need to provide lgtm with an API Key, which can be generated in the OpenAI platform page for your project, or your user.
Supported OpenAI models
These are the main supported models, though the CLI may support additional ones due to the use of pydantic-ai.
Model name |
---|
gpt-5 |
gpt-5-mini |
gpt-4.1 |
gpt-4.1-mini |
gpt-4.1-nano |
gpt-4o * |
gpt-4o-mini |
o4-mini |
o3-mini |
o3 |
o1-preview |
o1-mini |
o1 |
gpt-4-turbo |
gpt-4 |
gpt-3.5-turbo |
chatgpt-4o-latest |
Check out the Gemini developer docs to see all models provided by Google.
To use Gemini LLMs, you need to provide lgtm an API Key, which can be generated here.
These are the main supported models, though the CLI may support additional ones due to the use of pydantic-ai. Gemini timestamps models, so be sure to always use the latest model of each family, if possible.
For Gemini models exclusively, you can provide a wildcard at the end of the model name and lgtm will attempt to select the latest model (e.g., gemini-2.5-pro*
)
Supported Google's Gemini models
Model name |
---|
gemini-2.5-pro |
gemini-2.5-pro-preview-06-05 |
gemini-2.5-pro-preview-05-06 |
gemini-2.5-flash |
gemini-2.0-pro-exp-02-05 |
gemini-2.0-flash |
gemini-1.5-pro |
gemini-1.5-flash |
Check out Anthropic documentation to see which models they provide. lgtm works with a subset of Claude models. To use Anthropic LLMs, you need to provide lgtm with an API Key, which can be generated from the Anthropic Console.
Supported Anthropic models
These are the main supported models, though the CLI may support additional ones due to the use of pydantic-ai.
Model name |
---|
claude-sonnet-4-0 |
claude-3-7-sonnet-latest |
claude-3-5-sonnet-latest |
claude-3-5-haiku-latest |
claude-3-opus-latest |
Check out the Mistral documentation to see all models provided by Mistral.
To use Mistral LLMs, you need to provide lgtm with an API Key, which can be generated from Mistral's Le Platforme.
Supported Mistral AI models
These are the main supported models, though the CLI may support additional ones due to the use of pydantic-ai.
Model name |
---|
mistral-large-latest |
mistral-small |
codestral-latest |
Check out the DeepSeek documentation to see all models provided by DeepSeek.
At the moment, lgtm only supports DeepSeek from https://api.deepseek.com
: other providers and custom URLs are not supported. However, this is in our roadmap!
To get an API key for DeepSeek, create one at DeepSeek Platform.
Supported DeepSeek models
Model name |
---|
deepseek-chat |
deepseek-reasoner |
You can run lgtm against a model available at a custom url (say, models running with ollama at http://localhost:11434/v1). These models need to be compatible with OpenAI. In that case, you need to pass the option --model-url
(and you can choose to skip the option --ai-api-token
). Check out the pydantic-ai documentation to see more information about how lgtm interacts with these models.
lgtm review \
--pr-url https://github.com/group/repo/pull/1 \
--model llama3.2 \
--model-url http://localhost:11434/v1 \
...
lgtm is meant to be integrated into your CI/CD pipeline, so that PR authors can choose to request reviews by running the necessary pipeline step.
For GitLab, you can use this .gitlab-ci.yml step as inspiration:
lgtm-review:
image:
name: docker.io/elementsinteractive/lgtm-ai
entrypoint: [""]
stage: ai-review
needs: []
rules:
- if: $CI_MERGE_REQUEST_ID
when: manual
script:
- lgtm review --pr-url ${MR_URL} --git-api-key ${LGTM_GIT_API_KEY} --ai-api-key ${LGTM_AI_API_KEY} -v
variables:
MR_URL: "${CI_PROJECT_URL}/-/merge_requests/${CI_MERGE_REQUEST_IID}"
For GitHub, you can use the official LGTM AI GitHub Action:
- name: AI Code Review
uses: elementsinteractive/lgtm-ai@v1
with:
ai-api-key: ${{ secrets.AI_API_KEY }}
git-api-key: ${{ secrets.GITHUB_TOKEN }}
model: 'gpt-5'
pr-number: ${{ github.event.issue.number }}
You can also check out this repo's lgtm workflow for a complete example with comment triggers (/lgtm review
).
You can customize how lgtm works by passing cli arguments to it on invocation, or by using the lgtm configuration file.
You can configure lgtm through cli arguments, through environment variables, and through a configuration file. lgtm uses a .toml
file to configure how it works. It will autodetect a lgtm.toml
file in the current directory, or you can pass a specific file path with the CLI option --config <path>
.
Alternatively, lgtm also supports pyproject.toml files, you just need to nest the options inside [tool.lgtm]
.
When it comes to preference for selecting options, lgtm follows this preference order:
CLI options
> lgtm.toml
> pyproject.toml
Summary of options
Option | Feature Group | Optionality | Notes/Conditions |
---|---|---|---|
model | Main (review + guide) | 🟢 Optional | AI model to use. Defaults to gpt-4.1 if not set. |
model_url | Main (review + guide) | 🟡 Conditionally required | Only needed for custom/local models. |
exclude | Main (review + guide) | 🟢 Optional | File patterns to exclude from review. |
publish | Main (review + guide) | 🟢 Optional | If true, posts review as comments. Default: false. |
output_format | Main (review + guide) | 🟢 Optional | pretty (default), json , or markdown . |
silent | Main (review + guide) | 🟢 Optional | Suppress terminal output. Default: false. |
ai_retries | Main (review + guide) | 🟢 Optional | Number of retries for AI agent queries. Default: 1. |
ai_input_tokens_limit | Main (review + guide) | 🟢 Optional | Max input tokens for LLM. Default: 500,000. Use "no-limit" to disable. |
git_api_key | Main (review + guide) | 🔴 Required* | API key for git service (GitHub/GitLab). Can't be given through config file. Also available through env variable LGTM_GIT_API_KEY . |
ai_api_key | Main (review + guide) | 🔴 Required* | API key for AI model. Can't be given through config file. Also available through env variable LGTM_AI_API_KEY . |
technologies | Review Only | 🟢 Optional | List of technologies for reviewer expertise. |
categories | Review Only | 🟢 Optional | Review categories. Defaults to all (Quality , Correctness , Testing , Security ). |
additional_context | Review Only | 🟢 Optional | Extra context for the LLM (array of prompts/paths/URLs). Can't be given through the CLI |
issues_url | Issues Integration | 🟢 Optional | Enables issue context. If set, issues_source becomes required. |
issues_source | Issues Integration | 🟡 Conditionally required | Required if issues_url is set. |
issues_regex | Issues Integration | 🟢 Optional | Regex for issue ID extraction. Defaults to conventional commit compatible regex. |
issues_api_key | Issues Integration | 🟢 Optional | API key for issues service (if different from git_api_key ). Can't be given through config file. Also available through env variable LGTM_ISSUES_API_KEY . |
These options apply to both reviews and guides generated by lgtm.
- model: Choose which AI model you want lgtm to use. If not set, defaults to
gpt-4.1
. - model_url: When not using one of the specific supported models from the providers mentioned above, you can pass a custom URL where the model is deployed (e.g., for local/hosted models).
- exclude: Instruct lgtm to ignore certain files. This is important to reduce noise in reviews, but also to reduce the amount of tokens used for each review (and to avoid running into token limits). You can specify file patterns (e.g.,
exclude = ["*.md", "package-lock.json"]
). - publish: If
true
, lgtm will post the review as comments on the PR page. Default isfalse
. - output_format: Format of the terminal output of lgtm. Can be
pretty
(default),json
, ormarkdown
. - silent: Do not print the review in the terminal. Default is
false
. - ai_retries: How many times to retry calls to the LLM when they do not succeed. By default, this is set to 1 (no retries at all).
- ai_input_tokens_limit: Set a limit on the input tokens sent to the LLM in total. Default is 500,000. To disable the limit, you can pass the string
"no-limit"
. - git_api_key: API key to post the review in the source system of the PR. Can be given as a CLI argument, or as an environment variable (
LGTM_GIT_API_KEY
). - ai_api_key: API key to call the selected AI model. Can be given as a CLI argument, or as an environment variable (
LGTM_AI_API_KEY
).
These options are only used when performing reviews through the command lgtm review
.
- technologies: Specify, as a list of free strings, which technologies lgtm specializes in. This can help direct the reviewer towards specific technologies. By default, lgtm won't assume any technology and will just review the PR considering itself an "expert" in it.
- categories: lgtm will, by default, evaluate several areas of the given PR (
Quality
,Correctness
,Testing
, andSecurity
). You can choose any subset of these (e.g., if you are only interested inCorrectness
, you can configurecategories
so that lgtm does not evaluate the other missing areas). - additional_context: TOML array of extra context to send to the LLM. It supports setting the context directly in the
context
field, passing a relative file path so that lgtm downloads it from the repository, or passing any URL from which to download the context. Each element of the array must containprompt
, and eithercontext
(directly injecting context) orfile_url
(for directing lgtm to download it from there).
See Using Issue/User Story Information section.
- issues_url: The base URL of the issues or user story page to fetch additional context for the PR. If set,
issues_source
becomes required. - issues_source: The platform for the issues (e.g.,
github
,gitlab
). Required ifissues_url
is set. - issues_regex: A regex pattern to extract the issue ID from the PR title or description. If omitted, lgtm uses a default regex compatible with conventional commits and common PR formats.
- issues_api_key: API key for the issues service (if different from
git_api_key
). Can be given as a CLI argument, or as an environment variable (LGTM_ISSUES_API_KEY
).
technologies = ["Django", "Python"]
categories = ["Correctness", "Quality", "Testing", "Security"]
exclude = ["*.md"]
model = "gpt-4.1"
silent = false
publish = true
ai_retries = 1
ai_input_tokens_limit = 30000
[[additional_context]]
prompt = "These are the development guidelines for the team, ensure the PR follows them"
file_url = "https://my.domain.com/dev-guidelines.md"
[[additional_context]]
prompt = "CI pipeline for the repo. Do not report issues that this pipeline would otherwise catch"
file_url = ".github/workflows/pr.yml"
[[additional_context]]
prompt = "Consider these points when making your review"
context = '''
- We avoid using libraries and rely mostly on the stdlib.
- We follow the newest syntax available for Python (3.13).
'''
# Optional Issue/user story integration
issues_url = "https://github.com/your-org/your-repo/issues"
issues_source = "github"
# The options below are optional even if the two above are provided
issues_regex = "(?:Fixes|Resolves) #(\d+)"
issues_api_key = "${GITHUB_TOKEN}"
This project uses just
recipes to do all the basic operations (testing the package, formatting the code, etc.).
Installation:
brew install just
# or
snap install --edge --classic just
It requires poetry.
These are the available commands for the justfile:
Available recipes:
help # Shows list of recipes.
venv # Generate the virtual environment.
clean # Cleans all artifacts generated while running this project, including the virtualenv.
test *test-args='' # Runs the tests with the specified arguments (any path or pytest argument).
t *test-args='' # alias for `test`
test-all # Runs all tests including coverage report.
format # Format all code in the project.
lint # Lint all code in the project.
pre-commit *precommit-args # Runs pre-commit with the given arguments (defaults to install).
spellcheck *codespell-args # Spellchecks your markdown files.
lint-commit # Lints commit messages according to conventional commit rules.
To run the tests of this package, simply run:
# All tests
just t
# A single test
just t tests/test_dummy.py
# Pass arguments to pytest like this
just t -k test_dummy -vv
poetry
is the tool we use for managing requirements in this project. The generated virtual environment is kept within the directory of the project (in a directory named .venv
), thanks to the option POETRY_VIRTUALENVS_IN_PROJECT=1
. Refer to the poetry documentation to see the list of available commands.
As a short summary:
-
Add a dependency:
poetry add foo-bar
-
Remove a dependency:
poetry remove foo-bar
-
Update a dependency (within constraints set in
pyproject.toml
):poetry update foo-bar
-
Update the lockfile with the contents of
pyproject.toml
(for instance, when getting a conflict after a rebase):poetry lock
-
Check if
pyproject.toml
is in sync withpoetry.lock
:poetry lock --check
In this project we enforce conventional commits guidelines for commit messages. The usage of commitizen is recommended, but not required. Story numbers (JIRA, etc.) must go in the scope section of the commit message. Example message:
feat(#<issue-number>): add new feature x
Merge requests must be approved before they can be merged to the main
branch, and all the steps in the ci
pipeline must pass.
This project includes an optional pre-commit configuration. Note that all necessary checks are always executed in the ci pipeline, but configuring pre-commit to execute some of them can be beneficial to reduce late errors. To do so, simply execute the following just recipe:
just pre-commit
Feel free to create GitHub Issues for any feature request, bug, or suggestion!
Thanks goes to these wonderful people (emoji key):
Sergio Castillo 💻 🎨 🤔 🚧 |
Jakub Bożanowski 💻 🤔 🚧 |
Sacha Brouté 💻 🤔 |
Daniel 🤔 |
Rooni 💻 |
This project follows the all-contributors specification. Contributions of any kind welcome!