先选定一项任务，查清它对应了哪些请求

工具能正常回复，但 AIGoCode 额度下降得比预期快，最先需要核对的是：这段时间实际发生了哪些调用，每次调用用了什么模型、带了多少输入、生成了多少输出。只看聊天框里的消息条数，很难把消耗原因分清。

官方额度与限制说明，长上下文、大输出、缓存写入和工具重复请求都会增加消耗；不同模型的输入、输出、缓存读写成本也不同。下面给出一套核对顺序，帮助你把这些可能性落实到自己的调用记录，而不是直接猜测哪一项最贵。

一、先确认查看的是什么额度

根据官方额度与限制说明，前往主站用量统计查看具体请求记录；再按账户与额度说明，在主站控制台核对当前套餐、余额和消耗记录。文档同时列出了额度容量、恢复周期、周限额与并发限制，实际权益以控制台展示和服务端配置为准。

记录页面显示的指标名称和单位。如果你要比较两次任务，先确认比较的是同一个指标、同一单位和可对应的时间范围。不要把“额度尚未恢复”直接当成“刚才的任务消耗很大”：官方资料说明，额度未恢复也可能与恢复周期或周限额有关。

选取下一次本来就需要执行的任务，记下开始、结束时间和时区。如果同一时段还有其他客户端或脚本在工作，也一起备注；整段时间的变化不能直接全部归到这一个任务上。任务期间若发生充值、额度恢复或套餐变化，应将这些变化单独记下，不直接用余额前后差值代表本次消耗。

先给任务写一句明确的验收条件，例如“解释这一个函数的输入与输出”。再查看该时段能找到的请求记录，确认工具为完成它实际发出了哪些调用。

官方将工具重复请求列为消耗因素，因此一次用户操作不宜直接按一次请求估算。检查时可以记录下面这些内容；仅填写页面或日志实际提供的字段，看不到的标注为“未显示”。

如果任务跨了多个模型，先按模型分开看。工具显示的 token 用量和控制台显示的额度也应分别保留原单位；没有对应计费依据时，不自行套一个统一换算比例。

拿到记录后，按下面的顺序缩小范围：

调用次数比预期多。 回看工具是否多次发起相似请求，以及哪些步骤触发了后续调用。这里的目标是解释请求数量，不凭“看起来像重复”就判定后台重复扣费。失败、取消和成功记录也分开整理，不能只按日志条数估算扣减。

调用次数接近，但输入规模变化明显。 查看这次任务是否额外带入长历史、大文件或无关资料。官方把长上下文列为消耗增加的因素，但具体是哪份内容造成变化，仍要用你自己的输入范围和记录核对。

输出规模变化明显。 对照两次要求：一次只需要一个结论，另一次是否要求完整文件、详细说明和多轮补充。下一次可以先明确所需交付范围，例如只返回相关修改和必要解释，再观察记录是否变化。

出现缓存相关用量。 将缓存读写与其他用量分开核对。官方资料明确，不同模型的输入、输出、缓存读写成本不同；仅凭出现了缓存字段，不能推断这次一定更省，也不能据此还原具体扣费。

这四项是排查方向，不是已经测出的原因。如果两次任务的模型、输入和输出都变了，应先保留差异，再选一个因素继续观察，避免把所有变化归到同一处。

选择一项仍然需要完成的小任务，尽量保持模型和验收条件一致，只调整一个因素。比如已发现输入明显变长，就把提供材料限定到相关函数和必要背景；观察输出是否仍满足需求，以及对应请求、用量和消耗记录有什么变化。

保留“调整了什么、结果是否合格、记录怎样变化”这三项即可。一次消耗下降只能说明那次任务的结果，不能据此承诺长期固定节省比例；如果质量下降，还需要重新调整任务范围。

若主要现象已经变成并行运行时连续出现 429，可转到本站的429 并行任务排查指南。额度消耗核对和连接失败排查需要分别记录，避免把不同问题混在一起。

向支持人员说明具体时间范围、工具与模型、期望完成的任务、可对应的请求记录，以及控制台展示的消耗和单位。若页面提供请求标识，可一并保留；缺失字段直接说明缺失，不猜填。

发送前移除 API Key、认证头和敏感业务内容。把已经确认的现象与尚未确认的解释分开写，例如“这段时间出现多次相似调用”是可核对的线索，“一定重复扣费”则需要进一步证据。这样得到的记录，既能用于查明本次消耗，也便于下一次任务按相同口径比较。