Seat assignment

CodeRabbit ingests users from your git provider (GitHub, GitLab, Bitbucket, and Azure DevOps) and assigns seats based on your organization’s active seat assignment mode. Understanding these modes helps you control who gets access to CodeRabbit reviews and how billing is affected.

Seat assignment methods

Trial mode

This mode is only active during the trial. In trial mode, users are automatically provisioned with a seat when they raise a PR in a repository where CodeRabbit is installed. During an eligible primary trial, activity on an existing PR can also assign an available trial seat to a human author who doesn’t have one yet. Pushing commits, commenting, reopening the PR, or marking it ready for review all count. This never adds seats to the subscription or assigns seats to bots. Manual assignment restrictions still apply. Listing an author in ignore_usernames doesn’t stop them from getting a trial seat, as described in Auto-approval.

Manual approval

In this mode, admins can continue assigning seats directly from Team Management, or Workspace Team Management for Enterprise SSO workspaces. A developer does not need to submit a request first. Developer requests provide an additional way to ask for a seat. Eligible users without a seat can request a review seat from the free summary on their private-repository PRs. Public and open-source PRs do not show this request action.

Auto-approval

In this mode, users are automatically provisioned seats when they raise a PR in a repository where CodeRabbit is installed. On subscriptions billed through GitHub Marketplace, auto-approval doesn’t assign seats; admins assign them from Team Management in manual approval mode. For paid subscriptions, a pull request triggers automatic assignment only when it’s opened, including when it’s opened as a draft. Activity on an existing pull request doesn’t assign a seat: pushing commits, commenting, reopening a closed pull request, or marking a draft ready for review leaves an unseated author unseated. Unless free-tier reviews are turned off with enable_free_tier, CodeRabbit posts a free summary on those pull requests with a note that the author has no seat, or that the organization has reached its seat limit if every seat is in use. Newly provisioned users can open a new pull request to trigger automatic assignment. Other users should ask an administrator to assign a seat. While auto-approval is on, the administrator first switches to manual approval in Team Management. The available-seat exception during a trial is described in Trial mode. With auto-approval, using the IDE extension or the CLI can also assign a seat to a member of your Git organization, outside pull requests. This doesn’t apply in Enterprise SSO workspaces.

When inactive seats are released

CodeRabbit releases inactive seats only when every purchased seat is in use and a developer without a seat opens a new pull request. Seats aren’t released on a schedule, so while seats remain available, nobody loses a seat, however long they’ve been inactive. Seats are never released in manual approval mode, during a trial, or on GitHub Marketplace subscriptions. Enterprise SSO workspaces follow their own rules, described in Enterprise SSO workspaces. When this happens, CodeRabbit immediately releases the seat of every member with no activity for 30 days or more, including admins, bots, and manually assigned seats, and assigns one of the released seats to the pull request author. Any other released seats stay unassigned and remain part of your purchased seat count. The 30-day period isn’t configurable. Activity means CodeRabbit activity on pull requests the member authored:

• Opening a pull request, pushing commits to it, or any person commenting or chatting with CodeRabbit on it counts.
• Being assigned a seat counts.
• Reviewing other people’s pull requests and using the IDE extension or CLI don’t count.
• Opening, pushing to, or commenting on a pull request during a trial isn’t recorded and doesn’t count after the trial ends, but the time a seat was assigned during the trial does.

If no seat can be released, CodeRabbit adds one seat to the subscription on standard self-serve plans and bills it as a prorated charge, as described in How seat changes affect billing. On these plans, a seat assigned through the IDE extension or the CLI when every seat is in use also adds a billed seat, without first releasing inactive seats. Enterprise plans, and subscriptions bought through a marketplace, invoiced offline, or managed by a reseller, don’t add seats automatically. Instead, the author gets a free summary with a note that the organization has reached its seat limit, unless free-tier reviews are turned off with enable_free_tier. An Admin or Billing Admin can add Enterprise capacity, as described in Enterprise seat true-up. To keep a teammate’s seat regardless of activity, or to avoid unexpected seat purchases, use manual approval.

Request a review seat

In CodeRabbit Cloud, you can request a seat when your selected organization uses manual seat assignment, your membership is eligible for a seat, and you do not already have one. The organization must have an active paid subscription, including a subscription scheduled to cancel at the end of its current term. Requests are unavailable during trials, after the subscription ends, or while automatic seat assignment is enabled.

Request from a pull request

On an eligible private-repository PR, the free-summary notice identifies the author who needs a seat. On GitHub, select Request a review seat for @author. The request is always for the PR author, even if another person selects the checkbox. On GitLab, Bitbucket, and Azure DevOps, use the Request a review seat link to open CodeRabbit. Sign in as the developer who needs the seat and check the selected organization before submitting the request. The GitHub notice also includes an Open in CodeRabbit link. Public and open-source PRs do not display a seat-request checkbox or link. If a request fails, the GitHub checkbox remains available to try again.

Request from the web app

1. Sign in to CodeRabbit and select the organization where you need a seat.
2. In the developer sidebar, under Reviews, select Request a review seat.
3. Check the organization name in the dialog, then select Request a review seat to notify its administrators.

The sidebar action is shown only when you are eligible to request a seat in that organization. While a request is pending, its label becomes Seat request pending. It disappears after a seat is assigned.

Pending requests and reminders

After submitting, the dialog shows Seat request pending, your last request date, and when you can request again. Requests remain pending until a seat is assigned. Submitting again within seven days returns the same pending request without sending another notification. After seven days, select Request again to notify administrators again without creating a duplicate request. CodeRabbit also schedules one reminder after three weekdays from the initial request, calculated in UTC and skipping weekends but not holidays, if the request remains pending and eligible. Requesting again does not restart this reminder. Notifications go to the organization’s recorded CodeRabbit admins, billing admins, applicable workspace admins, and current billing contact. If no admins are recorded, CodeRabbit uses the billing contact when available. Saving a request does not guarantee that an email has reached an inbox; admins can also find pending requests in Team Management.

Approve a seat request

1. Open Team Management and select the Seat requests tab. Its badge shows the pending count.
2. Open a request to review the developer, person who requested the seat, organization, request dates, and source PR when available.
3. Select Approve. If another paid seat is needed, review the estimated cost, currency, seat quantity, proration, and billing timing before confirming. An available seat can be assigned without an additional charge.

For an eligible Enterprise organization, approval can increase paid capacity through quarterly true-up billing. Review Enterprise seat true-up before confirming the billable seat change. The Review seat request link in an email opens the request in the correct organization after sign-in. Opening the link does not assign a seat. Approval requires existing seat-management permission; receiving an email as the billing contact does not grant that permission. If pricing or seat quantity changes, refresh and confirm the updated estimate. When your purchasing arrangement does not support adding seats through the app, follow the purchasing instructions shown. Ineligible requests remain visible with approval unavailable. Admins can also assign the seat directly using the existing seat-management controls instead of approving it from this tab. Direct assignment fulfills the matching pending request. Approval does not automatically start a review on the original PR. Request a review through the PR commands after the seat is assigned.

Managing seat assignments

To change your seat assignment mode, navigate to Team Management in the CodeRabbit dashboard and click the settings icon next to Invite Billing Admin. From this menu, you can switch between auto-approval and manual approval modes. Click Confirm to save your changes. While auto-approval is on, Team Management locks the seat controls for members and shows a banner saying so. To assign or unassign a member’s seat yourself, switch to manual approval first. During some trials, the mode can’t be switched until your subscription is active, and the banner says so. Seats held by bots can be changed in either mode.

Enterprise SSO workspaces

Enterprise SSO workspaces manage seats from Workspace Team Management. Open the seat assignment settings to switch between Automatic and Manual modes. In Automatic mode, a member is assigned a seat when they open a new pull request while purchased seat capacity remains. On a paid subscription, CodeRabbit never adds seats to a full workspace automatically. If every seat is in use and none can be released, an author without a seat gets a free summary with a note that the organization has reached its seat limit, unless free-tier reviews are turned off with enable_free_tier. For ways to free up capacity, see Choose a seat assignment mode.

How Enterprise SSO seats are counted

Every pull request author is identified by a Git identity, such as a GitHub username, GitLab username, Bitbucket account, or Azure DevOps identity. That Git identity must be covered by a seat to receive paid PR reviews. In Workspace Team Management, CodeRabbit assigns the seat to a member entry. A member entry can be:

• An IdP member: A person who signed in through SSO or was provisioned from your identity provider through SCIM.
• A Git-only member: An entry created for a Git identity that has pull request activity but is not yet linked to an IdP member.

A seat on either type of member entry covers all Git identities linked to it. The same Git identity can receive reviews across every organization or group for the same Git provider and provider instance in the workspace without another seat. CodeRabbit can’t reliably link Git identities across providers. Git providers do not expose a shared, stable identifier that reliably links a GitHub username, GitLab username, Azure DevOps identity, or self-hosted account to the same person. Email and SAML attributes can differ between providers or may not be available, especially for self-hosted instances. Instead, an admin links identities, or a member connects their own Git account in CodeRabbit, as described in How IdP members, Git identities, and seats relate. As a narrow exception, when a pull request author has no member entry yet and their Git provider exposes a verified email that matches the normalized email of an existing member entry in the workspace, CodeRabbit links the identity to that member automatically, unless that member already has a different identity on the same Git provider. In that case, CodeRabbit creates a new Git-only member instead. Enterprise SSO workspaces use one CodeRabbit subscription across the workspace. Adding another organization for an already linked Git identity on the same provider instance does not require another seat.

How IdP members, Git identities, and seats relate

The Git identity that opens a pull request determines who needs review access. The member entry that contains that Git identity determines where CodeRabbit assigns the seat.

• If the Git identity is linked to an IdP member, the seat is assigned to that IdP member and covers every Git identity linked to the member.
• If the Git identity is not linked to an IdP member, CodeRabbit represents it as a Git-only member. That entry can receive a seat so the Git identity can receive paid PR reviews.

In Manual mode, admins assign seats to IdP members or Git-only members from Workspace Team Management. In Automatic mode, when a Git identity opens a new pull request, CodeRabbit finds the member entry that contains it and assigns a seat if needed. If the identity isn’t on any member entry yet, CodeRabbit creates a Git-only member entry for it, unless it can link the identity by email. On a paid subscription, activity on an existing pull request doesn’t assign a seat. Using the IDE extension or the CLI never assigns a seat in an SSO workspace. Admins can link Git identities to an IdP member through Workspace Team Management by selecting the member and using Edit member links. The same links can be managed with the User Management API. Linking identities that were on separate member entries consolidates them under the IdP member. One seat then covers all of the linked Git identities, and any duplicate seat is freed. Normally, a Git identity without a member entry becomes a Git-only member. An identity that CodeRabbit couldn’t attach to any member entry, not even a Git-only one, shows an Unlinked badge in Workspace Team Management and, unless it belongs to a bot, can’t be assigned a seat until it’s linked to a member. The person who owns that Git identity can link it by connecting their Git account in CodeRabbit, or an admin can link it with Edit member links. If that member has no seat, an admin can assign one, or in Automatic mode the author can open a new pull request to get one. When an IdP member is removed through SCIM, CodeRabbit removes the member, their linked Git identities, and their seat from Workspace Team Management. If one of those Git identities opens a pull request later, it reappears as a Git-only member and follows the workspace’s current seat assignment mode.

Choose a seat assignment mode

In Automatic mode, CodeRabbit assigns a seat to the member entry containing a Git identity when that identity opens a new pull request, up to the purchased seat count. When all seats are taken, a seat becomes available again when inactive seats are released, an admin frees one by unassigning it, or an Admin or Billing Admin buys more capacity. In Manual mode, admins assign and unassign seats for IdP members or Git-only members individually from Workspace Team Management. While Automatic mode is on, these controls are disabled for members, so an admin switches to Manual mode to unassign a member’s seat. Seats held by bots can be assigned or unassigned in either mode. Workspace Team Management does not assign consumed seats to billing admins. If a billing admin already has a seat, admins can still unassign it in Manual mode. For role-editing details, see Workspace roles.

When inactive SSO seats are released

In Automatic mode on a paid subscription, CodeRabbit releases inactive seats only when every purchased seat is in use and a Git identity without a seat opens a new pull request. It then releases the seat of every member entry whose linked Git identities have all had no CodeRabbit activity for 30 days or more across all organizations in the workspace, and assigns one of the released seats to the author. Activity through any one linked Git identity keeps the member entry’s seat. Activity has the same meaning as in When inactive seats are released. This applies to IdP members and Git-only members, including admins and manually assigned seats. These seats are never released this way: seats held by bots, seats granted only as part of a trial, and seats on member entries with no linked Git identity, such as an IdP member seated before any identity was linked. Manual mode never releases seats.

Unassigning seats and billing

Unassigning a seat takes effect immediately and frees it for someone else, but it doesn’t change what you pay. Your paid seat count goes down only when an Admin or Billing Admin lowers it in Billing, starting at the next billing cycle.

What happens when you unassign a seat

As an Admin, select the member in Team Management and click Unassign in the action bar. While auto-approval is on, Team Management doesn’t let you change members’ seats, so switch to manual approval first. Seats held by bots can be changed in either mode. In Enterprise SSO workspaces, use Workspace Team Management, where a member’s seat can likewise be unassigned only in Manual mode.

• The member loses their seat right away and is treated like any member without a seat. They get free-tier reviews unless enable_free_tier is turned off.
• The seat stays in your purchased seat count, and you keep paying for it. Unassigning doesn’t change your subscription or produce a credit.
• You can assign the freed seat to another member right away at no extra charge.
• If you turn auto-approval back on, the member gets a seat again the next time they open a new pull request, but not from activity on existing ones. To keep them without a seat, stay in manual approval.

Pay for fewer seats

To pay for fewer seats on a standard self-serve plan:

1. If more seats are assigned than you want to pay for, have an Admin unassign seats in Team Management first. Billing doesn’t let you choose fewer seats than are assigned. With 12 assigned seats, it shows “12 seats are assigned. Unassign one in Team Management to go below 12.”
2. As an Admin or Billing Admin, open Subscription and Billing, select Billing Overview, click the edit button in Plan details, and lower Developer seats, as described in Change your plan or seat count.
3. Review the order summary, which shows the change, such as “Your seat count will change from 15 to 12 in the next billing cycle.” Then click Update Subscription.

The lower count takes effect at the start of your next billing cycle, which is your renewal date on an annual plan. Until then, you pay for the current count and can still assign the unassigned seats. If more seats are assigned than the new count when it takes effect, CodeRabbit automatically releases seats until the count fits, without asking which members keep theirs. To choose who keeps a seat, don’t assign more seats than the new count in the meantime. Admins can change or remove the scheduled reduction from the Manage changes banner, as described in Scheduled changes. If you bought CodeRabbit through a marketplace, such as GitHub Marketplace, change the seat count in that marketplace instead. If a reseller or your account team manages your billing, contact them to change it. With auto-approval, a new pull request from an author without a seat can add a billed seat when every seat is in use. Use manual approval to keep the count down.

Enterprise plans

For seats added through Enterprise true-up, Unassign releases the seat for another teammate. It doesn’t reduce the contracted seat count, reverse the prorated charge, or end the commitment through the current contract term. The paid seat count can’t be reduced in the product during the term, so contact your Customer Success Manager to discuss a reduction. See Unassign a true-up seat.

Troubleshooting

Existing users having their seats removed

With auto-approval, CodeRabbit releases every seat with no activity for 30 days or more when all seats are in use and a developer without a seat opens a new pull request. See When inactive seats are released for what counts as activity and how to keep a seat.

New users in auto-approval mode getting new licenses despite open seats

Bots and external users with seats count toward your used seats, but they’re displayed separately from regular Git provider organization members. Using the IDE extension or the CLI can also add a seat. See When inactive seats are released.

Users without seats still receiving CodeRabbit reviews on their PRs

Users without paid seats to CodeRabbit still receive free-tier CodeRabbit reviews unless the enable_free_tier setting is disabled.

Why didn’t my bill go down after I unassigned a seat?

Unassigning a seat frees it for another member but doesn’t change your paid seat count. On a standard self-serve plan, lower the seat count in Billing to pay for fewer seats. The reduction takes effect at the start of your next billing cycle. For marketplace and Enterprise subscriptions, see Pay for fewer seats and Enterprise plans.

Why can’t I lower my seat count?

On a standard self-serve plan, Billing doesn’t let you choose fewer seats than are currently assigned. Unassign members in Team Management first, then lower the seat count, as described in Pay for fewer seats. Marketplace subscriptions change the seat count in the marketplace, and Enterprise plans can’t reduce it during the contract term, as described in Enterprise plans.

Why does a member have a seat again after I unassigned it?

Auto-approval was probably turned back on after the seat was unassigned. Team Management lets you unassign members’ seats only in manual approval mode, and once auto-approval is on again, a member without a seat gets one the next time they open a new pull request. To keep them without a seat, stay in manual approval, as described in Managing seat assignments.

Automate with the API and MCP

Automate this with the CodeRabbit API and MCP server.

12 operations

Operation	Method and path	MCP tool
List audit log entries	GET /v1/audit-logs	REST and CLI only
List roles	GET /v1/configuration/roles	list_roles
Create role	POST /v1/configuration/roles	create_role
Get role	GET /v1/configuration/roles/{roleId}	get_role
Delete role	DELETE /v1/configuration/roles/{roleId}	delete_role
Update role	PATCH /v1/configuration/roles/{roleId}	update_role
List role permission options	GET /v1/configuration/roles/permissions	list_role_permission_options
List all users in the organization	GET /v1/users	REST and CLI only
Add users and assign seats for a self-hosted organization	PUT /v1/users	REST and CLI only
Change roles for multiple users	POST /v1/users/roles	REST and CLI only
Assign or unassign seats for multiple users	POST /v1/users/seats	REST and CLI only
Update the seat assignment mode	POST /v1/users/seats/assignment	REST and CLI only

What’s next