Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Determine a way to limit usage of Agentic Workspace Builds by user/group

オープン
#1,230 コメント 1 件 リアクション 0 件 担当者 1 名 GitHub で見る

@zenithwolf1000 がすでに取り組んでいます。

2026年1月8日 から。

評価

この issue はまだ評価されていません。

説明

[!NOTE]
This issue is a part of our larger AI Governance Add-On: PRD. See the GitHub Project 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?
主要言語
言語のデータがありません
スター
3
フォーク
0
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

coder/internal のほかの issue

coder/internal の issue をすべて見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。