有 Google AI Pro 订阅，为什么第三方工具还报免费档限流？
有一种情况特别让人困惑：你明明买了付费订阅，用某个第三方工具接 Gemini 时，却一直报免费档的限流。
Kilo Code 仓库的 issue #4650（已关闭）标题就是这个：
Gemini CLI Provider returns "Free Tier Rate Limit Exceeded" error even with active Google AI Pro
报告者的描述是：在 Kilo Code 里用 Gemini CLI 作为提供商，持续收到「免费档速率限制超出」的报错，尽管他有一个有效的 Google AI Pro 订阅。
这篇讲清楚这类问题的结构，以及怎么定位。
一、先说清楚证据状态
issue #4650 里没有官方结论。 评论区只有寥寥几条，包括「这是 Google 的问题」「我也一样」，以及一条指向另一个 issue 的链接。本文不引用这些猜测。
本文能给的是：基于官方额度页的公开信息，把这类问题的结构讲清楚，让你能自己定位。
二、关键概念：额度是按「授权路径」算的
按官方额度与定价页，Gemini CLI 的额度是按授权方式划分的：
| 授权方式 | 每日请求上限 | 每分钟请求上限 |
|---|---|---|
| Google 登录（Gemini Code Assist 个人版） | 1000 | 60 |
| Gemini API Key（未付费） | 250 | 10 |
| Gemini Code Assist 标准版 | 1500 | 120 |
| Gemini Code Assist 企业版 | 2000 | 120 |
注意这张表的第一列是「授权方式」，不是「你买了什么」。
这就是理解这类问题的钥匙：你的额度取决于这次请求走的是哪条授权路径，而不是取决于你名下有哪些订阅。
一个账号名下可能同时存在多种授权方式：
- 你用 Google 账号登录了 Gemini CLI
- 你在 AI Studio 申请过一个 API key
- 你买了某个订阅
- 你在 Google Cloud 里有项目
这些不会自动合并成一份额度。 每条路径有自己的规则。
三、第三方工具让这件事更容易搞混
用第三方工具（编辑器插件、Agent 框架）接 Gemini 时，链路变成了：
你 → 第三方工具 → 某条授权路径 → Gemini
问题在于：中间那个工具选了哪条路径，你未必知道。
它可能：
- 调用你本地已登录的 Gemini CLI
- 用你在它设置里填的 API key
- 走它自己的某种接入方式
而你看到的报错，是那条路径的额度报错，不是你订阅的额度报错。
这就解释了 issue #4650 那种体感：订阅是有效的，但这次请求根本没走订阅那条路。
四、怎么定位额度被哪条路径吃了
第一，确认工具用的是哪条路径。
去那个工具的设置里看它的 Gemini 提供商配置：
- 填的是 API key？那走的就是 API key 那条路（未付费的话是 250/天、10/分钟）
- 配的是调用本地 CLI？那走的是你 CLI 当前登录的那条
- 其他方式？看它的文档
这一步能解决大部分困惑。 很多人以为自己在用订阅，实际上工具里填的是一个免费的 API key。
第二，直接用 CLI 试同样的操作。
绕开第三方工具，直接在终端里用 gemini 干一件类似的事。
- CLI 里正常、工具里报限流 → 问题在工具选的路径上
- CLI 里也报 → 那是你 CLI 当前授权路径本身的额度问题
这个对照几分钟就能做完，比在设置里猜快得多。
第三，确认 CLI 自己走的是哪条。
如果你的环境里有 GOOGLE_CLOUD_PROJECT 或 GOOGLE_CLOUD_PROJECT_ID，官方说明这会强制走组织订阅校验——这本身就会改变授权路径，甚至直接报错：
You must be a named user on your organization's Gemini Code Assist Standard edition subscription...
查一下：
env | grep GOOGLE_CLOUD
五、多个工具共用一个账号会怎样
这是另一个容易被忽略的方向：额度的单位是「per user」。
官方表格里写的是 1000 model requests / user / day、60 model requests / user / minute——按用户算，不是按工具算。
所以如果你同时用着：
- 终端里的 Gemini CLI
- 编辑器里的某个插件（配了同一个账号）
- 另一个 Agent 工具（也是同一个账号）
它们消耗的是同一份额度。
而这会造成一个很难排查的现象：你在某个工具里明明没用几次，却撞了限流——因为额度被另一个工具吃掉了。
尤其要注意后台运行的东西：某些插件会在你不主动操作时也发请求（比如后台索引、自动补全、定期同步）。这类消耗你完全感觉不到，但它实实在在占额度。
排查方法：怀疑额度被别的东西吃掉时，把其他工具全关掉，只留一个，再试。 这是最直接的验证。
六、几条实用建议
给不同用途分开配置。 如果条件允许，让日常使用和自动化/后台任务走不同的授权路径，这样它们不会互相挤占，出问题时也好定位。
心里记着链路。 用第三方工具时，随手记下它配的是哪条路径。出问题时这是第一个要看的地方。
别把「我买了订阅」当成额度的依据。 依据是这次请求走了哪条路。
限流报错要看清是哪一种。 「Free Tier Rate Limit Exceeded」这种措辞明确指向免费档——它已经告诉你走的是免费路径了，这本身就是一条重要线索，说明问题不在订阅有没有生效，而在于这次请求压根没用上订阅。
每分钟那条线更容易被多工具叠加撞上。 免费档是 60/分钟，两个工具同时活跃，脉冲叠加，很容易在某一分钟内超出。
七、一份「额度去哪了」的自查清单
怀疑额度被莫名其妙吃掉时，按这个清单走一遍，大部分情况能定位：
1. 这次请求走的是哪条授权路径？ 去工具的设置里看。填的是 API key 就是 API key 那条（未付费 250/天、10/分钟），不是你的订阅。
2. 环境里有没有 GOOGLE_CLOUD_PROJECT 或 GOOGLE_CLOUD_PROJECT_ID？
env | grep GOOGLE_CLOUD
官方说明这两个变量会强制走组织订阅校验，直接改变授权路径。
3. 同一个账号还在别的地方用着吗？ 终端里的 CLI、编辑器插件、别的 Agent 工具——额度单位是 per user，它们共用同一份。
4. 有没有后台在跑的东西？ 自动补全、后台索引、定期同步——这类消耗你感觉不到。把其他工具全关掉只留一个，是最直接的验证。
5. 撞的是日限还是分钟限？ 猛干一阵突然被拦、等一会儿又能用 → 分钟限；用一整天后持续被拦 → 日限。多工具叠加最容易撞的是分钟限，因为脉冲会叠加。
6. 报错措辞说的是哪一档？ 像「Free Tier Rate Limit Exceeded」这种明确提到免费档的，已经告诉你走的是免费路径了——这时候纠结订阅有没有生效是白费力气，该去查为什么没走上订阅那条路。
这六步里，第 1 步和第 3 步命中率最高。 大多数「订阅了却被限流」的情况，答案都在这两条里。
八、总结
- 额度是按「授权路径」算的，不是按「你买了什么」算的。 同一个账号名下的多种授权方式不会自动合并。
- 第三方工具选了哪条路径，你未必知道——先去它的设置里确认。
- 最快的定位方法是对照：绕开工具，直接用 CLI 干同样的事，看还报不报。
- 额度单位是 per user，多个工具用同一个账号会共用同一份额度。
- 后台请求最容易被忽略——某些插件在你不操作时也在发请求。怀疑时把其他工具全关掉再试。
- 「Free Tier Rate Limit Exceeded」这个措辞本身就是线索：它说明这次请求走的是免费路径，问题不在订阅是否有效。
- 环境里的
GOOGLE_CLOUD_PROJECT会改变授权路径，排查时顺手查一下。 - issue #4650 没有官方结论，本文不引用评论区的猜测。
本文数字来自 Gemini CLI 官方额度与定价页，报错说明来自该仓库自带的 troubleshooting 文档，issue 编号来自 Kilo-Org/kilocode 仓库，核对日 2026-08-08。额度政策与第三方工具的接入方式都会变化，以官方为准。