T3 Code 用量与账单对不上？先查统计范围和缓存价格

T3 Code 的 Usage 显示用了几十美元，订阅账户却没有多扣钱；另一边，模型明明跑过任务，费用栏却写着 Unpriced。先别急着判断漏扣或多扣：这几处显示回答的问题不同。

Usage 的费用用于估算，Limits 用于查看订阅余量，实际花了多少钱要查所用服务的账单。 对不上时，先把时间、机器、账号和模型对齐，再检查价格与缺失记录。

本文按 2026 年 11 月 9 日查阅的 T3 Code v0.1.7 正式版文档与计价源码说明。当天 latest stable 仍指向此版本。下面给出检查顺序和可复算例子；没有使用真实付费会话来测量账单差异。

先分清三个数字分别从哪来

T3 Code 的 Usage 文档把费用称为 estimated API-equivalent cost：根据能取得的用量记录与价格，显示相当于 API 调用的费用。它明确说明，这不是订阅账单。

你看到的数字	它能回答什么	还要去哪核对
Usage 里的估算费用	已读取的调用记录按所用价格算下来是多少	统计范围、价格来源、未定价模型
Usage → Limits 的剩余额度	已连接订阅账号报告的使用窗口还剩多少	实际账号、刷新时间、供应商的额度页面
模型服务的用量日志和账单	经该服务发出的请求如何记录、结算	请求明细、套餐规则、分组与计费单位

API 等价费用高于月订阅费，单凭这一点不能算“节省了多少”。要做比较，还得确认相同的任务、模型、速度档位、完整调用和实际套餐条件。Limits 的百分比也不能直接当作钱包余额来换算。

中文社区确实有人困惑于这些口径。一篇 V2EX 用量讨论里，既有人问怎样查看 Token，也有人讨论自建网关与官方后台是否一致。帖中的自报金额、总 Token 和免费额度混在不同配置里，适合提醒我们先对齐范围，不适合拿来算一个“开发者平均日成本”。

费用偏少或漏了模型，先看统计读到了什么

在网页或桌面打开 Usage，先看环境下拉框。v0.1.7 默认选择所有环境；某些机器仍在扫描时，结果会陆续更新。先选一台机器，再检查需要合看的其他机器，比较起来更容易。

接着确认这些范围：

• 时间：客户端与服务账单使用同一段时间，尤其注意跨午夜和时区。
• 账号与历史目录：Usage 会读取已配置账号的历史，包括停用账号。多个账号共用同一个历史目录时，文档说明会去重；停用连接并不等于删除其历史统计。
• 模型筛选：检查服务器是否配置了 usageModelFilter。它可能让部分模型不进入总数。
• 记录完整性：文档列有部分文本生成调用不进入总数的情况，包括某些运行工具生成标题、提交说明等调用未保存会话历史。不能据此把整个开发任务都当成已统计。

做完这些检查再刷新，让 Usage 重扫历史并更新模型价格。刷新后有 Token、没有费用，下一步查定价；连对应调用都没有，下一步查记录来源。反复修改价格不能补回没有读到的调用。

如果线程根本没有开始，先按 T3 Code 工作区准备检查定位等待阶段，再核对实际调用；加载状态本身不能证明已经产生或没有产生模型费用。

近期也有更具体的缺失报告。Issue #31298描述一例 Antigravity 子任务只有 transcript、没有独立会话数据库，因此未进入读取结果。报告针对 nightly 版本，署名说明由 AI Agent 代发并研究；截至查阅日仍是 Open、没有回复。本文没有复现，也不将它当作正式版所有子任务都会漏计的证明。

如果你正在多个线程之间分工，可以先用 T3 Code 工作区检查列清任务和环境，再核对各条调用。线程标题不同，不能证明它们连着不同的账号或费用入口。

Unpriced 表示缺少估价，不能据此判断免费

看到 Unpriced 时，先保留 Usage 显示的完整模型 ID，再查实际连接的服务与价格。

Issue #30671的作者报告，在 T3 Code 0.1.6、Windows 桌面和 OpenCode Go 订阅组合下，部分模型显示 Unpriced。后续回复补充了 nightly 版本的观察，并指出手填价格时漏填缓存读价格可能把估算抬高。回复明确标有 AI 辅助分析，这些数字与归因不作为本文实测结果。

截至查阅日，相关 PR #30683仍未合并；另一个 PR #30681已经关闭但也未合并。不能把“有补丁”或 Closed 当作正式版已修复。

你可以按官方文档给 Usage 补估算价格：

1. 在网页或桌面的 Usage → 环境下拉框 → Model prices 打开价格表；也可以选中 Breakdown 里的未定价模型，再点 Set price。
2. 填写 Usage 实际显示的模型 ID。输入、输出价格单位是 美元／百万 Token。
3. 同时核对缓存读与缓存写价格。明确免费才填 0；不知道价格时先查证，留空有实际计算含义。
4. 检查 Apply to 选择了哪些环境，再点 Save changes。离线目标若显示 Not saved，重连后用 Retry failed saves 完成。

这些设置只改变 T3 Code 的估算，不会修改模型供应商或 Nbility 的收费。文档还说明，保存的价格会替换该环境全部历史记录的自动定价，并由连接到它的客户端共享。因此，修改价格后，旧日期的总额也可能变化。

若只是想补价格，先不要用 Map to 合并模型。它会把原模型的 Token 和费用移到目标模型名下，并使用目标价格；原模型不再单独显示，前后核对反而更难。

缓存价格留空，差额可能就在这里

v0.1.7 的文档与 createOverrideRateTable 实现一致：缓存读和缓存写价格留空时，使用输入价格。 留空不代表自动查到缓存折扣，也不代表免费。

下面只演示标准速度、四类 Token 的计算。模型名 example-model 和价格均为教学假设，不对应某个在售模型或真实账单：

项目	假设用量	假设美元单价／百万 Token	本项估算
未缓存输入	1,000,000	2.00	$2.00
缓存读取	9,000,000	0.20	$1.80
缓存写入	0	2.00	$0.00
输出	100,000	8.00	$0.80
合计	—	—	$4.60

如果只填输入 2、输出 8，把缓存读价格留空，同样的 900 万缓存读取会按每百万 2 美元估算，变成 $18.00。合计就是 $20.80，相差 $16.20，Token 数量完全没变。

本文离线执行了正式版原始计价模块，核对了这两个结果，以及覆盖价格会优先于记录中已有费用的行为。这个验证只说明估价计算怎样工作，没有发送模型请求，也没有验证任何供应商的实际结算。

计算时，用的是未缓存输入加缓存读取、缓存写入和输出。不要把已含缓存部分的“总输入”再加一次缓存 Token。各服务的字段与规则要分别核对；缓存机制本身可以继续读 Prompt Caching 与费用说明。

Limits 没有数字，先去实际账号确认余量

Usage → Limits 展示订阅账号报告的窗口，并且可能合并多个账号。多台环境上的同一个账号会去重。先选单个环境并展开账号信息，看清登录位置、窗口和刷新时间，再与供应商页面对照。

官方文档说明，API Key 账号可能不报告订阅限额。这时没有 Limits 数字，不能据此判断 API 余额为零，也不能判断它没有使用限制。

近期的 Issue #30310讨论 Claude 订阅额度探测失败。11 月 7 日的后续报告仍涉及 nightly 版本；截至查阅日，相关 PR #30999关闭且未合并，PR #31135仍开放。不同回复的环境和观察不同，本文不据此给出统一修复方案，也不建议为了补显示而绕过组织管理设置。

想确认“还能不能用”，先看实际账号页面；想确认“刚才花了多少”，查请求和账单。额度显示缺失与计费错误需要分别调查。

与 Nbility 对账时，先确认请求确实走了这里

T3 Code 可以管理多种连接。一个任务里，Agent 运行工具可能使用订阅，另一个工具则使用独立 API Key；只有实际经 Nbility 发出的请求，才会出现在本站记录里。

按接入基础核对当前工具的 API 地址、协议、令牌和模型。然后选一段容易辨认的短任务，记录开始和结束时间、运行机器、账号标识与模型 ID，等相关请求完成后再比较。不要把 API Key 放进记录或截图。

核对顺序可以这样安排：

1. 在 T3 Usage 中选定环境、时间与模型，记录 Token 分项、是否 Unpriced，以及有无自定义价格或 Map to。
2. 到 Nbility 用量日志查同一时段的请求，核对实际模型、分组、状态及可取得的请求标识。一个 Agent 任务可能包含多次调用，不要只找最后一句回答。
3. 对照账户与计费说明，确认计费单位、分组条件以及最终结算；异步任务需等待结束，再到账单看相同时段的汇总。
4. 若仍有差异，保留时间、模型、请求 ID、Token 分项和脱敏价格配置，提交具体明细。只有总额截图，很难区分漏记录、估价不同和结算差异。

特别留意单位：T3 自定义模型价格填美元／百万 Token；Nbility 的 $ 是站内额度符号。 本站计费文档明确要求分清上游美元价格、站内额度与人民币实付金额，不能只看同一个符号就直接相减。

先核对一段短任务，再扩大到一天或一周。需要理解为什么一次开发任务会有多次模型请求，可以接着看 Agent Token 成本拆解；需要判断真实扣费，则回到实际服务的请求明细与账单。