> ## Documentation Index
> Fetch the complete documentation index at: https://www.greptile.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Review Tiers

> Choose how much work Greptile puts into each review. Set a tier for the organization, override it per repository or directory, or let Greptile pick per PR.

The review tier sets how deep Greptile goes on a pull request. Higher tiers take longer, catch more, and cost more credits.

<a id="levels" />

## Tiers

| Tier | Credits | Description |
| - | - | - |
| **Base** | 1 | Thorough code review with full codebase context. |
| **Plus** | 3 | A deeper review for PRs that need extra scrutiny. |
| **Apex** | 10 | Our most intensive review for large, complex PRs. |
| **Auto** | 1, 3, or 10 | Greptile picks a tier for each PR. |

**Auto** picks a tier for each PR from its size, risk, and complexity. You pay for the tier that ran.

T-Rex is not compatible with Plus, Apex, or Auto at this time. T-Rex support is coming soon.

## Recommendations

For most teams, we recommend three settings:

1. **Set the default to Auto.** Most PRs get Base, a thorough code review with full codebase context. PRs that need extra scrutiny get Plus or Apex.
2. **Run Apex on PRs into production.** Add a [tier rule](#tier-rules) where **Target branch** includes your production branch, such as `main` or `production`, and set **Review tier** to **Apex**.
3. **Run Apex on large PRs.** Apex is our most intensive review, built for large, complex PRs. Add a second rule where **Files changed** is **More than** `30`, and set **Review tier** to **Apex**.

A rule set to a tier overrides Auto for the PRs it matches. Auto still picks the tier for everything else.

<a id="set-the-level" />

## Set the tier

<Tabs>
  <Tab title="Dashboard">
    On the [Greptile dashboard](https://app.greptile.com/review#when-reviews), go to **Settings → Code Review → Greptile Review Configuration** and pick a tier under **Review tier**.

    <Frame>
      <img src="https://mintcdn.com/greptile/IzTyaJI4dG71G9g4/images/review-effort.png?fit=max&auto=format&n=IzTyaJI4dG71G9g4&q=85&s=859b3dca132feebac0c84e376eed703b" alt="Review tier setting with the Base, Plus, Apex, and Auto tiers" width="3220" height="1940" data-path="images/review-effort.png" />
    </Frame>

    This is the default for every repository in the organization. Teams inherit it and can set their own.
  </Tab>

  <Tab title=".greptile/ (Recommended)">
    Set `effort` in `.greptile/config.json` at the repository root or in any subdirectory:

    ```json .greptile/config.json theme={}
    {
      "effort": "plus"
    }
    ```

    Values: `base`, `plus`, `apex`, `auto`.

    In a monorepo, a child directory can set its own tier. When one PR touches directories with different tiers, the highest one wins for that PR. See [Cascading Configuration](/docs/code-review/greptile-config#cascading-configuration).
  </Tab>

  <Tab title="greptile.json">
    ```json greptile.json theme={}
    {
      "effort": "plus"
    }
    ```

    <Note>
      This overrides the dashboard setting for this repository.
    </Note>
  </Tab>
</Tabs>

## Raise it for one PR

Ask for a tier in the comment that triggers the review:

```
@greptileai review this at apex
```

`@greptileai apex review` and `@greptileai effort: plus` work too, and `@greptile` works in place of `@greptileai`. A request can raise the tier above the configured one. It cannot lower it.

The request applies to that review only. Reviews started by later pushes go back to the configured tier.

From the [CLI](/docs/code-review/greptile-cli), pass `--plus` or `--apex`:

```bash theme={}
greptile review --apex
```

CLI reviews don't use the configured tier. Without a flag they run at Base.

<a id="effort-rules" />

## Tier rules

Tier rules set the tier for the PRs they match. In **Settings → Code Review → Greptile Review Configuration**, add a filter rule and set its **Review tier**. A rule can use any filter condition, such as label, target branch, file path, or files changed.

For example, a rule where **Label** includes `security` with **Review tier** set to **Apex** runs every PR with that label at Apex.

<Frame>
  <img src="https://mintcdn.com/greptile/IzTyaJI4dG71G9g4/images/review-effort-rules.png?fit=max&auto=format&n=IzTyaJI4dG71G9g4&q=85&s=5f40d5cfe7836aa14730eb99d1bf5f29" alt="Filter rule where Label includes security, with Review tier set to Apex" width="3220" height="1940" data-path="images/review-effort-rules.png" />
</Frame>

A rule set to **Auto** lets Greptile pick the tier for the PRs it matches, even when the organization pins a tier.

<a id="which-level-runs" />

## Which tier runs

Greptile uses the highest of: the dashboard setting, the repository config, any directory config the PR touches, a matching tier rule, and a request in the trigger comment. Auto counts as no tier in that comparison, so any explicit tier beats it. The one exception is a matching tier rule set to Auto. It replaces the configured tier and lets Greptile choose for that PR. A matching Plus or Apex rule, or a request in the trigger comment, still overrides it.

Plus and Apex reviews show the tier next to the confidence score in the review summary. Base reviews show nothing.

## What's next?

* [Billing →](/docs/code-review-bot/billing-seats) for how credits are counted
* [.greptile/ Configuration →](/docs/code-review/greptile-config) for per-directory settings
* [Controlling nitpickiness →](/docs/code-review/controlling-nitpickiness) for strictness and comment types


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.