# Understanding Overages, Lines of Code & Quota This guide explains how Lines of Code (LOC) are counted in [**Bito's AI Code Review Agent**](/ai-code-reviews-in-git/overview.md), how monthly and yearly quota is assigned, how overages work, and practical steps you can take to optimize your usage. *** ### 1. What Are Lines of Code (LOC)? LOC is the primary unit of measurement in Bito's pricing model. Every time a code review is triggered, Bito counts the lines in the PR diff that are sent to the AI for analysis. #### 1.1 What is counted in a diff? A diff includes three types of lines: | Line Type | Description | Counted? | | ---------------------- | -------------------------------------------------------------------------------------- | -------- | | Additions (+) | New lines added in the PR | ✅ Yes | | Deletions (−) | Lines removed in the PR | ✅ Yes | | Relevant context lines | Unchanged lines shown around changes for context (usually a small percentage of total) | ✅ Yes | {% hint style="info" %} **Key formula** `LOC = Additions + Deletions + Relevant context lines` This applies to the portion of the diff that is sent for review, after any exclusion filters are applied. {% endhint %} {% hint style="info" %} Generated files, Lock files, dist/build folders, snapshots, etc. are excluded automatically. {% endhint %} #### 1.2 Does review mode (Comprehensive vs. Essential) affect LOC? No. The Comprehensive and Essential review modes control the depth of AI analysis — they do not change how many lines are counted. LOC is purely a function of the diff size. *** ### 2. Types of reviews and how they affect LOC There are two ways to trigger a code review in Bito: | Review Type | What is reviewed | Triggered by | Diff used | | ----------- | ------------------------------------------- | -------------------------------- | ----------------------------- | | Automatic | Full diff of the PR at the time of creation | PR is opened | Full diff | | Manual | Depends on review history — see below | `/review` command in PR comments | Full diff or incremental diff | #### 2.1 How manual review works — full vs. incremental diff The diff used in a manual review depends on the PR's review history: * **First review on a PR** — Bito reviews the full diff (all additions, deletions, and context lines across all commits). * **Subsequent reviews after new commits are pushed** — Bito automatically switches to an incremental diff, reviewing only the new commits added since the last review. Previously reviewed lines are not re-counted. {% hint style="info" %} **In short:** There is no separate "incremental" trigger. Incremental behaviour is how manual review works once a PR has already been reviewed by Bito and new commits have been added. {% endhint %} {% hint style="warning" %} **Important to understand** On a single PR, multiple review sessions can occur. The total LOC charged for that PR = sum of LOC across all individual sessions. * The first automatic or manual review always uses the full diff. * Subsequent manual reviews (after new commits) only count the new commit lines — previously reviewed lines are not re-counted. {% endhint %} *** ### 3. Quota assignment #### 3.1 How quota is calculated Quota is allocated per seat and pooled across your organisation. This means a developer who writes large PRs can draw from the quota of developers who are less active in a given period — the pool normalises usage naturally across teams. | Plan | Included quota | Overage rate | Billing cycle | | ---------------------- | ------------------------ | ---------------- | --------------- | | Team (Monthly) | 5,000 LOC / seat / month | $5 per 1,000 LOC | Monthly | | Team (Annual) | 60,000 LOC / seat / year | $5 per 1,000 LOC | Annually | | Professional (Monthly) | 5,000 LOC / seat / month | $5 per 1,000 LOC | Monthly | | Professional (Annual) | 60,000 LOC / seat / year | $5 per 1,000 LOC | Annually | | Enterprise | Custom limits | Custom | Custom contract | {% hint style="info" %} **Example** Team of 10 developers on the Team plan (monthly): * Total pooled quota = 10 × 5,000 = **50,000 LOC / month** * If the team reviews 55,000 LOC in a month, an overage of 5,000 LOC is charged: `5,000 ÷ 1,000 × $5 = $25 overage for that month` {% endhint %} #### 3.2 Monthly vs. Annual subscriptions The effective per-seat rate is the same (5,000 LOC/seat/month) for both monthly and annual subscribers, but the way quota is pooled differs: * **Monthly subscribers** — quota is pooled per month at 5,000 LOC × seats. Unused quota does **not** roll over from one month to the next. * **Annual subscribers** — quota is pooled across the full year at 60,000 LOC × seats (5,000 × 12). Within the annual cycle, lighter months effectively offset heavier ones; quota does not roll over past the annual renewal. Annual subscribers also benefit from a lower per-seat price. #### 3.3 Prorated LOC for mid-cycle additions When a user is added or a workspace is upgraded mid-month, the LOC is prorated based on remaining days in the billing cycle. **Monthly billing** **Formula:** `Prorated LOC = (Total LOC Quota / 30) × Remaining Days` Where `Total LOC Quota = Number of users added × 5,000` {% hint style="info" %} **Example — monthly billing** A user is added on the 21st of a 30-day month. * Remaining days = 10 * Prorated LOC = (5,000 / 30) × 10 = **1,667 LOC** {% endhint %} **Yearly billing** **Formula:** `Prorated LOC = (Total LOC Quota / 365) × Remaining Days` Where `Total LOC Quota = Number of users added × 5,000 × 12` (i.e. 60,000 LOC per user per year) {% hint style="info" %} **Example — yearly billing** A user is added on April 21, with 254 days remaining in the annual cycle. * Prorated LOC = (60,000 / 365) × 254 = **41,753 LOC** {% endhint %} #### 3.4 Why does Bito charge for LOC? Bito's pricing is usage-based because AI costs scale directly with the volume of code analysed. Bito does not downgrade to lower-quality AI models to reduce costs — the goal is to keep review quality high while charging a thin margin on top of actual AI compute costs. *** ### 4. Overages An overage occurs when your organisation's total reviewed LOC in a billing period exceeds the pooled quota — `seat count × 5,000 LOC` per month for monthly plans, or `seat count × 60,000 LOC` per year for annual plans. * Overages are billed at **$5 per 1,000 LOC** beyond your included quota. * Overages are calculated at the organisation level across all repos and agents. * Overage charges are reflected on your next invoice. {% hint style="danger" %} **Common overage causes to watch for** * High-frequency automatic reviews on PRs with large diffs * Manual reviews triggered repeatedly on the same PR before new commits are added (re-counts the full diff each time) * Short incremental batch windows (e.g. 15 or 30 minutes) creating many small review sessions * Reviewing generated files, lock files, or build artifacts that could be excluded {% endhint %} *** ### 5. Optimization strategies The following strategies can help you manage your LOC consumption and reduce the likelihood of overages. #### 5.1 Exclude files and folders that don't need review Configure file/folder exclusion filters in your Agent settings to skip non-essential files. Common candidates to exclude: * `.md` (Markdown documentation) * `.gitignore`, `.yml`, `.yaml`, `.xml`, `.json` config files * Lock files (`package-lock.json`, `yarn.lock`, `Gemfile.lock`, etc.) * Build, dist, and output folders * Snapshot and generated test files Configure exclusions in **Agent Settings → Exclude Files and Folders**. Supports glob and regex patterns. See: [Excluding files, folders, or branches with filters](/ai-code-reviews-in-git/excluding-files-folders-or-branches-with-filters.md). #### 5.2 Use branch filters to limit which PRs are reviewed Configure source and target branch filters so that only production-bound code is reviewed automatically. For example, trigger reviews only on PRs targeting `main` or `release/*` branches — not every feature-to-feature merge. Configure in **Agent Settings → Source Branch / Target Branch Filters**. #### 5.3 Use automatic and manual reviews strategically For most teams, the most effective approach is: 1. Let automatic review run when the PR is opened — this gives the author early feedback on the full diff. 2. Push additional commits and use `/review` in PR comments only when you want a follow-up review — Bito will automatically review only the new commits, keeping LOC usage low. 3. Avoid triggering manual reviews on a PR that has no new commits since the last review — this re-counts the full diff unnecessarily. #### 5.4 Enable Draft PR exclusion Enable **Draft Review Exclusion** in Agent Settings so that draft PRs are not reviewed automatically. Drafts are often works-in-progress with large, rapidly-changing diffs that would consume quota unnecessarily. #### 5.5 Summary of recommended settings | Setting | Recommended value | Why | | ---------------------- | ------------------------------------------------ | ----------------------------------------------- | | Automatic review | Enabled selectively (e.g. target branch filters) | Limit auto-reviews to production-bound PRs only | | Draft PR exclusion | Enabled | Skip WIP code that changes frequently | | File/folder exclusions | All non-production files | Reduce diff size by removing irrelevant files | | Branch filters | Target: `main` / `release/*` | Only review production-bound code | *** ### Frequently Asked Questions **Are deleted lines counted?** Yes. Deletions are part of the diff and are included in the LOC count, since the AI analyses removed code as part of understanding the change. **Are unchanged context lines counted?** Yes, but they typically represent a small percentage of total LOC. Relevant context lines give the AI the surrounding code it needs to provide accurate feedback. **If I run `/review` again after pushing new commits, are old lines re-counted?** No. Once a PR has been reviewed by Bito, subsequent manual reviews triggered via `/review` will only count the new commits added since the last review — not the lines already reviewed. **If I run `/review` again without pushing any new commits, what happens?** Bito will re-review the full diff since there are no new commits to isolate. This will count the same lines again, so avoid triggering manual reviews unless new commits have been pushed. **Does Comprehensive mode use more LOC than Essential mode?** No. The review mode controls the depth of analysis, not the number of lines counted. LOC is determined solely by the diff size and relevant context lines. **Are generated files and lock files excluded automatically?** Yes, certain commonly generated file types are excluded by default. You can extend this with custom exclusion patterns in Agent Settings to cover project-specific generated files. **Is there a `.bito.yaml` configuration to reduce LOC consumption?** There is no direct LOC reduction via `.bito.yaml`. LOC is calculated from the actual diff size after exclusion filters are applied. The most effective levers are the [file exclusion filters and branch filters](/ai-code-reviews-in-git/excluding-files-folders-or-branches-with-filters.md) configured in Agent Settings. **How does pooled quota help larger teams?** Teams with 50+ developers benefit the most from pooling, since not all developers open PRs at the same time and usage naturally normalises across the team. Smaller teams (under 20–25 seats) may see more month-to-month variability and should focus on the [optimization strategies](#id-5.-optimisation-strategies). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.bito.ai/help/billing-and-plans/understanding-overages-lines-of-code-and-quota.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.