用 Gemini 时最难受的不是花钱，是任务跑到一半突然被拦住，又说不清是哪个入口的额度没了。网页版、AI Studio、API 三条路的限制口径不一样，报错提示也各不相同。这篇帮你先定位是哪种限制被触发，再按顺序排查，最后给止损和恢复的具体动作。
用 Gemini 最烦的时刻不是它答得不好，而是活干到一半突然被拦住，界面只给一句含糊的提示，你也说不清到底是哪份额度没了。网页端聊天、AI Studio 的实验环境、官方 API，这三条路的限制口径完全不一样，报错文案也各不相同，所以先别急着换账号或者充钱。
下面这套顺序的思路是：先定位限制来源，再看是哪种限制，然后按步骤排查、止损、恢复，最后给几个能让每天额度花得更久的动作。全程只讲判断标准和可执行动作，具体数值、档位差异一律以站内页面当时显示为准。
先搞清你被哪条入口限制了
同一个账号在三个入口里是三个独立的额度池，互相不共享。网页端聊天被限了，不代表 API 也被限；反过来 API 打到配额上限，网页端照样能聊。判断入口不要靠感觉，靠两个线索：报错文案长什么样，以及报错出现在哪个界面。
| 入口 | 典型表现 | 先看哪里 |
|---|---|---|
| 聊天网页端 | 提示当天/周期可用的次数用完，界面直接拦住不给发 | 看看是不是当日额度类提示，换 AI Studio 试同一句话 |
| AI Studio 实验环境 | 请求被拒或排队，长上下文任务更容易失败 | 看控制台有没有速率或配额类字样，清短上下文再试 |
| 官方 API | 返回配额或速率类错误码，脚本日志里能看到 | 区分是总量配额还是每分钟速率，参考站内速率口径页 |
| 订阅档位覆盖 | 某些入口能用、某些用不了，或额度上限不同 | 到 /plans/gemini-ai-plus 核对你开的档位实际覆盖什么 |
如果你开了订阅，先别默认「订阅=全入口放开」。不同档位覆盖的入口和额度上限不一样，同一个功能在网页端和 API 侧的口径也可能分开算。花两分钟去站内订阅说明页对一遍，比反复重试省事得多。
额度限制不止一种：次数、token、速率
很多人把「额度没了」当成一个笼统的概念，其实至少分三类，处理方式完全不同。分清这三类，你就知道该等一整天，还是等几十秒重试就行。
- 按请求次数限制
- 问一句和问十句都算一次，短对话并不会更省，靠精简提问内容没用
- 按 token 限制
- 长文档、长历史、长上下文吃亏最大，提示词越长消耗越快，和问几次关系不大
- 按速率限制
- 每分钟或每秒请求数被卡，报错和额度耗尽长得像，但等几秒到一分钟重试通常就通
识别顺序很简单：先看是「今天彻底不能用了」还是「稍等再试」。前者多半是配额类，按周期恢复；后者大概率是速率类，属于短时拥挤。速率这一块的口径容易和配额混，站内 /relay-billing-rate-rpm 讲得比较清楚，拿不准去对一下。
- 次数类限制：换入口、换账号可能绕过，但总量是死的，绕不过去
- token 类限制：开新会话、砍历史、拆文档是主要缓解手段
- 速率类限制：降并发、加退避重试、错峰跑脚本最有效
- 三种可能叠在一起，先按最省事的那条排查，别一上来就大动干戈
触发后的排查顺序：四步定位
被拦之后最容易犯的错是原地反复重发，这既浪费剩余额度，又可能把速率限制也踩出来，把一次小问题拖成双重限制。按下面四步走，一般两三分钟能定位到大概原因。
- 换一个入口试同一句话网页端不行就去 AI Studio 发一遍，API 不行就换网页端。能通，说明只是单个入口的额度耗尽，其他路径还能干活；三个都不通，再往下查。
- 开新会话、清长上下文如果换入口也不行，把当前对话历史清掉，用一个全新的短会话发一个简单问题。单次请求因为上下文太长而顶穿限制，是很常见的一种，清掉之后能通就属于这类。
- 检查是不是并发或脚本在刷多个进程、多个脚本共用同一把 key，是最容易被忽略的额度杀手。看一眼有没有自动重试、定时轮询在后台空转，先停掉再说。
- 确认是不是集体问题去 /resets 和 /ai-status 看当期说明和服务状态。如果一大片人同时反映，那多半是服务端额度调整或波动，不是你的锅，等公告即可。
免费额度和付费额度的差别在哪
免费额度不是「少了点钱的付费额度」，它是另一套逻辑：限制更紧、优先级更低。高峰期就算你没超量，也可能排队、变慢、偶发失败。这不是 bug，是资源调度的正常结果。
| 维度 | 免费额度 | 付费档位 |
|---|---|---|
| 限制松紧 | 更紧，容易在长任务中途断 | 更宽，但仍有上限 |
| 优先级 | 高峰期可能排队或失败 | 相对靠前，波动小一些 |
| 适用场景 | 验证想法、轻量试用、偶尔问 | 有固定量的日常活 |
| 不适用场景 | 当成稳定产能跑生产链路 | 指望单次超长任务一定跑完 |
判断标准就一句话：如果你每天都有固定量的活要干，别把免费额度当产能规划。长任务无论免费还是付费都要拆段做，付费解决的是上限和优先级，不保证单次一定跑得完。各档位的实际差异，到 /plans/gemini-ai-pro 看当时的说明。
任务跑到一半被拦，先做这三件事
任务断在半路，第一反应通常是「再试一次说不定就过了」。但在额度类限制下，重试大概率只是把剩余额度更快烧光。先把损失控制住，再谈恢复。
- 立刻停止连续重试，尤其是带自动重试的脚本，一定要先关掉
- 保存已完成的部分，中间产物落盘，别让整段工作随额度归零
- 把任务拆成小段，分时段续跑，或者临时换一条入口/另一家模型收尾
- 检查后台有没有轮询、心跳、自动补跑在空转，这类隐形消耗最吃额度
止损的关键是「可续」。任务设计时就该有中间保存点，这样哪怕被拦，你也只损失最后那一小段。一次性长任务在额度敏感的场景下本身就是高风险设计，能拆就拆。
额度多久恢复、能不能提前恢复
恢复时间取决于额度是按日、按周还是按订阅周期算。日额度一般按自然周期刷新，周或月额度跟着订阅周期走。具体时间点不要在脑子里背，站内 /resets 有当期说明，每次以那里为准。
订阅档位的额度通常随续费周期重置，中途升级不一定立刻补足当前周期的差额，下单前看清楚 /plans/gemini-ai-pro 的说明，别默认「升了就马上能用」。API 侧配额的提升一般需要在控制台申请，个人开发者等审批期间可以先降并发、加退避重试熬过高峰。
把每天的额度花得更久：可执行动作
与其每次被拦了再救火，不如把日常习惯改一下。下面这几个动作不需要额外成本，改完当天的可用时间通常能拉长不少。
- 合并提问把多次小问合成一次结构清晰的请求，明确让它一次给出完整结果。减少请求数就是减少次数占用，这是最直接的一招。
- 控制上下文长对话定期开新会话，别让历史一直背着走。长文档总结这类任务有专门的省 token 做法，参考站内 /long-doc-summary-token-saving 的思路。
- 批量与异步能等的任务放到低峰或批量通道跑，别占着交互额度。交互额度最贵，留给真正需要即时反馈的活。
- 给脚本设预算和告警跑之前先估用量，参考 /budget-alert-setup-guide 设阈值，超了就停。别等被平台拦下才发现已经跑飞了。
这些情况这套办法不适用
上面整套排查的前提是「正常账号、正常额度、正常服务」。有几种情况报错长得几乎一样，但无论换入口、清上下文还是等刷新都不会好，这时候继续按额度排查就是浪费时间。
- 账号本身被风控或权限受限，换入口、等刷新、换 IP 都无效
- 组织或团队账号的额度由管理员分配，个人层面的动作没用，要找管理员看分配口径
- 企业走合同或承诺用量，额度口径和公开档位完全不同，一切以合同为准
- 服务端本身异常，跟你用多少额度无关，先看 /ai-status 有没有公告
拿不准是不是额度的锅时，一个简单的判别办法：去 /ai-status 看一眼。如果没有异常公告、换个入口也不通、时间点又卡在周期重置之前，那基本就能确认是额度问题，按前面的顺序处理即可。
下一步把各入口的实时额度口径、订阅档位差异和恢复周期一次性对清楚，比每次被拦了再猜快得多。去站内页面核对当时的数字和政策说明，心里有底再安排当天的活。→常见问题
Gemini 的额度是按天刷新还是按月刷新？
两种都有，取决于你走的是哪个入口和哪种档位。免费入口的额度周期通常更短，订阅档位跟着计费周期走。具体刷新时间点和当期的口径，去站内额度重置追踪页面核对，别按上一次的记忆推。
额度用完了还有什么办法继续用？
先确认是哪种限制：如果是速率被卡，降并发、加退避重试就能继续；如果是配额耗尽，只能等刷新、升级档位或临时换另一条入口。急活建议提前准备一条备用路径，不要把关键任务压在单一入口上。
为什么我明明没超量，还是提示额度不足？
常见三种原因：上下文太长导致单次消耗远超预期；多进程或自动重试在后台反复占额度；以及账号权限或风控问题。按排查顺序先换入口验证，再查并发，最后看是不是服务端波动。
免费额度和付费额度可以叠加用吗？
多数情况下是两条独立的额度池，先扣哪条取决于入口和配置，混用会让你的用量账很难对。团队做成本分摊时最好固定走一条路径，混用的处理办法可以参考站内免费额度与付费额度分摊的写法。
怎么提前知道这个月会不会不够用？
用一两天的真实用量记录去外推，而不是凭感觉估。把请求数、上下文长度、并发峰值三个数记下来，再对照站内的模型用量榜看同类任务的常见水平，留出三成余量。
