# AI review usage and limits Source: https://docs.cubic.dev/account/ai-review-usage How GitHub PR AI review usage and billing-period limits work. cubic measures GitHub PR AI review usage in **reviewed lines** — the changed lines of code cubic actually reviewed in completed PR reviews. Auto-generated files, binaries, vendored code, and anything matching your ignore patterns are discounted automatically and barely touch your quota. So a 30,000-line PR that's mostly a regenerated lockfile counts as a small fraction of that. ## Paid team capacity Each paid seat adds to a shared reviewed-line pool for your whole team. | Plan | Reviewed lines per seat per billing period | | - | - | | Trial | 20,000 | | Team (paid) | 40,000 | | Pro | 80,000 | | Max | 160,000 | A 5-seat Pro team gets `5 × 80,000 = 400,000` reviewed lines per billing period, pooled across everyone. You can see your current usage, reset date, and a breakdown by review type, base branch, and repository in **[Settings → Usage](https://www.cubic.dev/settings?tab=usage)** when reviewed-line limits apply to your installation. The quota resets with your billing period, not a rolling 30-day window. ## What is not included The reviewed-line meter applies to GitHub PR AI reviews. Other cubic features use separate limits and do not consume this reviewed-line pool: * CLI/local reviews * Codebase reviews and daily scans * Wikis * cubic coding agents ## When you run out If your team uses its full reviewed-line capacity, new GitHub PR AI reviews pause until the next reset or until you add more capacity. Existing comments stay on PRs, and replying to cubic still works. Other features are unaffected by this reviewed-line quota because they have their own limits. Paid workspaces can use [flex capacity](/account/flex-capacity) to keep reviews running automatically after included usage runs out. Flex capacity costs \$20 per 10,000 extra reviewed lines, is billed only as used, and stops at the monthly spend limit you set. ## Tips to reduce usage Use these ideas when you want to lower reviewed-line consumption without changing your plan. Most options live in [AI review settings](https://www.cubic.dev/ai-review) or [`cubic.yaml`](/configure/cubic-yaml). * **[Disable automatic reviews](https://www.cubic.dev/ai-review?tab=setup\&card=ai-review-card-code-review-agent)** for repositories where you only want cubic to review PRs manually. Turn off AI reviews for the repository, or set `reviews.enabled: false` in [`cubic.yaml`](/configure/cubic-yaml). * **[Ignore specific files or directories](https://www.cubic.dev/ai-review?tab=setup\&card=ai-review-card-ignore-patterns)** that do not need AI review. Add file globs under **Ignore files**, or add them to `reviews.ignore.files` in [`cubic.yaml`](/configure/cubic-yaml). * **[Ignore test files and fixtures](https://www.cubic.dev/ai-review?tab=setup\&card=ai-review-card-ignore-patterns)** if your team generates a lot of test code. Choose the repository, open **Ignore files**, and add file path patterns such as `**/*.test.*`, `**/*.spec.*`, `**/__tests__/**`, `tests/**`, `test/**`, or `fixtures/**`. * **[Turn off automatic incremental reviews](https://www.cubic.dev/ai-review?tab=setup\&card=ai-review-card-incremental-reviews)** to review a PR once when it opens instead of re-reviewing every pushed commit, or set `reviews.incremental_commits: false` in [`cubic.yaml`](/configure/cubic-yaml). You can still request an incremental review by commenting `@cubic-dev-ai incremental review`. * **[Use the cubic CLI locally](/ide/cli-review).** CLI and local reviews don't draw from your reviewed-line pool, so running in-progress checks with the cubic CLI keeps your cloud capacity for the PRs that need it. * **[Skip automatic reviews on non-default base branches](https://www.cubic.dev/ai-review?tab=setup\&card=ai-review-card-ignore-pull-request-patterns)** when long-lived branches do not need continuous review, or set `reviews.ignore.base_branches` in [`cubic.yaml`](/configure/cubic-yaml). You can still request a review with `@cubic-dev-ai review` when one is useful. * **Avoid unnecessary full reruns.** Pushing commits triggers incremental reviews when they are enabled. You can also comment `@cubic-dev-ai incremental review` to review only the changes since cubic's last completed review. Incremental reviews count only newly reviewed changes, while `@cubic-dev-ai review this PR` runs a full review and counts reviewed lines again. * **[Use PR label ignores](https://www.cubic.dev/ai-review?tab=setup\&card=ai-review-card-ignore-pull-request-patterns)** for work-in-progress PRs. Add label patterns, or set `reviews.ignore.pr_labels` in [`cubic.yaml`](/configure/cubic-yaml), to suppress automatic reviews, including push-triggered incremental reviews, while still allowing manually requested reviews. For example: ```yaml theme={null} reviews: enabled: true ignore: files: - 'dist/**' - 'generated/**' - '**/*.test.*' - '**/*.spec.*' - '**/__tests__/**' - '*.lock' ``` When a file matches your ignore patterns, cubic skips it during PR review, so it does not spend reviewed-line capacity on that file. ## How to get more * **[Set a flex capacity spend limit](/account/flex-capacity)** to cover overages automatically at \$20 per 10,000 extra reviewed lines. * **[Upgrade to Pro or Max](https://www.cubic.dev/settings?tab=billing)** for a higher per-seat allowance. * **Add seats** in [Settings → Billing](https://www.cubic.dev/settings?tab=billing). Capacity goes up immediately. * **Tighten ignore patterns** in [`cubic.yaml`](/configure/cubic-yaml) for generated or vendored code you don't want reviewed. ## FAQ Usage counts added and deleted lines actually reviewed, including full reruns. Ultrareviews count at 3× the standard rate. For example, a review of 1,000 added and 200 deleted lines uses 1,200 reviewed lines, or 3,600 for an Ultrareview. A later incremental review of 100 new changed lines uses 100 more at the standard rate. Check **Settings → Usage** for a breakdown by review type and repository. Exclude generated files or fixtures with [ignore patterns](/configure/cubic-yaml) to keep them out of reviews. No. Only changed lines actually reviewed count, not the surrounding code cubic reads for context. Caching and learning your codebase do not reduce the reviewed-line count. Incremental reviews reduce usage by reviewing only new changes instead of repeating the full PR review. No. The reviewed-line allowance covers GitHub PR reviews only. Codebase scans, wikis, CLI reviews, and coding agents have separate limits. Full reruns can count the same lines again. Commenting `@cubic-dev-ai review this PR` runs a fresh full review, while `@cubic-dev-ai incremental review` reviews and counts only the changes since cubic's last completed review. Pushing new commits also triggers incremental reviews when they are enabled. No. Reviewed-line usage is based on the changed lines of code cubic reviews, not how many comments cubic leaves. Changing sensitivity can make cubic more or less selective about the issues it reports, but it does not change how much code cubic reviews. To reduce reviewed-line usage, change when reviews run or which files cubic reviews. You can do that with [AI review settings](/ai-review/ai-review-settings) or [`cubic.yaml`](/configure/cubic-yaml). Yes. Add a PR label ignore pattern in [AI review settings](/ai-review/ai-review-settings), or add the label to `reviews.ignore.pr_labels` in [`cubic.yaml`](/configure/cubic-yaml). For example, labels such as `wip` or `skip-review` suppress automatic reviews, including push-triggered incremental reviews, until the label is removed. If you want a review before then, comment `@cubic-dev-ai review` on the PR. No. Only completed reviews count toward your billing-period capacity. If you cancel a review, merge a PR before its review finishes, or cubic hits an error, those reviews don't use any of your quota. Public repositories can use cubic for open-source work at no cost, subject to separate reviewed-line fair-use and abuse-protection limits. These safeguards are designed for unusually large or high-volume usage, not normal OSS maintenance. On paid plans, reviews of public PRs from workspace members count toward the team's reviewed-line allowance. Reviews from external contributors use a separate public allowance and do not consume the team's reviewed lines. Unpaid public repositories use the public fair-use pool instead of the private free-plan review count. If your open-source project is blocked and you think the limit was applied incorrectly, email [contact@cubic.dev](mailto:contact@cubic.dev) with your organisation, repository, and PR link. Your cap recalculates immediately. Adding seats gives you more capacity right away; removing seats lowers it. Flex capacity costs \$20 per 10,000 extra reviewed lines. cubic buys whole blocks only when a review would otherwise be paused, and it never buys a partial block that would charge you without unblocking the review. See [Flex capacity](/account/flex-capacity) for examples and spend-limit behavior. Yes. An Ultrareview is a longer, deeper review using cubic's most capable models, so it counts against your reviewed-line capacity at 3× the standard rate. There is no separate Ultrareview limit — usage shares the same reviewed-lines allowance as normal reviews. Email [contact@cubic.dev](mailto:contact@cubic.dev) with your organisation name and we'll dig in. # Flex capacity Source: https://docs.cubic.dev/account/flex-capacity How cubic bills extra reviewed-line capacity after your included usage runs out. Flex capacity keeps GitHub PR AI reviews running after your workspace uses its included reviewed-line capacity. cubic buys extra reviewed-line capacity, in top-ups of the size you choose, only when a review would otherwise be paused. A monthly spend limit is optional. Flex capacity is available on paid workspaces billed through Stripe. Admins manage it from **Settings → Billing** or **Settings → Usage** by choosing a top-up size and, optionally, a monthly spend limit. ## How flex capacity works Flex capacity turns a reviewed-line usage block into an automatic one-off charge: 1. Your workspace uses its included reviewed-line capacity for the billing period. 2. A new GitHub PR review would otherwise pause because the workspace is over its monthly limit. 3. cubic checks your flex capacity setting and any monthly spend limit. 4. If the needed capacity fits under the limit, or you set no limit, cubic charges the saved payment method immediately. 5. After payment succeeds, cubic adds the extra reviewed-line capacity for the current billing period and continues the review. Flex capacity applies only to GitHub PR AI review usage. CLI/local reviews, codebase scans, daily scans, wikis, and cubic coding agents use separate limits. ## Pricing Flex capacity costs **\$20 per 10,000 extra reviewed lines**. | Item | Amount | | - | - | | Billing unit | 10,000 extra reviewed lines | | Price | \$20 per 10,000 lines | | Top-up sizes | 40,000, 100,000 or 500,000 lines, or any multiple of 10,000 | | Billing timing | Charged immediately when capacity is needed | | Availability | Current billing period only | The price is the same for Team, Pro, and Max workspaces, and the same for monthly and annual subscriptions. Flex capacity is separate from your seat subscription; it appears as a one-off invoice charge when cubic adds capacity. ## Example charges You choose a preferred top-up size in multiples of 10,000 lines. cubic buys enough blocks to cover the current overage, and it never buys a partial block. For a preferred top-up size of 20,000 lines: | Current overage | Preferred top-ups | Charge | Extra capacity granted | | - | - | - | - | | 4,000 reviewed lines | 1 | \$40 | 20,000 reviewed lines | | 15,000 reviewed lines | 1 | \$40 | 20,000 reviewed lines | | 25,000 reviewed lines | 2 | \$80 | 40,000 reviewed lines | If a review is 25,000 lines over the included limit, cubic needs two blocks of 20,000 lines each. If your remaining monthly flex limit is less than the price for a preferred top-up, then cubic will buy the smallest amount that fits under the limit. For example, if your remaining limit is \$30, but your preferred top-up is 20,000 lines for \$40, and the review needs 5,000 lines, cubic will buy a 10,000-line block for \$20. If a review needs 40,000 lines, cubic will buy nothing because the remaining \$30 cannot fund the required 40,000 lines. ## Spend limits Flex capacity has no spend limit by default. Without one, cubic emails workspace admins once flex spend reaches \$200 in a billing period. A monthly spend limit is the most cubic can spend on flex capacity during one billing period. The setting is a hard stop: reviews can continue while the needed flex purchase fits under the limit, and reviews pause once the next needed purchase would exceed the limit. For example, a \$60 monthly spend limit can buy up to 30,000 extra reviewed lines during the current billing period. If your workspace has already spent \$40 and the next review needs 5,000 lines, cubic can buy a smaller 10,000-line top-up for the remaining \$20. If the review needs 15,000 lines, cubic buys nothing because the remaining \$20 cannot fund the required 20,000 lines. Admins can set, change, or remove the spend limit from the **Flex capacity** row in **Settings → Billing**, or from **Settings → Usage**. **Turn off flex** stops future purchases. Extra capacity already bought during the billing period remains available until the period ends. ## Payment behavior Flex capacity is granted only after payment succeeds. If the payment method is declined, cubic does not grant the extra capacity and reviews stay paused at the current limit. Some cards require extra authentication, such as 3D Secure. When that happens, cubic emails workspace admins a link to the installation's Billing settings. The settings page provides the secure Stripe invoice link, and cubic grants the extra capacity after Stripe confirms the payment. A failed flex capacity payment prevents cubic from creating another flex invoice for the same capacity. cubic retries the existing open invoice when another review needs capacity, waiting longer after each declined charge (from one hour up to a day). Workspace admins can pay it sooner from the installation's Billing settings. ## How to turn it on Admins can enable flex capacity from the billing settings: 1. Open **Settings → Billing**. 2. Next to **Flex capacity**, select **Edit**. 3. Choose a top-up size: 40,000, 100,000 or 500,000 lines, or **Custom** for any multiple of 10,000. 4. To cap spending, select **Set a monthly limit**. Without a limit, cubic keeps buying top-ups as reviews need them. 5. Select **Turn on flex**, or **Save** if flex is already on. On **Settings → Usage**, **Add flex capacity** on the Flex row opens the same dialog. While a flex payment is pending or has failed, admins see **View payment** instead, which opens **Settings → Billing** so they can complete the payment. Members see a note to ask an admin. The setting takes effect for future reviews. If reviews are already paused because your workspace is over the reviewed-line limit, turning flex on, or raising or removing the limit, lets cubic buy the needed extra capacity and resume reviews. ## How to monitor usage Open **Settings → Usage** to see your reviewed-line usage and reset date for the current billing period, split into included lines and flex capacity. While flex capacity is on, Usage and Billing both show any monthly limit and this period's flex spend. Flex capacity resets with your billing period. Unused extra capacity does not roll over. ## FAQ No. Seats still determine your included reviewed-line allowance and who has paid AI review access. Flex capacity covers temporary overages after your included reviewed-line capacity runs out. No. cubic charges flex capacity only when a review needs extra capacity and, if you set a monthly spend limit, the purchase fits under it. No. The spend limit is a hard cap. If the next required purchase would exceed the limit, cubic buys nothing and reviews stay paused until you raise or remove the limit or the billing period resets. cubic buys your preferred top-up size in 10,000-line units. It can combine multiple preferred top-ups when the current overage needs more capacity. cubic stops making future flex capacity purchases. Extra capacity already paid for during the current billing period remains available until the period resets. Your included reviewed-line allowance resets, flex spend returns to \$0 for the new period, and any unused extra flex capacity from the previous period expires. Flex capacity applies to your paid workspace's GitHub PR AI review usage. Public repositories may also be subject to separate fair-use and abuse-protection limits, which flex capacity does not override. # Members API Source: https://docs.cubic.dev/account/members-api List organization members and manage their seats and roles from your own tools. The Members API lets your scripts and tools manage cubic members. You can list your organizations and their members, read one member, turn a seat on or off, and change a role. ## Get an API key The Members API accepts two kinds of key. | Key | Starts with | Who creates it | Acts as | | - | - | - | - | | Personal key | `cbk_` | Any cubic user | You, with your own cubic access. | | Organization key | `cok_` | An organization admin | One organization, with read or admin access to its members. | Use an organization key for automation that should not depend on one person, such as a sync from your identity provider. It keeps working when the admin who created it leaves. ### Personal key Go to [Settings > API, CLI & MCP > cubic API](https://www.cubic.dev/settings?tab=api-cli\&integration=api). In the **Members API** card, click **Generate API key**. Keys start with `cbk_`, and cubic only shows the full value once. Save the key in your secret manager or local environment. This is the same personal key that the [cubic MCP server](/ide/mcp-server), the [cubic CLI](/ide/cli-review), and the [Analytics API](/analytics/api) use, and regenerating it replaces the key for all of them. The key acts with your own cubic access. You only see organizations you can already view in cubic, and changes need an organization admin. See [Roles and permissions](/account/roles-and-permissions). ### Organization key Only organization admins can create and revoke organization keys. Go to [Settings > API, CLI & MCP](https://www.cubic.dev/settings?tab=api-cli) and pick the organization next to **Organization API keys**. Click **Create API key** and name the key after the script or integration that uses it. Choose **Read** to list organizations and members, or **Admin** to also turn seats on or off and change roles. Keys start with `cok_`, and cubic only shows the full value once. Save the key in your secret manager. An organization key belongs to the organization, not to the admin who created it. It reads members of that one organization. A key with **Admin** access also updates them with an admin's permissions, and a **Read** key gets `403 admin_required` on `PATCH`. No key can change billing. Any admin can revoke a key in **Settings > API, CLI & MCP**, and requests with a revoked key fail from then on. Uninstalling cubic from the organization deletes its keys. ## Endpoints | Method | Endpoint | Description | | - | - | - | | `GET` | `/api/v1/organizations` | [List the organizations you can view](/api-reference/members/list-organizations). | | `GET` | `/api/v1/organizations/{org}/members` | [List an organization's members](/api-reference/members/list-members). | | `GET` | `/api/v1/organizations/{org}/members/{githubUserId}` | [Read one member](/api-reference/members/get-member). | | `PATCH` | `/api/v1/organizations/{org}/members/{githubUserId}` | [Turn a seat on or off, or change a role](/api-reference/members/update-member). | The base URL is `https://www.cubic.dev`. `{org}` is the GitHub organization login, such as `acme`. Each organization in the list includes `githubAccountId`, GitHub's numeric account ID, and flags such as `canManageSeats` that show what your access allows. An organization key lists only its own organization. Each endpoint's reference page includes request fields, response schemas, and code examples. Enter an API key in the playground to try a request with that key's access. The [OpenAPI document](https://www.cubic.dev/api/v1/openapi.json) powers the API reference. You can also generate a client from it. ### Authentication Send a personal or organization key in the `Authorization` header as a bearer token. ```http theme={null} Authorization: Bearer cbk_your_api_key ``` The same keys work with the [Analytics API](/analytics/api). Analytics API keys that start with `cak_` do not work with the Members API. ### Example requests ```bash cURL theme={null} # List members who have a seat curl --request GET \ --url 'https://www.cubic.dev/api/v1/organizations/acme/members?seat=true&limit=100' \ --header 'Authorization: Bearer cbk_your_api_key' # Turn off a member's seat curl --request PATCH \ --url 'https://www.cubic.dev/api/v1/organizations/acme/members/583231' \ --header 'Authorization: Bearer cbk_your_api_key' \ --header 'Content-Type: application/json' \ --data '{"seat": false, "expectedSeat": true}' ``` ```javascript JavaScript theme={null} const memberUrl = 'https://www.cubic.dev/api/v1/organizations/acme/members/583231'; const headers = { 'Authorization': `Bearer ${process.env.CUBIC_API_KEY}`, 'Content-Type': 'application/json', }; const memberResponse = await fetch(memberUrl, { headers }); const member = await memberResponse.json(); if (!memberResponse.ok) { throw new Error(`${member.error.code}: ${member.error.message}`); } const response = await fetch(memberUrl, { method: 'PATCH', headers, body: JSON.stringify({ seat: false, expectedSeat: member.seat }), }); const result = await response.json(); if (!response.ok) { throw new Error(`${result.error.code}: ${result.error.message}`); } ``` ## Members ```json theme={null} { "githubUserId": "583231", "githubLogin": "octocat", "workEmail": "octocat@acme.com", "role": "member", "seat": true, "isBot": false } ``` | Field | Description | | - | - | | `githubUserId` | GitHub's numeric user ID, as a string. It never changes, so use it as the member's key. | | `githubLogin` | GitHub login, or `null`. Logins can change. | | `workEmail` | Work email, or `null`. An admin sets it in cubic, or cubic syncs it from GitHub SAML or SCIM. cubic never returns a personal email here. | | `role` | `admin`, `member`, or `viewer`. | | `seat` | Whether the member has a seat. | | `isBot` | Whether the account is a bot. Bots do not consume paid seat capacity and cannot be admins. | A seat is a paid license for cubic reviews. Turning a seat off does not remove the person's access to cubic. To remove someone, remove them from the GitHub organization. cubic removes their access when GitHub notifies it. See [Roles and permissions](/account/roles-and-permissions) for what each role can do. The member list holds the people cubic tracks for the organization, including members with access to a repository cubic reviews and pull request authors. On paid plans, cubic refreshes it from GitHub every day. ### Filter the member list | Parameter | Description | | - | - | | `search` | Match part of a GitHub login, ignoring case. | | `role` | Only members with this role. | | `seat` | `true` for members with a seat, `false` for members without one. | The list also takes `cursor` and `limit`, described in [Pagination](#pagination). An unknown parameter returns `400 invalid_request`, so a mistyped filter never lists everyone. ## Update a member Send the fields you want to change, each with the value from your latest read. | Field | Description | | - | - | | `seat` | `true` turns the seat on. `false` turns it off. Send it with `expectedSeat`. | | `expectedSeat` | The `seat` value from your latest read. | | `role` | `admin`, `member`, or `viewer`. Send it with `expectedRole`. | | `expectedRole` | The `role` value from your latest read. | If the member changed since your read, the request fails with `409 member_state_changed` and changes nothing. Read the member again, then retry. A request that asks for the member's current state succeeds with `"changed": false`, so retrying a completed request is safe. You can change a seat and role in the same request. Both changes are committed together, or the request fails without changing either field. For example, to turn off a member's seat and change their role to viewer, send this body with `PATCH`: ```json theme={null} { "seat": false, "expectedSeat": true, "role": "viewer", "expectedRole": "member" } ``` The response holds the member's `before` and `after` state, `changed`, and `availableSeats`, the number of paid seats still free after the change. `purchasedQuantityChanged` is always `false`: the API assigns existing capacity and never changes the number of seats you buy. ```json theme={null} { "githubUserId": "583231", "before": { "seat": true, "role": "member" }, "after": { "seat": false, "role": "viewer" }, "changed": true, "availableSeats": 1, "purchasedQuantityChanged": false } ``` Updates need an organization admin or an organization key with **Admin** access, and an active Team, Pro, or Max subscription billed through cubic. Manage seats for Vercel Marketplace subscriptions in cubic. The API never buys seats. When every paid seat is in use, turning on a human member's seat fails with `seat_capacity_exceeded`. Add seats in [Settings → Billing](https://www.cubic.dev/settings?tab=billing) first. ## Pagination List endpoints return one page and a `nextCursor`. To get the next page, send `nextCursor` back as `cursor`. `nextCursor` is `null` on the last page. Set the page size with `limit`, from 1 to 100. The default is 20. Copy `nextCursor` unchanged. The members endpoint does not check whether a cursor came from an earlier page, so an edited or unrecognized cursor can return an empty page instead of an error. The organizations endpoint returns `400 invalid_cursor` for invalid cursor numbers. To fetch every member, continue until `nextCursor` is `null`: ```javascript theme={null} const members = []; let cursor = null; do { const url = new URL('https://www.cubic.dev/api/v1/organizations/acme/members'); url.searchParams.set('limit', '100'); if (cursor !== null) { url.searchParams.set('cursor', cursor); } const response = await fetch(url, { headers: { Authorization: `Bearer ${process.env.CUBIC_API_KEY}` }, }); const page = await response.json(); if (!response.ok) { throw new Error(`${page.error.code}: ${page.error.message}`); } members.push(...page.members); cursor = page.nextCursor; } while (cursor !== null); ``` ## Rate limits The Members API allows 1,000 requests per 15 minutes for each person's personal key. An organization's keys share a separate limit of 1,000 requests per 15 minutes. Regenerating a personal key or creating more organization keys does not reset or raise a limit. Analytics API requests with these keys count toward the same limits. Every response after authentication includes these headers. | Header | Description | | - | - | | `X-RateLimit-Limit` | Requests allowed per 15-minute window. | | `X-RateLimit-Remaining` | Requests left in the current window. | | `X-RateLimit-Reset` | When the window resets, in Unix epoch seconds. | When you run out, cubic answers `429 rate_limited` with a `Retry-After` header in seconds. If cubic cannot check the limit, it answers `503 rate_limiter_unavailable` with `Retry-After: 30` and no `X-RateLimit-*` headers. In both cases, wait for `Retry-After` before you retry. ## Errors Every error uses the same envelope. ```json theme={null} { "error": { "code": "member_state_changed", "message": "The member changed since you read it. Fetch the member again and retry.", "retriable": false } } ``` Branch on `code`, because messages can change. `retriable` says whether the same request can succeed if you send it again. Some errors include a `correlationId`. Quote it when you contact support. Validation errors include `details`, a list of `path` and `message` pairs for the fields that failed. The reference pages describe response schemas. The codes below explain errors your scripts can handle. | Status | Code | When it happens | | - | - | - | | `400` | `invalid_request` | A path, query, or body value is invalid, or a query parameter is unknown. | | `400` | `invalid_arguments` | The body changes neither `seat` nor `role`, sends a value without its expected value, or sends an expected value without its value. | | `400` | `invalid_cursor` | An organization-list cursor is not an integer from 0 to 2,147,483,647. Member lists do not return this error. | | `401` | `unauthorized` | The bearer token is missing, or the account or organization cannot use cubic. | | `401` | `invalid_api_key` | The key is invalid, expired, or revoked, or it is not a personal `cbk_` or organization `cok_` key. | | `403` | `access_denied` | Your cubic access does not cover this organization. | | `403` | `admin_required` | Updates need an organization admin, or an organization key with admin access. | | `403` | `paid_plan_required` | The organization is not on a paid plan. | | `403` | `subscription_not_active` | The subscription is not active, or its payment collection is paused. | | `403` | `unsupported_subscription` | The subscription is not a standard Team, Pro, or Max seat plan. Manage it in cubic. | | `403` | `billing_provider_not_supported` | The organization is billed through Vercel. Manage its seats in cubic. | | `404` | `organization_not_found` | The organization does not exist in cubic, or you cannot access it. | | `404` | `member_not_found` | No member of the organization has this GitHub user ID. | | `409` | `member_state_changed` | The member changed since your read. | | `409` | `seat_capacity_exceeded` | Every paid seat is in use. | | `409` | `last_admin_required` | The change would remove the last active admin. | | `409` | `billing_state_changed` | Billing changed while the request ran. Send the request again. | | `422` | `self_demotion_not_allowed` | You cannot remove your own admin role. | | `422` | `bot_admin_not_allowed` | Bots cannot be admins. | | `429` | `rate_limited` | You used every request in this window. | | `500` | `internal_error` | Something failed unexpectedly. Retry the request. | | `503` | `unavailable` | cubic could not verify the key. Retry shortly. | | `503` | `rate_limiter_unavailable` | cubic could not check the rate limit. Retry shortly. | # Privacy & security Source: https://docs.cubic.dev/account/privacy-security How cubic keeps your code and data safe cubic is built by developers, for developers. We understand that your source code is your most valuable asset, so we designed our systems with security and privacy as a first-principle—not an afterthought. ## Our guiding principles * **Encryption everywhere** – All data is encrypted **in transit** (TLS 1.2+) and **at rest** (AES-256), including database records and object storage. * **Least-privilege access** – The cubic GitHub App requests the minimum scope required to perform reviews. No additional write-or-admin permissions are granted unless they are strictly necessary (see below). * **Transparent operations** – We publish this page so that every customer—current or prospective—can understand exactly how we treat their data. If you have questions, email us any time at [contact@cubic.dev](mailto:contact@cubic.dev). Our data handling practices are further detailed in our [Privacy Policy](https://cubic.dev/privacy) and use of the service is governed by our [Terms of Service](https://cubic.dev/terms). * **No third-party model training on Customer Code** – Our AI model providers (e.g., OpenAI, Anthropic) contractually commit that code snippets and metadata passed through their APIs are **not** used to train or improve their underlying models. ## SOC 2 compliant cubic is **SOC 2 Type 1** compliant, demonstrating our commitment to security and trust for our customers. We maintain comprehensive controls for change management, access management, and vulnerability management. ## Permissions requested by the cubic GitHub App Granting the following scopes allows cubic to read pull-requests, leave review comments, and update PR status checks. | Scope | Access | Why we need it | | - | - | - | | **Administration** | Read-only | Access repository settings and organization information | | **Actions** | Read & write | Read CI results on pull requests and fixes | | **Checks** | Read & write | Surface pass/fail status checks for AI review completion | | **Code** | Read & write | Read: Fetch PR diffs and context for reviews. Write: Enable [Background Agents](/ai-review/coding-agents) to push fix commits to your PR branch or create fix PRs (never pushes directly to main or protected branches—all fixes go through PR review) | | **Commit statuses** | Read-only | Monitor and display commit status in the cubic UI | | **Deployments** | Read-only | Access deployment information for integration purposes | | **Issues** | Read & write | Create issues for tracking review findings when configured (optional feature) | | **Metadata** | Read-only | Display repository information inside the cubic UI | | **Pull requests** | Read & write | Post AI-generated review comments, resolve threads when feedback is addressed, and create fix PRs or update PR branches via [Background Agents](/ai-review/coding-agents) | | **Workflows** | Read & write | Let [Background Agents](/ai-review/coding-agents) push fixes that change workflow files | > **Note:** You can install the cubic App on a single repository or an entire organization. Access is scoped to the repositories you select during installation, and can be modified at any time from GitHub's "Installed Apps" settings page. > > **Write permissions are primarily needed for the Background Agents feature**, which can push commits to your PR branch or create separate fix PRs—never direct commits to your main branch. Background Agents generate fixes in an isolated sandbox, ensuring all changes go through your standard PR review process. **For extra peace of mind:** While cubic never pushes directly to your main branch, you can enhance security by enabling branch protection rules. Configure [branch protection rules](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule) on your main/default branch to prevent direct commits and require pull request reviews before merging. This ensures all changes—including those from cubic's Background Agents—must go through your standard review process. ## How AI code review works 1. **Event trigger** – Whenever a pull request is opened or updated, GitHub sends cubic a webhook describing the event. 2. **Isolated sandbox** – A new isolated container is launched. 3. **Analysis** – The pull-request diff and *only* the necessary context needed for reviewing the PR are processed by AI models. 4. **Comment publication** – The generated review comments are posted back to the PR via the GitHub API. ## AI subprocessors cubic uses best-in-class large-language models hosted by vetted providers. Our agreements with these subprocessors explicitly prohibit using Customer Code to train their own models. Code is sent only to perform the requested analysis, and all requests are sent over encrypted channels. Our current subprocessors are listed in our [Trust Center](https://trust.cubic.dev/?tab=subprocessors). If your organization prefers to *completely* block AI features, please contact us and we can disable them for your workspace. ## Reporting a security issue If you believe you have found a vulnerability in cubic, please email our security team at [contact@cubic.dev](mailto:contact@cubic.dev) with the subject line "Security Vulnerability". We investigate all reports promptly and appreciate the efforts of the security community. # Referral program Source: https://docs.cubic.dev/account/referral-program Earn up to $2,000 for every team you refer to cubic. Invite teams to cubic and earn rewards that scale with their team size—up to \$2,000 per referral. Your referred teams get an exclusive extended 14-day trial period to fully explore cubic. ## How it works Referring teams to cubic is simple and rewarding: 1. **Share your unique link** - Every cubic user gets a personalized referral link 2. **Teams sign up** - New teams use your link to create their cubic account 3. **Earn rewards** - Get rewards when referred teams upgrade to paid plans There's no limit to how many teams you can refer, and rewards are automatically processed when teams convert to paid subscriptions. ## Getting your referral link Access your unique referral link in seconds: 1. Go to [cubic.dev/refer](https://www.cubic.dev/refer) while signed in to your cubic account 2. Click **Refer and earn** in the top right 3. Copy your personalized link and share it via email, Slack, or social media ## Reward structure Earn rewards based on the team size at conversion: | Team Size | Your Reward | | - | - | | 1 seat | \$30 | | 2 seats | \$60 | | 3 seats | \$90 | | 4 seats | \$120 | | 5 seats | \$150 | | 6-9 seats | \$30 × seats | | 10-15 seats | \$300 | | 16-19 seats | \$500 | | 20-30 seats | \$750 | | 31-50 seats | \$1,000 | | 51-75 seats | \$1,500 | | 76+ seats | \$2,000 | **Example:** If you refer a team that subscribes with 8 seats, you'll receive \$240. Rewards are calculated based on the subscription size when the team first upgrades to a paid plan. ## Benefits for referred teams Teams you refer receive an exclusive extended trial period: ### Extended 14-day trial While standard trials last 7 days, teams that sign up through referral links enjoy a full 14-day trial period, giving them an extra week to experience cubic's full capabilities. ### Full platform access During their extended trial, referred teams get AI code reviews and complete access to all cubic features, giving them ample time to evaluate cubic for their team. ## Frequently asked questions ### Who can participate? Every cubic user with an active account can refer new teams. ### Can I refer my own team or organization? For fairness, you cannot earn rewards for referring teams within your own GitHub organization. ### When do I receive my reward? Rewards are processed after a referred team makes their first payment for a cubic subscription. ### Is there a limit on referrals? No! You can refer as many teams as you'd like. Each successful referral that converts to a paid plan earns you a reward based on their team size. ### What if a referred team changes their subscription size? Your reward is calculated based on the team's subscription size at the time of their first payment. Later changes don't affect your reward amount. ### Can referred teams use other promotions? The extended 14-day trial is automatically applied to all referred signups and cannot be combined with other trial extensions or promotional offers. ### What happens if a referred team cancels? Once you've received your reward for a successful referral, it's yours to keep—even if the team later cancels their subscription. ## Start referring today Ready to earn rewards while helping other teams discover cubic?
Get your referral link
Questions about the referral program? Contact us at [contact@cubic.dev](mailto:contact@cubic.dev). # Roles and permissions Source: https://docs.cubic.dev/account/roles-and-permissions Manage team roles and permissions in cubic cubic uses a role-based access control system to manage who can make changes to your team's subscription and settings. Every team member has one of three roles: | Role | Best for | What they can do | | - | - | - | | **Admin** | Workspace owners, engineering managers, and operations owners | Manage seats, roles, billing, integrations, repository settings, and AI review settings. | | **Member** | Engineers and teammates who need to configure cubic day to day | Use cubic's full product surface and edit non-billing settings, including AI review behavior, repository settings, integrations, and scan settings. | | **Viewer** | Stakeholders who need visibility without configuration access | View team information, settings, review surfaces, analytics, and subscription status without changing configuration. | ## Permissions matrix | Permission | Admin | Member | Viewer | | - | - | - | - | | Use PR review, analytics, and other non-settings surfaces | ✅ Yes | ✅ Yes | ✅ Yes | | View team members, role assignments, subscription status, and settings | ✅ Yes | ✅ Yes | ✅ Yes | | Configure AI review behavior and repository settings | ✅ Yes | ✅ Yes | ❌ No | | Manage integrations and linked repositories | ✅ Yes | ✅ Yes | ❌ No | | Configure codebase scan settings and scan automation | ✅ Yes | ✅ Yes | ❌ No | | Manage seat assignments | ✅ Yes | ❌ No | ❌ No | | Change user roles | ✅ Yes | ❌ No | ❌ No | | Configure auto-assign and usage seat automation | ✅ Yes | ❌ No | ❌ No | | Manage billing, plans, and subscription controls | ✅ Yes | ❌ No | ❌ No | | Promote bot accounts to admin | ❌ No | ❌ No | ❌ No | ## Seats and roles Seats and roles are related, but they control different things. * **Seats** control which GitHub users are assigned cubic access and how usage is counted for billing. * **Roles** control what a seated user can change inside cubic. Bot rows can be enabled so bot-authored PRs receive AI reviews without adding a paid developer seat. Those reviews still use the team's normal reviewed-line allowance. Members and viewers can both use cubic surfaces available to their seat. The difference is configuration access: members can change non-billing workspace and repository settings, while viewers can only read them. Repository and PR visibility can still depend on GitHub repository access. If someone cannot see a specific repository or PR, confirm that they have access to the repository in GitHub and that cubic has access to that repository. ## How to become an admin There are three ways to become a cubic admin: 1. **Install the cubic GitHub app.** When you install cubic for your GitHub organization, you automatically become an admin. 2. **Be a GitHub organization admin.** GitHub organization admins automatically become cubic admins when the app is installed. 3. **Get promoted by an existing admin.** Any current admin can promote you through [Members settings](https://www.cubic.dev/settings?tab=members). At least one admin is required for every team. Admins cannot remove their own admin role, and cubic prevents changes that would leave the team without an active human admin. Bot accounts cannot be admins. The default role for new seats is **Member** unless the user qualifies for admin during setup. ## Admin role Admins have full control over team management and can: * **Manage seat assignments:** Add or remove cubic seats for team members * **Manage roles:** Change members between admin, member, and viewer roles (note: bot accounts cannot be admins) * **Configure workspace settings:** Change AI review settings, repository settings, integrations, scan settings, and billing automation * **Configure auto-assign:** Give a seat to developers who join the GitHub organization or open their first PR, and remove seats when members leave the GitHub organization * **Manage billing:** Update plans, seats, and subscription controls ## Member role Members can use cubic's full feature set and edit non-billing settings: * **Full platform access:** Use all cubic features including AI reviews, analytics, and PR management * **Manage workspace settings:** Configure AI review behavior, repository settings, integrations, scan settings, and other non-billing team settings * **View billing status:** See subscription status and billing-related information without changing billing details * **No seat, role, or billing management:** Cannot assign/remove seats, change user roles, or manage billing and subscription controls ## Viewer role Viewers can use cubic's review and analytics surfaces, but they cannot change cubic settings: * **View team information:** See team members, role assignments, subscription status, and settings * **Use review surfaces:** Access PR review, analytics, and other non-settings views available to their seat * **No configuration changes:** Cannot change AI review settings, repository settings, integrations, seats, roles, or billing controls ## How to manage user roles Only admins can change user roles. To promote or demote a user: 1. Navigate to [Settings → Members](https://www.cubic.dev/settings?tab=members) 2. Find the team member in the list, or search for them with **Search people** 3. Click the row menu (⋯) and choose **Change role** 4. Select the new role: Admin, Member, or Viewer 5. The change takes effect immediately Only admins can see and use seat and role management options. Members and viewers can view the team list, but they cannot change seats or roles. ### Manage roles through the API Use the [Members API](/account/members-api) to list members and update their seats and roles from your own scripts. With your personal API key, the API uses the same role permissions as the app. Admins create organization API keys in **Settings → API, CLI & MCP**, with read or admin access. A read key can read members, and an admin key can also update their seats and roles like an admin. Each key works only in its own organization and cannot change billing or the subscription. Updates need an organization admin or an organization key with admin access, and an active Team, Pro, or Max subscription billed through cubic. ## FAQ Check your role in **Settings → Members** for the selected GitHub organization. Billing requires the **Admin** role in cubic. GitHub organization admins receive that role during installation, but later role changes are managed in cubic. Ask an existing cubic admin to promote you. If you installed the app and have no admin access, contact [support](/account/support) with your GitHub username and organization. Not automatically. Your personal GitHub installation and an organization's installation are separate. Check the selected organization and its subscription in **Settings → Billing**. Contact [support](/account/support) if you need help moving a subscription to the right workspace. ## Troubleshooting ### I need someone to edit settings, but not billing Give them the **Member** role. Members can edit non-billing settings, but they cannot manage seats, roles, or billing. ### A user can view settings but cannot save changes Check their role. Viewers can read settings but cannot change AI review settings, repository settings, integrations, seats, roles, or billing controls. ### I cannot demote myself from admin cubic prevents admins from removing their own admin role. Ask another admin to change your role after confirming that the team will still have at least one admin. ### I cannot remove or demote the last admin Every team needs at least one active human admin. Add or promote another admin first, then change the original admin's role or seat. ### I cannot make a bot an admin Bot accounts cannot be admins. Assign bot seats a non-admin role instead. # Subscription Source: https://docs.cubic.dev/account/subscription Free and paid cubic plans. Start with a 7-day free trial, with no credit card required. Everyone on your team is enabled by default during the trial. Choosing a paid plan at checkout starts billing immediately. After the trial, continue on the free plan or upgrade to a paid plan. ## Free plan The free plan includes 20 AI reviews per month, shared across repositories in your GitHub organization. The quota resets on the 1st of each month. Review comments show how many reviews remain. ## Paid subscriptions For paid AI review access, cubic's subscription cost is determined by the number of developer seats you choose to activate. Each active seat corresponds to a unique GitHub user within your organization. AI review usage on paid plans is measured in reviewed lines, with an allowance per paid seat that is pooled across your team. * **Seat-based billing:** You are billed based on the number of *active* seats you assign to your team members (GitHub users). * **Flexible seat management:** You can manage seat assignments at any time, both during your free trial and after it ends. * **Customizable checkout:** When you purchase a subscription, you select the exact number of seats you need. * **Ultrareview:** Paid and trial plans include Ultrareview for high-risk or complex PRs. Ultrareviews count toward your team's reviewed-lines allowance at 3× the standard rate. * **Seat and billing management:** Assign seats in [Settings → Members](https://www.cubic.dev/settings?tab=members). Change your plan, seat count, and payment details in [Settings → Billing](https://www.cubic.dev/settings?tab=billing). Settings > Billing with the Pro plan, 5 seats, flex capacity, the payment method, and one paid invoice ### Seat scope across organizations Seat assignments are scoped to the selected GitHub organization. If your company uses cubic in multiple GitHub organizations, assigning a seat in one organization does not automatically assign that user a seat in another organization. The seat summary in **Settings → Members** applies to the selected organization. For example, `86 of 155 paid seats in use` means that organization has 86 active developer seats out of 155 paid seats. Other linked organizations do not consume that organization's available seats. ### Usage and flex capacity See [AI review usage and limits](/account/ai-review-usage) for what counts toward your allowance. Other features, such as local reviews and coding agents, have separate limits. Enable [flex capacity](/account/flex-capacity) on a paid plan to buy extra reviewed lines when the included allowance runs out. An admin sets the monthly spend limit in **Settings → Billing**. ### Assigning seats To manage seats as an admin, go to **Settings → Members**: * Turn on a developer's **Seat** switch to assign a seat, or turn it off to unassign one. cubic asks you to confirm each change. * When every paid seat is in use, turning a seat on buys another seat, prorated. If more people already have seats than you pay for, it buys enough seats to cover them too. cubic shows the price before you confirm. * If the card is declined or needs another step, such as 3-D Secure, the seat stays off until the payment goes through. See [Seats waiting for payment](#seats-waiting-for-payment). * Turning a seat off does not lower your bill. You keep paying for your seat count until you lower it with **Change** on the seats row in **Settings → Billing**. Settings > Members with 5 paid seats at $99 each, a Search people box, and members with their role, PRs, lines, and seat switch With Vercel billing, these switches only assign seats you've already bought. Add or remove paid seats in your Vercel dashboard. To manage seats from your own scripts, use the [Members API](/account/members-api). With an active Team, Pro, or Max subscription billed through cubic, an organization admin or an organization API key can enable or disable existing seats and change roles. The API uses capacity you've already purchased and never buys more seats. Members and viewers cannot change seats. See [Roles and permissions](/account/roles-and-permissions) for the full permission list. To set a work email for the selected organization, open **Settings → Members**, open the **⋯** menu on your row, and choose **Edit notification email**. Weekly summaries, trial emails, and codebase scan completion emails use this address; your GitHub email stays the same. ### Automatic seat management Turn on **Give new developers a seat automatically** in **Settings → Members** to give a seat to each developer who joins your GitHub organization or opens their first PR, and to remove seats when members leave. When every paid seat is in use, cubic buys another seat, prorated. If that payment fails, the developer [waits for a seat payment](#seats-waiting-for-payment). When someone with a seat leaves your GitHub organization, cubic also lowers your paid seat count, unlike turning a seat off yourself. These changes affect billing. With Vercel billing, a developer's first PR doesn't give them a seat. An admin turns their **Seat** switch on, and you add paid seats in your Vercel dashboard. Existing manual assignments remain. For example, if 3 of 10 developers have seats, turning it on gives a seat to the next new developer who opens a PR, bringing the assigned total to 4. It does not assign the other existing members. ### Seats waiting for payment When cubic buys a seat with a card and the card is declined or needs another step, such as 3-D Secure, the seat stays off until the payment goes through. In **Settings → Members**, the developer shows **Waiting for payment**, and a message above the list says how many developers are waiting. An organization admin adds seats for everyone waiting in the billing account from that message, including developers in linked organizations. The number of seats being added can exceed the number waiting in the selected organization. **Add seat** (or **Add 2 seats**, for example) charges the card on file the prorated amount shown. When the purchase already has an open invoice and a payment link is available, **Pay the invoice** opens it, so you can complete 3-D Secure or pay with another card. If no payment link is available, pay the open invoice under **Invoices** in **Settings → Billing**. Waiting developers get their seats as soon as the payment goes through. While anyone waits, cubic buys no more seats on its own, so a declined card is charged once. Developers who join or open their first PR in the meantime wait too. Plan changes wait until the open invoice is paid. On a card subscription without add-ons, adding a seat beyond your paid ones with a **Seat** switch waits too. cubic skips reviews of private-repository PRs from developers who are waiting, and refuses their ultrareviews in any repository. Paying doesn't start them. After the payment, comment `@cubic-dev-ai review` on a PR to review it, or ask for an ultrareview again. If an automatically billed subscription is past due, no seats can be bought until its open invoice is paid. Pay it under **Invoices** in **Settings → Billing**. ## Bot seat management cubic creates a separate bot row when a recognized bot, such as `devin-ai-integration[bot]`, first opens a PR. Bot reviews are disabled by default; an admin can turn on **Review PRs** for a bot in the bots group at the bottom of **Settings → Members**. When a bot with reviews turned off opens PRs, a card on that page suggests turning them on. Enabled bots do not require paid developer seats. Their reviews consume the team's shared reviewed-line allowance. ## Frequently asked questions Pro and Max require a seat for each active developer in the installation, including developers whose seat toggle is off. Active means opening at least 15 PRs in the last 30 days. Bots are excluded. This minimum applies because codebase scans on Pro and Max cover the whole repository. Team does not have this activity-based minimum. No. Everyone is enabled during the trial so your team can try cubic. Before upgrading, go to **Settings → Members** and turn off the **Seat** switch for users who do not need seats. Choose your paid seat count at checkout. Pro and Max still require enough seats to cover the active-developer minimum. Check that you're viewing the GitHub organization linked to your cubic integration in Vercel. A subscription linked to your personal GitHub installation does not automatically cover a separate organization. If the wrong installation is linked, contact [support](/account/support) with the organization name and your Vercel subscription details so we can help correct the connection. Yes. We offer an annual subscription at a 20% discount off the monthly rate. Select "12 months" on the checkout page, and the discount will apply automatically. You can enter your coupon or promo code on the subscription checkout screen: Screenshot showing the promo code field on the checkout page Yes. In [**Settings → Billing**](https://www.cubic.dev/settings?tab=billing), select **Cancel plan** at the bottom of the page. Your plan stays active until the end of the current billing period, and you won't be billed again. You can undo it from the same page until then. If a card payment has failed, cancelling ends the plan right away and voids the plan's unpaid invoices. Unpaid flex top-ups stay due. If you pay through Vercel, cancel in Vercel instead. To change your seat count after your subscription has started, go to [**Settings → Billing**](https://www.cubic.dev/settings?tab=billing) and click **Change** on the seats row. Prorated charges or credits will be applied based on your changes. We currently accept all major credit cards (Visa, MasterCard, American Express) and PayPal. For enterprise customers, we also support ACH bank transfers. Contact support to set them up. Nonprofits and schools can receive a 50% discount. Please [contact support](mailto:contact@cubic.dev?subject=Nonprofit%20Discount) to verify your eligibility. Yes. Public repositories on the free plan use a separate public fair-use allowance. On paid plans, reviews of public PRs from workspace members count toward the team's reviewed-line allowance; reviews from external contributors do not. See [public-repository usage](/account/ai-review-usage#faq) for details. Cancelling a subscription, disconnecting GitHub, and deleting your account are separate actions. See the [Support FAQ](/account/support#faq) for each one. For billing questions, [contact support](/account/support). # Support Source: https://docs.cubic.dev/account/support Contact cubic support for help, questions, and feedback. Email [contact@cubic.dev](mailto:contact@cubic.dev) for help or to share feedback. ## FAQ Go to [**Settings → Billing**](https://www.cubic.dev/settings?tab=billing) and select **Cancel plan**. For subscriptions purchased through Vercel, cancel in Vercel. Cancelling a subscription does not delete your cubic account. In GitHub, open the settings for the account or organization where you installed cubic. Under **Installed GitHub Apps**, select cubic and configure its repository access, or uninstall it to disconnect the installation. Before you uninstall, cancel your plan in **Settings → Billing**, or in Vercel if you pay through Vercel. After uninstalling, the organization's billing page is no longer available. Email [contact@cubic.dev](mailto:contact@cubic.dev) from your account email address with your GitHub username and organization name. Tell us whether you want to delete your personal account or the organization's cubic workspace so we can confirm the scope of the request. # Verify your GitHub email Source: https://docs.cubic.dev/account/verify-github-email Steps to verify your primary GitHub email address so you can sign in to cubic. If you see an **“unverified\_email”** error when signing in with GitHub, it means your primary GitHub address hasn’t been verified yet. To verify your email: 1. Open [GitHub](https://github.com) and go to **Settings › Emails**. 2. Click **Resend verification** next to your primary address. 3. Follow the link in the email from GitHub to complete verification. 4. Return to cubic and sign in again. Having trouble? Reach out at [contact@cubic.dev](mailto:contact@cubic.dev). # AI review settings Source: https://docs.cubic.dev/ai-review/ai-review-settings Configure repository-level and organization-level AI review behavior in cubic. Within your project's [settings](https://cubic.dev/settings), the **AI review** section offers controls to tailor AI review behavior. AI review settings ## Configurable options AI review settings can be configured for individual repositories or globally for all repositories in an installation. To update settings for all repositories at once, select "All repositories" from the repository picker before making changes. 1. **Review instructions** * Provide general guidelines for the AI in plaintext. 2. **Library & framework versions** * Specify or override detected versions (e.g., React 18, Django 4) to improve suggestion accuracy. * Note that, by default, cubic will try to automatically detect the common libraries and versions they use to ensure that it tailors its reviews to those specific ones. 3. **Ignore patterns** Define comprehensive patterns to control which pull requests and files are reviewed: * **File path patterns**: Skip files or directories matching glob patterns (e.g., `dist/`, `*.test.ts`) * **Head branch patterns**: Suppress automatic reviews for PRs from matching branches (e.g., `feature/*`, `hotfix/*`) * **Base branch patterns**: Suppress automatic reviews for PRs targeting matching branches (e.g., `staging`, `develop`) * **PR label patterns**: Suppress automatic reviews for PRs with matching labels (e.g., `wip`, `skip-review`) * **PR title patterns**: Suppress automatic reviews for PRs with matching titles (e.g., `Draft:*`, `WIP:*`) * **Maximum changed lines**: Store the automatic-review threshold for a PR's reviewable added plus deleted lines. The default is 50,000 lines, and leaving the setting absent or blank uses that default. cubic preserves positive integers up to 2,147,483,647, but applies an effective ceiling of 50,000 reviewable lines to every review. Manual `@cubic-dev-ai review` requests can bypass a lower repository threshold, but not the effective ceiling. Pull request label, title, and branch patterns suppress automatic reviews. You can still request a review on a matching PR with `@cubic-dev-ai review`. File path patterns continue to apply to manually requested reviews, so matching files remain excluded. File ignore/include patterns ending in `/` behave as `dir/**`: `packages/locales/` is equivalent to `packages/locales/**`. Paths are relative to the repository root, so `locales/` does not match `packages/locales/`. Wildcard expansion does not match dotfiles or hidden directories unless their dot-prefixed segments are explicit, for example `packages/locales/.locale-config.json` or `packages/locales/.hidden/**`. 4. **Exclude generated files** For large repositories, you can tell cubic to ignore files that don't require review. This is handy for: * Data files that don’t need to be reviewed * Auto‑generated code produced by build or code‑gen tools * Any other files that would make a pull request too large for cubic to process You can do this by marking files as generated in your repository’s `.gitattributes` file: ```gitattributes theme={null} # Exclude specific files docs/data.txt linguist-generated=true # Exclude file types *.csv linguist-generated=true *.pb.go linguist-generated=true # Exclude entire directories data/* linguist-generated=true generated/* linguist-generated=true ``` Files marked as `linguist-generated` will be: * Automatically collapsed in GitHub pull request views * Skipped entirely during **cubic**'s code review 5. Automatic PR approval * When enabled, cubic can evaluate clean pull requests for automatic approval * Disabled by default to prevent bypassing branch protection rules * Only available when general AI review is enabled * Useful when you want to start in a safe dry-run mode, confirm your approval policy matches team expectations, and only later allow cubic to submit real approvals Behavior controls: * **Disabled**: cubic only comments on PRs and skips auto-approval evaluation * **Shadow**: cubic evaluates whether the PR would be approved, but still posts a normal review comment instead of a real GitHub approval * **Live**: cubic evaluates the PR and submits a real GitHub approval when the selected policy allows it Approval policy controls: * **Low-risk only**: Approves only when no open issues block approval and cubic determines the PR is low-risk * **Always**: Approves any clean PR, regardless of risk level * **Custom**: Define your own criteria via a custom prompt. For example, only approve documentation changes while requiring human review for source code modifications * **Allow open issues**: Approve even while cubic issues at the chosen priorities stay open. Choosing a priority also includes every lower one; none are selected by default. See [Allow open issues](/ai-review/auto-approval#allow-open-issues). * **Never auto-approve**: Add file or directory globs that block auto-approval. If any changed file in a PR matches, cubic will not auto-approve that PR. * **Only auto-approve files**: Add file or directory globs that define an allowlist. Every changed path must match at least one glob. Renamed files must match on both their current and previous paths. * **Do not auto-approve external contributors**: For public repositories, cubic still reviews PRs from external contributors, but leaves a comment review instead of approving. cubic does the same when it can't confirm who the author is. On by default for new settings; existing settings keep their saved value. Shadow mode is useful when you want to test your approval policy safely before letting cubic approve pull requests automatically. See [Auto-approval](/ai-review/auto-approval) for setup steps, YAML configuration, safeguards, and troubleshooting. Auto-approve PR settings showing behavior and approval policy controls 6. **Review incremental commits** * When enabled, cubic reviews new commits pushed to open pull requests * Only new issues are posted as comments; previously flagged issues are not repeated * This setting also covers force-pushes, including jj workflows. cubic reviews only new changes relative to a previously reviewed version when it can safely reconstruct the difference. * Rewrites with no new code changes skip AI review. Text additions and modifications are supported. Unsupported changes (such as renames or binary changes) cause a skip, as does an unavailable reviewed baseline. Neither case falls back to a full review. * When a force-push is skipped because of an unsupported change or an unavailable reviewed baseline, cubic still reviews later pushes that only add commits on top of it, but does not auto-approve the pull request. Comment `@cubic review` to review the whole pull request. 7. **Auto-resolve threads when addressed** * When enabled, cubic automatically resolves GitHub review threads after detecting the issue has been addressed in a subsequent commit * Enabled by default for new installations 8. **Merge confidence summary** * Adds a 1-5 confidence score to cubic's reviews, helping you assess the risk of merging a pull request * The score considers factors like test coverage, code complexity, and potential regressions * During incremental reviews, cubic updates the score when issues are addressed and removes it when all issues are addressed * Disabled by default 9. **Ultrareview** (own tab) * The **Ultrareview** card controls whether [ultrareviews](/ai-review/ultrareview) — deep \~30-minute reviews billed at 3× the reviewed-lines rate — can run at all: **Disabled**, **Manual** (default; PR-comment and dashboard triggers only), or **Automatic** * With the mode set to **Automatic**, choose a risk policy (**Off**, **High-risk PRs**, or a **Custom prompt**) and add file rules that always trigger an ultrareview independently of the policy; manual triggers stay available; see the [ultrareview docs](/ai-review/ultrareview) for details 10. **Review draft pull requests** * When enabled, cubic reviews draft PRs immediately when opened * Get early feedback while still working on your changes * Disabled by default 11. **Cross-repo reviews** * Check related repositories for changes that need coordinated updates * Configured per repository from the **Cross-repo reviews** card * Available on every plan * See [Cross-repo reviews](/ai-review/cross-repo-reviews) for setup and behavior 12. **Coding agent instructions** * Instructions cubic's coding agent follows in this repository when it fixes issues: **Fix with cubic**, [auto-fix](/ai-review/auto-fix), `@cubic` requests, and codebase scan fixes * Use it for guidance just for cubic's fixes, like which issues are worth fixing in your codebase. Keep general guidance in your `AGENTS.md`, which cubic also reads * Can also be set with `issues.coding_agent_instructions` in [cubic.yaml](/configure/cubic-yaml) * See [Coding agent instructions](/ai-review/coding-agents#coding-agent-instructions) ## PR description settings Control how AI generates PR descriptions for your repository through the dedicated **Descriptions** tab. ### Available options 1. **PR description generation toggle** * Enable or disable automatic PR description generation for new pull requests * When enabled, cubic generates descriptions when PRs are opened 2. **Custom instructions** * Provide specific guidelines for how PR descriptions should be formatted * Instructions are applied to all AI-generated descriptions in the repository * Leave empty to use cubic's default description format 3. **View guided diff link** * Link to the PR in cubic from its description and from cubic's reviews * Enabled by default 4. **Skip when authors write descriptions** * When enabled, cubic skips generating a description on new PRs whose author already wrote a substantive one * Empty or template-only descriptions (unfilled headings, checklists, bare issue links) still get an AI description * Disabled by default Access these settings from the **Descriptions** tab in your [AI review settings](https://cubic.dev/ai-review?tab=descriptions). ## FAQ Yes. Turn off AI reviews for the repository in **AI review settings**, or set `reviews.enabled: false` in [cubic.yaml](/configure/cubic-yaml). Then comment `@cubic-dev-ai review this PR` when you want a review. To stop only push-triggered reviews, turn off **Review incremental commits** instead. Yes. Branch, title, and label ignore patterns stop automatic reviews, including incremental reviews after pushes. Comment `@cubic-dev-ai review this PR` to request a review manually. File ignore patterns still apply, so excluded files stay out of the review. ## Next steps * [Interactive comments](/ai-review/interactive-comments): Refine the AI's suggestions directly within PR comments. * [Custom agents](/ai-review/custom-agents): Create domain-specific checks to expand beyond general analysis. * [Auto-approval](/ai-review/auto-approval): Let cubic approve clean pull requests when your policy allows it. # Auto-approval Source: https://docs.cubic.dev/ai-review/auto-approval Skip human review for clean, low-risk pull requests when your policy allows it. Auto-approval lets you skip human review for pull requests that cubic determines are low risk and issue-free. When a PR matches your repository policy, cubic can submit the GitHub approval so the change can keep moving. Not every PR needs a human reviewer. Documentation updates, test-only changes, small config edits, and other low-risk PRs can move faster when cubic has already reviewed them and found no issues. Human reviewers can spend their time on changes that need judgment: product logic, infrastructure, security, data models, and other high-impact code. You stay in control by choosing the policy per repository. Auto-approval is disabled by default, and you can test it in shadow mode before cubic submits real GitHub approvals. Auto-approve PR settings showing Shadow behavior, Custom approval policy, a custom prompt, and never-auto-approve rules ## How it works cubic treats auto-approval as part of the review outcome. If the review is clean and your settings allow approval, cubic can approve the PR. If the PR does not match your policy, cubic does not approve it. cubic also checks again when someone dismisses the last issue that blocks approval, so the PR does not wait for another push. See [Dismissed issues](#dismissed-issues). Shadow mode is the safe way to start. It keeps cubic in comment-only mode, but adds a summary showing whether cubic would have approved the PR. ## Recommended workflow Start with repositories where the risk is low, such as documentation, internal tools, test fixtures, or repos with narrow change types. Auto-approval settings are configured per repository, so you do not need to roll it out everywhere at once. 1. Open [AI review settings](https://www.cubic.dev/ai-review?tab=auto-approve) and select one repository. 2. Set **Behavior** to **Shadow**. 3. Choose **Low-risk only** or write a **Custom** policy for that repository. 4. Watch a few real PRs to see which ones cubic would approve. 5. Add never-auto-approve rules for sensitive paths, such as migrations or infrastructure, and for PR attributes such as authors or labels. 6. Switch **Behavior** to **Live** when the shadow results match your team's expectations. Use different policies for different repositories. A docs repo might use live auto-approval much sooner than a payments, auth, or infrastructure repo. ## Behavior and policy Behavior controls whether cubic submits real approvals: * **Disabled:** cubic only comments. * **Shadow:** cubic comments and shows what it would have approved. * **Live:** cubic submits a real GitHub approval when the policy allows it. Approval policy controls which clean PRs are eligible: * **Low-risk only:** recommended default for most repositories. * **Custom:** your own approval criteria, such as "only approve tests and docs." * **Always:** approves any clean review. Use this only for repositories where that is acceptable. ### Custom policy The custom policy allows you to provide your own prompt for the auto-approval agent. When you select this option, cubic will first give you the prompt it uses for the low-risk policy. You can then edit the prompt to adapt it to your needs. The custom policy only runs when no open cubic issues block approval. By default every open issue blocks; [Allow open issues](#allow-open-issues) lets issues at the priorities you choose stay open. If cubic finds issues in the first commit of the PR, but those issues are resolved in the next commit, the custom policy will run. It also runs when someone dismisses the last blocking issue. The custom approval agent receives the following context: | Context | What cubic provides | | - | - | | PR details | The title, author, description, total number of changed files, and total number of changed lines. | | Current changes | Available diff patches with each file's name, status, additions, and deletions. Large descriptions and diffs may be truncated to fit the evaluation context. | | Earlier decisions | On later reviews, the previous approval decision and the changes since that decision, when available. The agent still makes a fresh decision from the current PR diff. | | Open issues | Open cubic issues that [Allow open issues](#allow-open-issues) lets through, with each issue's priority, location, and summary. | | Dismissed issues | cubic issues that someone resolved or disputed without a fix cubic detected, with each issue's priority, location, summary, and latest reply, if any. A reply may dispute the issue, say it was fixed, or defer it. The agent treats each dismissal and reply as a claim to check against the diff. See [Dismissed issues](#dismissed-issues). | ## Allow open issues By default, any open cubic issue blocks auto-approval. **Allow open issues** lets a repository approve PRs while issues at the priorities you choose stay open. Pick the priorities in the dropdown; picking one also picks every lower priority, so choosing **P2** allows P2 and P3. Nothing is selected by default. | Open issues on the PR | Setting | Result | | - | - | - | | This review finds a P3 | None | Comment only | | This review finds a P3 | P3 | Findings review, then a separate approval | | This review finds a P2 and a P3 | P3 | Comment only | | This review finds a P0 | All | Findings review, then a separate approval | | No new issues; a P3 from an earlier push is still open | P3 | Approval | | An issue has no recorded priority | Any except All | Comment only | * Priority is the P0–P3 label on each cubic comment. * Only findings cubic posts count. Findings dropped by the inline comment limit never block approval. * When new issues are allowed, cubic posts its findings as a normal review, then submits the approval as a separate review. * Every other rule still applies: behavior, approval policy, never-auto-approve and only-auto-approve rules, and external contributors. With **Low-risk only** or **Custom**, the approval agent sees the open issues and still makes its own decision. In `cubic.yaml`, set `reviews.auto_approve_rules.allow_open_issues` to `none`, `p3`, `p2_and_p3`, `p1_to_p3`, or `all`. ## Dismissed issues A cubic issue stops blocking approval when a later commit fixes it, when someone resolves its review thread, or when someone disputes it by replying that it is wrong. These authors can dispute an issue by replying: * A repository member. * The pull request author. * Anyone with write access to the repository. * A GitHub App bot, such as a coding agent working on the pull request. The bot does not need to tag cubic. cubic does not reply to a bot's dispute. If the dispute clears the last blocking issue and cubic checks approval again, it can still post the result in the thread, as described below. Only repository members teach it [learnings](/ai-review/memory-and-learning). A pull request comment that tags cubic can dispute issues too, such as `@cubic-dev-ai the P3 about test coverage is out of scope for this PR`. cubic works out which open issues the comment disputes, dismisses them, and replies with links to their threads. When it can't tell which issue the comment means, cubic dismisses nothing and replies with a list of the open issues, so the author can reply in the right thread. cubic answers these comments from bots as well. The same authors can dismiss issues this way, and these comments never teach learnings. When someone dismisses the last blocking issue, cubic checks approval again without waiting for another push. cubic waits about 10 seconds for further dismissals, then checks once. Every other rule still applies: behavior, approval policy, never-auto-approve and only-auto-approve rules, and external contributors. * With **Low-risk only** or **Custom**, the approval agent sees each dismissed issue and its latest reply. It checks the reply against the diff and can ask for human review when an issue still applies. * With **Always**, cubic approves once no rule blocks approval, so resolving the last thread is enough to approve the PR. If the last issue was disputed in a reply, cubic answers in that thread: | Result | cubic's reply | | - | - | | Approved | Says cubic approved the PR. With [Allow open issues](#allow-open-issues), it also counts the issues left open. | | A rule blocks approval | Names the rule. | | The approval agent declines | Gives the agent's reason and asks for human review. | cubic does not post an approval result when other issues still block approval, or when the last issue was dismissed by resolving its thread or by a pull request comment. cubic checks again only when: * **Behavior** is **Live**. * cubic has reviewed the PR's latest commit. After a push, the review of that commit decides. * No cubic review is running on the PR. A running review decides with the dismissals in place. ## Safety controls Auto-approval is conservative by design: * cubic only approves when no open review issues block it. By default, every open issue blocks approval. * A resolved or disputed issue stops blocking approval. With **Low-risk only** or **Custom**, the approval agent still checks each dismissal against the diff. See [Dismissed issues](#dismissed-issues). * Shadow mode never submits a real approval. * Never-auto-approve rules block approval when a PR changes sensitive files or matches a PR attribute rule. * Changed-file allowlists restrict approval to explicitly approved paths. * By default, public-repository PRs from external contributors are reviewed but not auto-approved. The same applies when cubic can't confirm whether the author is an external contributor. This default applies to new settings; existing settings keep their saved value. * Bots enabled in your team settings count as trusted authors for the external-contributor check. Their PRs still need to satisfy your approval policy and every other rule. * GitHub branch protection still applies, including required checks, required reviewers, and code owner rules. Use never-auto-approve rules for files that should always get human review, such as migrations, infrastructure, auth, billing, or production configuration. If any changed file in the PR matches one of those patterns, cubic does not approve the PR. Use only-auto-approve file rules to start with a narrow set of trusted paths. Every changed path must match at least one configured glob. A PR that changes both `docs/**` and `cdk/**` does not qualify when the allowlist contains only `docs/**`. Renamed files must match on both their current and previous paths, and never-auto-approve rules always take precedence. ## Approval filters Auto-approval can also filter on PR attributes: the author, the head or base branch, PR labels, and the PR title. * **Never auto-approve when…** rules block approval when any rule matches. For example, exclude PRs labeled `do-not-auto-approve` or titled `WIP:*`. * **Only auto-approve when…** rules are allowlists. Once an attribute has rules, PRs must match one of them. For example, only auto-approve PRs from `renovate[bot]` or `dependabot[bot]` that target `main`. Authors, branches, and titles support glob patterns; labels match exactly, ignoring case. If cubic cannot verify a PR's metadata, it does not approve the PR. Configure these settings in [AI review settings](https://www.cubic.dev/ai-review?tab=auto-approve), or version-control them with [`cubic.yaml`](/configure/cubic-yaml). ## Next steps * [AI review settings](https://www.cubic.dev/ai-review?tab=auto-approve): Configure auto-approval in the dashboard. * [Configure with cubic.yaml](/configure/cubic-yaml): Version-control auto-approval settings. # Auto-fix Source: https://docs.cubic.dev/ai-review/auto-fix Let cubic fix the issues it finds in your pull requests cubic can automatically fix the issues from its review. It checks each issue, pushes fixes for the real ones to your pull request, and replies on every thread. Instead of copying the **Prompt for AI agents** into your own coding agent, let cubic do the work. You only need to answer the questions it can't decide alone. Auto-fix is in beta. Paid plans and trials include an allowance of auto-fix pull requests. See [Limits](#limits). cubic's Confirmed reply on a resolved review thread, naming its fix commit ## How it works When cubic finishes reviewing your pull request, auto-fix: 1. **Checks each issue** - Reads the code to see if the issue is real 2. **Fixes the real ones** - Makes the change and runs your lint, type-check, and tests where it can 3. **Pushes the fix** - Commits to your PR branch 4. **Replies on each thread** - Explains what it decided and resolves the thread when it's done With more than 10 issues, auto-fix works in batches of 10. Each batch's fixes and replies reach your pull request before it starts the next, and the run's progress comment counts the issues done so far. Each push gets a new review. Auto-fix keeps going until a review finds no open issues. This needs automatic reviews of new commits, which are on unless `cubic.yaml` sets `reviews.incremental_commits: false`. cubic's fix commit in the pull request's commit list ## What cubic replies Each reply starts with cubic's decision: | Reply starts with | Meaning | Thread | | - | - | - | | **Confirmed.** | The issue is real. cubic fixed it and names the commit. | Resolved | | **Not an issue.** | The issue doesn't hold, or the change isn't worth the risk. | Resolved | | **Already fixed.** | A later commit fixed it. | Resolved | | **No longer applies.** | The code it flagged is gone. | Resolved | | **Needs your input.** | It needs a decision from you. cubic asks a question. | Open | cubic keeps its fixes small and in line with your pull request's goal, as its title and description state it. When a fix would significantly change how the pull request is built, such as implementing a feature, taking a different approach or deleting a substantial part of your changes, or would undo part of that goal, cubic asks you instead. Want a say before it runs? Reply on the thread. If you have write access, cubic follows your reply. For example, "leave it" means cubic won't change the code. ## Turn on auto-fix for a pull request Anyone with write access to the repository can turn auto-fix on or off from: * **GitHub** - Click **Turn on auto-fix** in the footer of cubic's review * **PR description** - Click the **Auto-fix** switch next to **View guided diff** * **cubic** - Use the **Auto-fix** switch on the PR page * **Slack** - Click **Enable auto-fix** on cubic's review message * **MCP** - Ask your coding agent to call `set_pr_auto_fix` on the [cubic MCP server](/ide/mcp-server) Turn on auto-fix link in the footer of cubic's review Auto-fix starts right away on any open issues. cubic commits the fixes as its own GitHub app, not as the person who turned it on. Turning it on from GitHub or Slack opens the pull request's fix session, where you can watch the run start. If there are no open issues yet, the session shows that auto-fix is waiting for the review cubic is running, or for its next review if none is in progress. ## Turn on auto-fix for a repository Admins and members can set auto-fix for a repository in [AI review → Auto-fix](https://www.cubic.dev/ai-review?tab=auto-fix): * **Off** - Auto-fix isn't available * **On demand** (default) - Someone turns it on for each pull request * **On** - Auto-fix turns on for every pull request that matches your rules. People can still turn it off on a pull request Auto-fix card set to On, with an Only auto-fix rule for one author and a Never auto-fix rule for bots ### Rules When auto-fix is **On**, rules under **Advanced** pick which pull requests get auto-fix: * **Only auto-fix when…** - A pull request must match each of these. For example, an **Author** rule with your GitHub username runs auto-fix on your pull requests only * **Never auto-fix when…** - Any match skips the pull request. For example, skip `*[bot]` authors or PRs with a `no-auto-fix` label Rules can match the author, label, title, head branch, or base branch. They only decide whether auto-fix starts. Once it's on, turn it off on the pull request. You can also set the mode and rules in [cubic.yaml](/configure/cubic-yaml), under `issues`. `auto_fix_rules` takes the same PR keys as `auto_approve_rules`: `only_` or `exclude_` followed by `authors`, `labels`, `titles`, `head_branches`, or `base_branches`. ```yaml theme={null} issues: auto_fix: on # off | on_demand | on auto_fix_rules: only_authors: - alice exclude_labels: - no-auto-fix ``` If a rule in `cubic.yaml` has a whitespace-only list item, a value longer than 256 characters after trimming, or an empty `only_` list, cubic ignores all the rules and keeps auto-fix **On demand** until you fix them, or **Off** if the file sets `auto_fix: off`. An empty-string item (such as `""`) invalidates the entire YAML file and falls back to UI settings, which may still have auto-fix **On**. ## Follow a run Each run opens as a fix session in [Fixes](https://www.cubic.dev/code/fix). You can watch the agent work and see what it fixed. You can't send it messages. An auto-fix run's fix session in cubic, showing the agent's steps and the pushed fix Open the session from: * The **cubic · Auto-fix** check on the pull request * cubic's comment on the pull request * The cubic PR page Click **Stop fix** to stop a run, or **Retry fix** to rerun a failed one. ## Stop auto-fix * **Turn it off** - From any place you can turn it on. A run in progress finishes first * **Push your own commits** - cubic stops the current run and picks up again after the next review * **Close or merge the pull request** - Auto-fix turns off, and the pull request's fix sessions move to **Archived** ## Limits Each organization can auto-fix a set number of pull requests per billing period, shared across its repositories: | Plan | Auto-fix pull requests per billing period | | - | - | | Free and open source | Not included | | Trial | 2 per seat, up to 50 | | Team | 2 per seat | | Pro | 10 per seat | | Max | 20 per seat | Paid plans reset monthly, including annual subscriptions. The trial allowance covers the whole trial and resets when it ends. A pull request counts once per period, the first time auto-fix starts a run on it. Later runs, retries, and pushes on that pull request don't count again. Auto-fix works through up to 100 different issues per pull request per period, across all its runs. An issue counts once, so working on it again in a later run or a retry doesn't count it again. Failing CI checks have their own limit and don't count toward the 100 issues: auto-fix works through up to 50 different failing check runs per pull request per period. Each push's CI creates new check runs, and working on the same check run again doesn't count it again. A run that stops because your repository's environment needs setup, such as access to a private package registry, doesn't count: it adds nothing to either limit, and a pull request whose only runs stopped that way doesn't count toward your organization's limit. When your organization reaches its limit, auto-fix pauses on new pull requests until the period resets. Pull requests that already count keep running. The PR page shows why auto-fix paused and when it resumes. See your usage in [Settings → Usage](https://www.cubic.dev/settings?tab=usage). ## Tell cubic how to fix cubic reads your repository's `AGENTS.md`. Keep general guidance for coding agents there. For guidance just for cubic's fixes, like which issues are worth fixing in your codebase, add [coding agent instructions](/ai-review/coding-agents#coding-agent-instructions). ## Troubleshooting * In [AI review → Auto-fix](https://www.cubic.dev/ai-review?tab=auto-fix), make sure the **Fix with cubic button** is on, the coding agent provider is **Default** (cubic), and auto-fix isn't **Off** * Make sure you have write access to the repository * Pull requests from forks aren't supported, because cubic can't push to them * Check that the repository is set to **On** and the pull request matches your rules * If someone turned auto-fix off on the pull request, it stays off there. Turn it back on from the pull request * With label rules, auto-fix turns on after the first review, not when the PR opens * Your organization used its auto-fix pull requests for the period, or the pull request reached its limit of 100 different issues, or 50 failing check runs, for the period and has only new ones left. See [Limits](#limits) * After the reset date shown on the PR page, auto-fix resumes at cubic's next review. To resume right away, click **retry** next to **paused** on the PR page * After three failed runs in a row, auto-fix stops. Click **Retry fix** in the fix session or push a commit * If you pushed commits, auto-fix picks up again after cubic reviews them * Auto-fix doesn't revisit an issue it already decided, but you can still ask for a fix. Comment `@cubic fix this` on the thread, and cubic starts a [separate fix](/ai-review/coding-agents#tagging-cubic-in-github-or-cubic) * For **Needs your input.**, tag cubic with your answer, for example `@cubic keep three retries and fix this` # Coding agents Source: https://docs.cubic.dev/ai-review/coding-agents Use Coding agents to asynchronously fix issues flagged in code review. cubic can automatically fix issues identified during code review. Request a targeted fix with one click, or turn on [auto-fix](/ai-review/auto-fix) to have cubic fix the issues from every review of a pull request. Fix with cubic button ## How it works When cubic identifies an issue in your code, you can request an AI-generated fix that: 1. **Analyzes the issue** - Reviews the problem and relevant context 2. **Generates a solution** - Creates a targeted fix addressing the specific issue 3. **Applies the fix** - Pushes commits to your PR branch by default, or opens a fix PR when requested 4. **Preserves review flow** - Lets you review the changes before merging into your main PR By default, cubic pushes commits directly to your PR branch. To override, include "open a fix PR" in your request. If cubic opens a fix PR, it targets the branch of your original PR, not the main branch. ## Triggering fixes There are two ways to request an AI fix: ### Tagging cubic in Github or cubic Request AI fix demo You can also request fixes for issues cubic didn’t flag. Tag cubic in any PR comment (including colleague comments) and ask for a fix: * "@cubic fix this issue" * "@cubic-dev-ai can you generate a fix for this?" * "@cubic please fix the type error mentioned above" cubic will acknowledge your request and begin generating the fix. If you want a separate PR instead of direct commits, say "open a fix PR." cubic only treats the current comment as permission to edit code when that comment explicitly tags cubic. `@cubic`, `@cubic-dev-ai`, and other supported cubic tags work. Replying inside a cubic-started thread without a fresh tag is treated as discussion, feedback, or questions, not authorization to push changes. ### Using the fix button in cubic