Determine a way to limit usage of Agentic Workspace Builds by user/group
- Dominant language
- No language data
- Stars
- 3
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
> [!NOTE]
> This issue is a part of our larger **AI Governance Add-On**: [PRD](https://www.notion.so/coderhq/AI-Governance-Add-On-2ced579be592801eac50c83982a0fa49). See the [GitHub Project](https://github.com/orgs/coder/projects/84/views/2) for all related issues.
> [!IMPORTANT]
> This is a problem statement and needs more definition via a PRD/RFC.
Since admins are given a pool of Agentic Workspace Starts (e.g. 1000 in Premium, and more via an AI Governance Add-On or Usage-Based Pricing), they will want to ensure that one greedy user, group, or accidental usage will not consume the entire pool. This will also prevent overuse of the underlying compute or other repercussions of an excessive number of ephemeral workspaces being provisioned by a single actor. We need to find a way for admins to limit users/groups from creating too many workspaces.
Things to consider:
- [ ] Budget/pools per group: Allow an entire group (e.g. Everyone) access to a budget of workspaces, and any user in the group can consume as many as they need up to the budget. This doesn't entirely solve a greedy user but can prevent use of the entire pool and also allow other groups (e.g. "Automated Bots") a dedicated pool.
- [ ] Budget/pools per user: This will allow users access to their own budgets. This could be combined with a group budget, or entirely separate but determined based on group membership similar to quotas.
- [ ] Reset/extend budgets: There will be scenarios where a user/group may consume all of their workspaces and need access to more. How can this be reset/extended if there is additional room in the pool?
- [ ] Overages: How should overages be handled? Both for the overall deployment pool and group pools?
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.