Claude Academy
加载中

支出上限

第 9 课9 分钟
本节课内容学完后，您将能够
  • 描述三个支出上限级别，并预测哪一个适用于某个特定成员
  • 解释成员达到上限时会经历什么，以及谁可以批准他们提出的更多额度请求
  • 决定上限在您的组织中应设在何处，以及谁负责处理升级请求

这是五项决策中的第四项：支出。您已经为成员可以构建的内容设定了规则。本课将介绍支出上限：它们所处的三个级别、成员达到上限时会发生什么，以及谁负责处理升级请求。

上限是什么，以及它们处于什么位置

支出上限分为三个级别，从最宽到最窄依次为：

  1. 组织上限（organization ceiling）： 您的组织在给定月份内可以使用的总额；没有任何群组上限或单个成员的覆盖设置可以让任何人超出这个总额。
  2. 群组上限（group caps）：群组中每个成员都继承的单成员限额，其大小根据该群组的典型使用量设定。
  3. 单成员覆盖（per-member overrides）：特定成员自己的限额，单独设置，可高于或低于其所在群组的数值。

在群组上限之下，还有一个在"支出默认设置（Spending defaults）"下设置的席位默认限额——这是成员在未设置任何群组上限或覆盖之前获得的数值。当某个成员同时属于两个都带有上限的群组时，一个组织范围的设置（"支出默认设置"下的"来自群组的成员限额（Member limit from groups）"）会决定适用哪一个，您可以选择让较高或较低的群组上限生效。席位默认限额也会参与这一比较，因此在选择"较高的群组限额"时，如果席位默认限额高于某个群组的上限，该成员获得的就是这个更高的数值。请谨慎设置这一项，因为与第 5 课中"权限并集规则"（即更宽的授权始终生效）不同，这里的决定权在您手中。

上限在实践中如何运作

当成员达到其上限时，其使用会被暂停。暂停不是中断服务，也不会有任何工作排队等待稍后运行。在其限额随新月份重置之前，或在获批的请求解除限制之前，该成员都无法超出上限继续使用 Claude。该成员还会在应用内看到一个请求更多额度的提示。该请求会出现在"组织设置（Organization settings）"中的"使用情况（Usage）"页面上，Owner、Primary Owner，以及任何自定义角色中"账单（Billing）"权限设置为"可管理（Can manage）"的人员都可以批准或拒绝该请求。

在规模扩大时需要注意一点：能够批准请求的人往往不是掌管预算的人，因此产品内的请求有时可能要等上好几天才能得到决定。如果您的预算负责人使用的是自定义角色，那么将"账单"权限设置为"可管理"的角色可以让他们直接做出决定；请只将此权限授予那些应当批准支出的人所担任的角色。大型组织通常会改为通过自己的工单系统来处理上限提升请求——"支出限额 API（Spend Limits API）"同样可以列出、批准和拒绝请求，以及设置限额。

与其逐个为成员设置上限，不如将群组上限作为您的规模化机制：将其大小设定为该群组的典型使用量，让成员身份来完成分配。群组上限并不是该群组共享的一个资金池，也不一定与人数成比例——它回答的问题是"这个群组中一个成员通常需要多少？"覆盖设置则用于特定的例外情况，例如某位分析师每月要用 Claude Code 运行一次繁重的数据分析任务。这样可以满足该分析师的需求，而无需为其所在的整个群组提高上限。

当单成员覆盖的数量不断增多时，作为 Claude Enterprise Admin API（公开测试版）一部分的"支出限额 API"可以以编程方式设置这些覆盖，这样平台团队就不必逐一手动设置。群组上限仍保留在您的组织设置中。如果覆盖列表持续增长，应将其视为一个信号：这些成员需要拥有自己的群组，而不是一份越来越长的例外清单。

Pluto 的上限设置

Pluto 根据预算负责人给出的数字设定了组织上限，并根据每个部门典型成员的使用量设定了群组上限。在第一个月的使用情况审查之后，那些 Claude Code 工作量远高于群组典型使用量的少数 Platform 工程师获得了单成员覆盖，而不是提高整个 Platform 群组的上限。提高群组上限会为每一位工程师（包括那些本来就远未达到上限的人）提升上限，因此覆盖设置只针对那些确实需要额外空间的异常值。Payments & Trust 会审查每一个涉及其群组的请求。

下面的交互式小组件展示了群组上限和单成员覆盖如何为某一位成员共同作用，以及当她同时属于两个群组时，您的"来自群组的成员限额"设置会应用哪一个上限。

加载中

1 · 您的决策

对于您的组织，上限应设在哪里（上限、群组上限、任何首日覆盖），以及当成员达到上限时，谁负责处理升级请求？

2 · 您可以做出的选择

这项决策是一个判断性决定，而不是一个简单的开关。您既要决定如何设置上限，也要决定一旦设置好之后由谁负责处理升级请求。请将以下各项考虑因素一并权衡。

您可以参考 Claude Enterprise 消费指南中的层级结构，而不必自行发明一套。该指南建议在推广之前按角色类型定义消费层级（轻度、标准和重度），以便上限的分配和调整保持一致。代理型工作每次会话的消耗可能多于一次简短的聊天：Claude Code、Cowork，以及统一版 Claude 体验中转入 Cowork 云端会话的聊天。

根据您自己的使用历史，或者如果有客户团队提供的规模建议，为每个层级设定一个数字，记录您设定该数字的日期，并将其视为一个起始数字，后续根据您自己的使用情况进行调整，而不是一个固定目标。有两个因素会限定您最终确定的数字：您的预算负责人所掌握的组织上限，以及第 6 课中每个群组实际获得的使用场景。

设置上限归结为三项考虑因素，外加一项（如果您是预付费用户）的约束条件，每一项都要结合您拥有多少使用历史以及该群组工作的性质来权衡：

  1. 按典型使用量设定： 典型适配。群组上限根据每个群组典型成员的使用量设定，由成员身份完成分配。
  2. 先收紧，再根据证据提高： 当使用量确实未知时（没有历史数据、新的使用场景），先从较紧的数字开始，并将每一次请求都视为您需要的使用证据，以便合理调整预算规模。根据证据提高，意味着在第一个月的数据支持之后，将群组上限重新设定到观察到的使用水平，而不是反复批准小幅度的增量。
  3. 为突发性工作预留空间： 对于有月末分析或季节性负载的群组，应为这种突发情况设置更高的上限或覆盖，并在之后撤销，而不是反复进行紧急审批。
  4. 如果您预付使用额度： 上限就是您剩余的预付额度。额度归零时，使用会在整个组织范围内暂停，直到额度被补充，因此预算负责人需要参与每一次上限变更。

在设置上限时就决定好升级处理的分工，而不是等到第一个请求出现之后再决定。从上文列出的批准人中指定谁来批准常规请求，并提前与预算负责人就批准范围达成一致；任何会改变群组上限或组织上限的请求都由预算负责人决定，并附上您的使用情况说明。让成员知道这个流程的存在，比具体的分工细节更重要。

3 · 如果您之后要更改

上限可以自由更改；每次更改从更改那一刻起生效。

设置资源

做出决定后，您将在组织设置中设置上限、群组上限以及任何覆盖。

课程活动

在许多组织中，这些数字由预算负责人来确定；如果您的情况正是如此，配套文档部分也可以作为您交给预算负责人的简报。在您的配套文档中，草拟：

  • 上限表：组织上限、各群组的数字，以及您为每个群组选择的层级，并说明选择该层级的原因。
  • 您已经预计需要覆盖设置的成员（如果有的话）。
  • 升级处理的分工：哪些由您当天批准，哪些提交给预算负责人。
  • 当某个成员同时属于两个设有上限的群组时，哪个上限生效。
  • 您组织的使用历史（如果有的话），与上限表一起分享，以便每个上限背后的理由能随请求一并呈现。

需要带给预算负责人的内容：上限表、您预计会出现的覆盖设置、升级处理的分工，以及支撑这些决定的使用历史。

→ 将此记录在随堂练习配套文档的第 9 课部分。

下载内容

  • Work-along companion (Word)

    The editable Word version of the rollout plan you fill in lesson by lesson.

    下载

  • Work-along companion (PDF)

    The same rollout plan as a fillable PDF.

    下载

接下来是什么

下一课将介绍您的计费方式，以及那些无需触碰任何上限就能调整支出的设置，这样当请求出现时，提高数字将是您的最后选择，而不是第一选择。