gemini cli 额度怎么查

用 Gemini CLI 写代码写到一半忽然报额度不够，或者想提前知道今天还剩多少，很多人第一反应是翻聊天记录找入口。这篇不背任何数字，只给你一套固定的查法：先分清你用的是哪种账号，再按顺序看命令行反馈、网页后台和站内追踪页，最后对一遍用量口径。

用 Gemini CLI 写代码写到一半忽然报额度不够，或者想提前知道今天还剩多少，很多人第一反应是翻聊天记录、翻收藏夹里那个入口链接。其实额度这东西不在一个固定地方，它跟着你用的账号类型走。这篇不背任何数字，只给你一套固定的查法：先分清自己属于哪种账号，再按顺序看命令行反馈、网页后台和站内追踪页，最后把三边的用量口径对一遍。整个过程不依赖记忆，照着做就行。

开始之前先记住一件事：别人告诉你的「在哪看」不一定适用于你。免费个人账号、订阅档位账号、API Key 自付费，这三类身份额度来源完全不同，能看到数字的地方也不同。所以第一步永远是确认身份，而不是直接冲去某个页面翻。

先确认你用的是哪种账号，再谈查额度

在终端里敲命令之前，先花一分钟确认自己是怎么登录的：是浏览器登录授权，还是填了一个 API Key，还是公司给的一串凭证。这个前提决定了后面所有步骤走哪条路。记下登录方式和是否绑过结算，这两条信息后面每一步都依赖它。

免费个人账号

用邮箱登录，没有订阅也没有绑卡，额度通常按天或按周期给一个笼统的量。

订阅档位账号

同一个邮箱订阅了付费档位，额度一般有明确周期和重置时间，能在订阅管理页看到。

API Key 自付费

自己在开发者控制台建了 Key 并绑了结算，用量按调用量计，去控制台的用量页看。

团队统一分配

额度由管理员发，个人后台通常看不到总额度和已用量的全貌。

还有一个容易踩的坑：同一个邮箱在网页对话端和 CLI 端，计量的可能是两套账。网页里显示还剩不少，不代表命令行里也还剩这么多。别把一边的剩余量直接套到另一边。

命令行侧能看到的信号：从报错反推剩余量

额度不够时，最先冒出来的往往是报错，而不是某个面板。所以第一动作是把那条报错的完整文本读一遍。留意关键词：说的是配额、限额，还是请求频率。这两类提示含义完全不同，处理方式也完全不同。

• 配额类提示：通常是周期内的量用完了，要等重置，重试没用。
• 限流类提示：请求太频繁被挡了一下，等几十秒再发往往就能过。
• 权限类提示：跟额度无关，多半是 Key 失效或账号没开通对应能力。
• 网络类提示：超时、连接被断这类，别往额度上想，先查网络和代理。

部分版本在状态或诊断类输出里会带上账号和用量摘要，可以主动跑一次看看有没有。如果有，这就是最省事的查询方式；如果没有，就把报错文本留好，作为后面去后台对账的锚点。

1. 复现一次报错用一条最小的请求触发，确保报错干净、不被其他信息淹没。
2. 抓完整文本报错被终端截断时，去日志文件里找原始返回，别只看后半段。
3. 归类按上面清单分成配额、限流、权限、网络四类，决定是等待还是排查。
4. 留档把报错原文和时间点记一行，后面和后台数字对照时用得上。

不适用的情形：报错只显示了简略提示，或者客户端把关键字段吞掉了。这时候命令行侧基本给不出有效信息，直接跳到网页后台那一步。

网页后台的入口位置与要看的字段

网页后台要记住一个分岔：订阅档位的额度去订阅管理页看，API Key 的用量去开发者控制台的用量与配额页看，这两处不在一起。找错地方会以为自己的额度消失了，其实只是走错门。

不管在哪个页面，先找三个字段：当前周期是什么、已经用了多少、下次重置在什么时候。缺任何一个都无法判断手头的活能不能撑到结束。只有已用量没有重置时间，等于只知道花了一半钱却不知道工资什么时候发。

如果页面有按模型拆分的视图，先确认你 CLI 里实际调用的是哪个模型，再看对应那一行。对着另一个模型的数字发愁是常见误判。不适用的情形：免费层往往只给一句笼统的剩余提示，不展示具体数值，这种情况下只能靠本地记录估。

没有现成面板时，自己记一笔最靠谱

有些情况下你就是看不到一个明确的数字，比如免费层、比如走渠道接入。这时候别死磕页面，自己记一笔反而更实用。在 CLI 的配置里开启请求日志或会话记录，把每次调用的基本信息落盘，几天下来你自己的曲线比任何面板都准。

• 时间戳：精确到分钟，方便和后台数字对齐时段。
• 模型标识：写清调用的是哪个模型，便于按模型分开统计。
• 请求次数：一次会话算一次还是按轮次算，自己定个规则并固定下来。
• 规模量：输入和输出的规模，粗记即可，用来看趋势不用来精算。

汇总时按天看比按次看有意义得多。重点盯单日峰值，也就是你最忙那天用了多少，而不是平均值。平均值会让你误以为很宽裕，结果一到赶进度的日子就撞墙。

不适用的情形：日志只记录本地行为。如果你的请求经过代理或中转，日志里不会完整出现真实调用，这时候本地记录只能当参考，不能当账本。

重置周期怎么判断，别在错误的时间焦虑

同样是「还剩一点」，在不同重置规则下含义差别很大。先分清是按自然周期滚动，还是按你首次调用那一刻起算。前者到点统一刷新，后者每个人时间不同。搞错了规则，就会在明明快刷新的时候慌张，或者在刚重置后误以为还有余量。

重置时间点一般写在配额页面，命令行报错里有时也会带一句。两边对不上的时候，以官方页面的时间为准，因为报错里的时间可能是缓存的或者按 UTC 显示的。

不适用的情形：通过第三方渠道接入时，重置节奏由渠道自己定，官方页面写的时间对它不成立。这时候要么去渠道自己的说明里找，要么按自己的本地记录保守估。

把三个来源对齐：命令行、后台、站内追踪

单个来源都可能骗你，所以养成对账习惯：同一时间段取三个数放在一起看。命令行给的报错或摘要、网页后台的用量页、以及站内的额度与价格追踪页，横向比一次，心里就有底了。

1. 定一个时间窗选最近一段连续使用的时间，别拿不同天的数据比。
2. 取三个数CLI 侧信号、后台用量、站内追踪页各取一份。
3. 查口径差异看是否含缓存、是否按输入输出分开计、时区是否一致。
4. 下结论三个来源指向同一结论才据此安排接下来的开发节奏。

想看清不同渠道的价格与用量口径差异，可以到 /price-watch 核对当时的数字，那里把各类计费维度列得比较细，用来判断自己看到的数字属于哪一类很有用。不适用的情形：跨账号或跨渠道混着用的时候，数字天然不可比，别硬凑成一个结论。

一张排查清单和固定动作顺序

把上面几节压成一套固定动作，下次遇到额度问题直接照着走，不用重新想。顺序不要跳，跳了就容易在错误的页面找答案。

• 第一步：确认账号身份，是订阅、API Key 还是免费层。
• 第二步：复现一次报错，抓完整文本并归类。
• 第三步：按身份打开对应的后台用量页，找齐三个字段。
• 第四步：翻自己的本地日志，核对同一时间窗的消耗。
• 第五步：到站内追踪页对比口径，看差异出在哪。
• 第六步：结论记一行，下次直接复用。

几个最常见的误判：把限流当成额度耗尽，白等半天；把网页端的剩余当成 CLI 的剩余；把上个月的数据当成这个月的。这三条只要按顺序查一遍，基本都能避开。

如果所有入口都看不到明确数字，那就按最保守的节奏排任务，把长任务拆成能中断的小段，每段做完就落一次盘。这样即使中途额度断了，损失也可控。相关的工具和辅助脚本可以在 /tools/speed-test 和站点工具目录里找，先拿小请求验证一下链路再上正式任务。

这些情况下上面的查法不成立

上面这套流程基于一个前提：你对账号有一定的查看权限。一旦这个前提不成立，硬套只会让你更困惑。下面几种情况要换思路。

• 额度由公司管理员统一分配、你没有后台权限：只能向管理员要口径，别自己猜。
• 走中转或代理接入：你看到的是渠道额度，和官方数量级没有可比性。
• 账号刚变更订阅或刚绑结算：页面数字可能有延迟，别急着下结论。
• 多人共用一个账号：个人看到的用量是合并的，判断不了自己贡献了多少。

还有一条通用原则：凡是要引用具体数字、单价或者名次的地方，都不要凭记忆写，一律去站内对应页面看当期值。数字会变，页面才是唯一依据。