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.

​

Manual approval

In this mode, admins can update their seat counts manually. When a user without a seat raises a PR in a repository where CodeRabbit is installed, they receive a note on their PR indicating that they do not have a seat and will receive a free tier summary.

​

Auto-approval

In this mode, users are automatically provisioned seats when they raise a PR in a repository where CodeRabbit is installed. Automatic assignment is triggered only when a user opens a pull request. Pushing new commits (a synchronize event) to an existing pull request does not assign a seat, so an unseated author remains unseated until they open a new pull request or an administrator assigns one. Newly provisioned users can open a new pull request to trigger automatic assignment. Other users should ask an administrator to assign a seat through subscription management. If there is an existing user with a seat who has not raised a CodeRabbit pull request in the last 30 days, that seat is reallocated to the new user. If all seats are taken, CodeRabbit can provision a new license and charge a prorated amount. Enterprise organizations are capped at their purchased seat count, as described in Enterprise SSO workspaces.

​

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.

​

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 pull request while purchased seat capacity remains. Once all purchased seats are in use, CodeRabbit does not increase the subscription’s seat count, and the pull request author is treated as ineligible for the normal review flow. Automatic seat assignment resumes after seat capacity is freed, such as through reallocation, or the purchased seat count is increased.

​

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 does not automatically combine 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. 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 pull request, CodeRabbit finds the member entry that contains it and assigns a seat if needed. If the identity has not been linked to an IdP member, CodeRabbit creates or uses its Git-only member entry. 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. 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 pull request. If all seats are taken, CodeRabbit can provision a new license according to your subscription. In Manual mode, admins assign seats to IdP members or Git-only members individually from Workspace Team Management. Individual seat assignment controls are disabled while Automatic mode is on. Workspace Team Management does not assign consumed seats to billing admins. If a billing admin already has a seat, admins can still unassign it. For role-editing details, see Workspace roles.

​

Pending unassignment

When you unassign a seat from a user on a monthly paid subscription, the seat is marked as “Pending unassignment” rather than being immediately unassigned. This allows for more flexibility in managing your team while maintaining fair billing practices.

​

How “Pending unassignment” works

• Delayed unassignment: When you unassign a seat from a monthly subscriber, it remains active until the end of your current billing cycle
• Continued access: Users with “Pending unassignment” seats retain full CodeRabbit access until the billing cycle ends
• Automatic cleanup: At the end of the billing cycle, all “Pending unassignment” seats are automatically unassigned, and the users will lose the seat

​

Billing implications

“Pending unassignment” seats are still counted as active seats for billing purposes during the current cycle. You will continue to be charged for these seats until they are automatically unassigned at the end of your billing period. This approach ensures you get full value from your subscription while giving you the flexibility to adjust your team composition as needed.

​

Troubleshooting

​

Existing users having their seats removed

When auto-approval mode is enabled, users have their seats reassigned if they have not raised a PR in the last 30 days and a new user without a seat opens a PR.

​

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

This is likely due to bot users or external users that have seats. These users are displayed separately from regular git provider organization members.

​

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 does a user still have access after I unassigned their seat?

For monthly paid subscriptions, unassigned seats are marked as “Pending unassignment” and remain active until the end of the current billing cycle. This means users retain full CodeRabbit access during this period. See the Pending unassignment section for more details on this behavior.

​

When will a “Pending unassignment” seat become available for reassignment?

“Pending unassignment” seats are automatically unassigned at the end of your billing cycle. Once the billing cycle ends, the seat becomes fully available for reassignment to a new user. Until then, the seat remains allocated to the original user.

​

What’s next