这一页写的是在装机之前就该定的四件事：身份怎么带、额度按什么单位设、被拦下来之后看什么、哪几格今天还是占位。逐键的配置步骤随安装包一起发，现在这里不写。
关心额度按什么单位设、成员与密钥怎么发、告警挂到哪。这一档人配的那一格是「每人美元额度」，不是「每人每天几发」。
关心请求地址指到哪、身份怎么带。身份沿用网关发的密钥，走 Authorization: Bearer，原有代码几乎不改。
关心这里的数字能不能报账。答案是网关的账本按预扣与实际产生量记，厂商账单以厂商为准，两边不做逐笔勾稽。
每人美元额度预设四档：$10 / $50 / $200 / 不限，默认 $50。付不起本次最坏成本 ⇒ 请求不发往厂商，这一条就是「额度耗尽即拦截」的全部含义。
四档预设是给"一个人最多能花多少"的天花板，不是把团队预算除以人数。给得过低的结果是正常需求被拦，不是省钱。
闸门按本次最坏情况预扣，所以额度消耗看起来比厂商账单快。这不是超支，是留出的安全边际 —— 要压缩这段边际，请调低模型的输出上限而不是调高额度。
输出量大、单发贵的模型，把它的输出上限自己配一道天花板比抬额度更管用；这一格的建议值随价目表逐行核对完再给。
席位数（1 / ≤10 / ≤25）是 License 授权门，不参与额度换算，也不等于能用的人数。
面板与回执给的是同一笔账：输入按价目计价，输出按你为这个模型配的上限计满。两个数都在，判定才可复现。
同一次请求可能人没问题、项目有问题。先确认触底的是哪一层，再决定是加额度还是收上限。
死循环与重复读取的处理方向在 Agent 行为风控那一格，它今天还在进行中，判据没上量具之前这里不承诺它能认出什么。
请求打到一半断了怎么算：至少按已产生量入账；拿不到量时按本次预扣额入账，不再退回。
安装、首装提示、把客户端指到网关的逐步截图随安装包一起发；现在写就等于承诺一个还没打出来的包。
计费说明与供应商超发的处理原则随文档一起发布，本页只挂了那句限定的原文。
参考表随包的 60 秒自测命令一起提供，本页不放数值区间。
需要这几项先到？在候补名单里说明你的场景 —— 收件地址即将开通。