Usage and Limits

Codity meters usage against three monthly pools that belong to your organization. Every surface draws from the same pools: the dashboard, the CLI, the public API, the Claude Code plugin, and your connected version control system.

Your actual limits are agreed in your contract. This page explains how the pools work, what consumes them, how they are calculated, and where to see them.

The Three Pools

Each pool is tracked and enforced independently. Exhausting one pool does not affect the other two. If your Review / Scan pool is used up, chat and automation continue to work normally.

One Pool, Shared Across Every Surface

The pools are organization-wide and shared. There is no separate allowance per developer, per repository, or per tool. A review started from the CLI, a review triggered automatically on a pull request, and a review submitted through the API all draw from the same Review / Scan pool.

This means usage is counted once, consistently, no matter who on your team triggers the work or which tool they use.

How Limits Are Calculated

• Per seat, then pooled. Each pool has a per-seat allowance defined in your contract. Your organization's limit for that pool is the per-seat allowance multiplied by the number of purchased seats, and the whole team shares the result.
• Monthly. Pools are measured over a calendar billing period and reset at the start of each new period.
• Adding seats raises limits. Because the limit is derived from your seat count, purchasing additional seats increases every pool proportionally. The change applies as soon as the seat count updates.

What Counts as One Unit

A few rules worth knowing:

• Very large reviews count as two jobs. A review whose diff is more than 15,000 changed lines is billed as two Review / Scan jobs, because it costs proportionally more to analyze. A diff of 15,000 changed lines or fewer counts as one job.
• Retries are not double-counted. Codity keys each unit of work to its underlying job. If a job is retried internally, or the same pull request event is delivered twice, it still consumes a single unit.
• Blocked requests are free. If a request is rejected because a pool is exhausted, it does not consume anything.
• Failed work is still counted. A unit is consumed when work is accepted and started. Work that is skipped before it starts, for example a pull request with no reviewable changes, does not consume a unit.
• codity review --full runs several jobs. It performs a review plus scans, and each part draws its own unit from the Review / Scan pool. If the pool runs out partway, the remaining parts are skipped and reported, and the review still returns.

Hard and Soft Caps

Your contract also sets a cap mode, which decides what happens when a pool is fully used:

Your current cap mode is shown on the API Access page.

Where to See Your Usage

Open API Access in the dashboard. The usage panel shows the live state of all three pools for the current billing period:

 ┌──────────────────────────────────────────────────────────┐
 │  your-organization                                       │
 │  cdt_…XXXXXXXX                                           │
 │                                                          │
 │  Billing period        Cap mode          Overage         │
 │  <current month>       <Hard | Soft>     <amount>        │
 │                                                          │
 │  Review & scans                            used / limit  │
 │  ████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   │
 │  <n> remaining                            <amount> overage│
 │                                                          │
 │  Navigation                                used / limit  │
 │  ██████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   │
 │  <n> remaining                            <amount> overage│
 │                                                          │
 │  Automation                                used / limit  │
 │  ███░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   │
 │  <n> remaining                            <amount> overage│
 └──────────────────────────────────────────────────────────┘

For each pool you see:

The panel also lists Recent Jobs, so you can see the work that consumed the pools and its status.

Because the pools are shared, these figures reflect your whole organization's usage across every surface, not just the API key you are looking at. The same totals are available programmatically from the API; see API Overview.

When You Reach a Limit

On a hard cap, Codity tells the user where they are working, and never fails silently:

To restore service before the next billing period, add seats or talk to your account contact about adjusting your contracted limits. On a soft cap, none of the above applies. Work simply continues and overage is recorded.

Frequently Asked Questions

Do unused units roll over? No. Pools are measured per billing period and reset at the start of the next one.

Does one person's usage affect the rest of the team? Yes. The pools are organization-wide, so all usage is drawn from the same shared allowance. The dashboard shows the combined total.

Do read-only actions cost anything? No. Checking usage, polling a job's status, and browsing results in the dashboard are free and never draw from a pool.

What happens to work already running when a limit is reached? Work that has already been accepted continues to completion. Only new requests are affected.