Groups | CodeVector Docs

Organize users into teams with Groups. Members inherit shared access grants, rate limits, and budget caps so you don’t have to manage each user individually.

The Groups list

Groups list showing names, descriptions, and member counts — The Groups list shows every group with its description and member count.

Open /admin/groups to see all groups. The table shows:

Name - linked to the group detail page.
Description - optional context for the group’s purpose.
Members - how many users belong to the group.
Created - when the group was added.

Creating a group

Click Create group and enter a name. The description is optional but recommended for larger teams.

Group detail

Click any group name to open its detail page. From here you can:

Edit the name or description
Add member - open the user picker to attach existing users
Remove member - row menu on the Members table
Assign Model Access Grants that apply to every member
Set group-level Rate Limit caps that merge with each member’s user-level limits
Set group-level Budget Limit caps with the same merge-strictest rule

How grants and limits merge

When a user belongs to one or more groups, their effective permissions are computed as follows:

Access grants - the union of personal grants and all group grants. If any grant allows access to a model, the user can use it.
Rate limits - the strictest applicable limit wins across the user and all their groups.
Budget caps - the strictest applicable cap wins across the user and all their groups.

Group by seniority, not by project

Budget and rate limits always pick the strictest value across every group a user belongs to. Because of that, the way you structure groups has real consequences. We recommend grouping by user level or role (“Engineering,” “Interns,” “Contractors”) rather than by project or team (“Project Alpha,” “Backend Team,” “Q4 Initiative”).

Why this matters:

Alice is in two groups:

“Project Alpha” with a $200 daily cap
“Backend Team” with a $100 daily cap

Alice’s effective daily cap is $100. She cannot “switch” to the Project Alpha cap when working on Alpha. The Backend Team cap is stricter, so it applies everywhere. If she was grouped only by seniority, her cap would be predictable. She would not accidentally inherit a stricter limit from a secondary project group.

Bottom line: Put users in one primary group that matches their trust level or spend tier. If you must use multiple groups, treat every group’s limits as if they apply to every member at all times, because they do.

Bad conventions (what goes wrong)

How you grouped	What it looks like	Why it breaks
By project	”Project Alpha” ($200/day) + “Project Beta” ($50/day)	Anyone on both projects gets the $50 cap everywhere. The $200 cap is invisible to them.
By team	”Backend Team” ($100/day) + “Platform Team” ($30/day)	Platform’s $30 cap overrides Backend’s $100 cap. Engineers who wear both hats are throttled on backend work too.
By time period	”Q4 Initiative” ($500/day) + “H1 Planning” ($20/day)	The cheaper initiative’s $20 cap wins. The person cannot “use” the Q4 cap just because it is Q4.

Good conventions (what works)

How you grouped	What it looks like	Why it works
By seniority	”Engineering” ($150/day) + “Interns” ($20/day)	The intern gets $20, the senior gets $150. No overlap, no surprises.
By role	”ML Researchers” ($500/day) + “Support” ($10/day)	Different roles, different needs. A researcher is not in Support, so their $500 cap is untouched.
By trust level	”Full-time” ($200/day) + “Contractors” ($50/day)	Clean separation. If someone is both, the contractor cap wins — which is usually what you want for legal/compliance reasons.

If you genuinely need to organize people by project or team for access-control reasons, use groups only for model grants and leave budget and rate limits empty on those groups. Set the actual spend caps on a single role-based group instead.

Frequently asked questions

Do group grants stack with user grants?

Yes. A user gets the union of their personal grants and all group grants they belong to.

What if a user and group have conflicting rate limits?

The strictest limit wins. If a user has 100 req/min and a group has 60 req/min, the effective limit is 60.

Can a user belong to multiple groups?

Yes. There is no limit on group memberships. Keep in mind that budget and rate limits are merged strictest-wins across all groups, so adding a user to multiple groups can tighten their effective limits in ways you might not expect. See the notice above for details.

What happens if two groups give the same user different budget caps?

The lower cap wins. A user in “Engineering” ($50/day) and “Interns” ($20/day) is capped at $20/day. There is no way for the user to “use” the Engineering cap for some requests and the Interns cap for others.

Users. Manage individual accounts and their direct grants.
Access grants. How grants work for both users and groups.
Rate limits. How limits merge across users and groups.