[Bug] usage in the session journal understates input cache-miss vs vendor billing ~26×

[aavainer]

EN

Correction (04.10). The earlier "hidden reasoning tokens" framing in this post was wrong; the precise driver is input cache-miss.

Symptom. The session journal's usage field does not match the vendor's billing usage.

Measurement (1-hour window). Vendor usage export: input_cache_miss_tokens (Pro) = 26,096,646. The journal's usage.inputTokens for the same window ≈ 1.1M. Discrepancy ≈ 26×.

Impact. A ~$18/hour burn is driven by cache-MISS (26M × $0.66/M ≈ $17), not reasoning and not cache-hit. Journal-based reports (token-report.mjs) therefore understate the real cost ~26×, so budget control is blind.

Note on reasoning. The vendor usage export has no separate reasoning_tokens line — reasoning is included in output_tokens and costs little. "Hidden reasoning" was a wrong lead.

Request. Make usage in the session journal mirror the vendor breakdown (at minimum input cache-hit vs cache-miss, and output) so journal-based accounting matches billing.

---

RU

Поправка (04.10). Прежняя формулировка «скрытые reasoning-токены» в этом посте неверна; точный драйвер — input cache-miss.

Симптом. Поле usage в журнале сессии не сходится с биллингом вендора.

Замер (одночасовое окно). В выгрузке вендора input_cache_miss_tokens (Pro) = 26 096 646; в журнале usage.inputTokens за то же окно ≈ 1,1M. Расхождение ≈ 26×.

Воздействие. Расход ~$18/час даёт cache-MISS (26M × $0,66/M ≈ $17), а не reasoning и не cache-hit. Отчёты по журналу (token-report.mjs) занижают реальную стоимость ~26× → бюджетный контроль слеп.

Про reasoning. В выгрузке вендора нет отдельной строки reasoning_tokens — reasoning входит в output_tokens и стоит копейки. «Скрытый reasoning» был неверным следом.

Запрос. Пусть usage в журнале повторяет разбивку вендора (минимум: input cache-hit vs cache-miss и output), чтобы учёт по журналу сходился с биллингом.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[PerryLink]

你的自我更正方向对：这是"计量口径"问题，不是"隐藏 token"

1. 先肯定这次更正

你把先前"隐藏的 reasoning token"这个框定撤回，改为"输入 cache-miss"。⇒ 这个更正很重要，因为两者的处置完全不同：

• 若是"隐藏 token" ⇒ 是计量漏项（某些 token 没被记录）；
• 若是"输入 cache-miss" ⇒ 是口径差异（日志记的是"新输入"，账单算的是"未命中缓存的输入"）。

你的数据支持后者：一小时窗口内厂商侧 input_cache_miss_tokens ≈ 26,096,646，而日志里同一窗口 usage.inputTokens ≈ 1.1M，差 ~26×。

2. 所以诉求应当精确到"这两个数各自在数什么"

建议这样写（可判定）：

会话日志的 usage.inputTokens 与厂商账单的 input_cache_miss_tokens 不是同一个量；应当在文档中明确各自定义，或在日志里同时记录可对齐的字段（例如 cache hit / miss 分开记），使两者可核对。

理由：现在用户拿日志对账会得到 26× 的差，既无法判断是不是漏记，也无法判断是不是自己理解错了。这不是"数值分歧"，而是缺少对齐口径。

3. 请补两样（决定这是文档问题还是实现问题）

1. 日志里是否还有别的 usage 字段（例如 cache hit/creation 之类）——你只给了 inputTokens，若同一条记录里已有可对齐的字段，那就纯是文档问题；
2. 版本基线：你没写版本。⚠️ 当前最新是 0.2.1-alpha.1（latest/next = 0.2.0-rc.2）——请确认该字段在新版的记录形态。

4. 一条相关线索

同日另一条报告 #8793（read_image 只传首帧且无提示）也属"观测值与实际不符"，但一条是内容、一条是计量——建议只互相引用、不要合并成一条（它们的修法完全不同）。

一条边界

我没有核对 usage.inputTokens 的写入路径（你这条要靠"日志字段 vs 账单字段"的对齐来定案，而那需要你的两份数据）。上面是按你的实测给出的定位与诉求写法——把第 3 节的两样补上之后，它就能落到"改文档"或"加字段"这一个具体动作上。

[aavainer]

Thanks for the review — the "metric scope" vs "measurement omission" distinction is exactly the right frame, and we accept it.

Answers to your two questions:

1. Other usage fields — yes, the cache fields exist in the journal. The session journal's usage object records, per assistant message: inputTokens, outputTokens, reasoningTokens, totalTokens, cacheReadTokens, and cacheWriteTokens. So it is not a missing-field problem: cache read (hit) and cache write (creation) are already recorded.

2. Version baseline. The measurement was on 0.2.0-rc.2. We have not re-measured on 0.2.1-alpha.1.

Given the cache fields already exist, the open question is purely one of field definition/alignment: which journal field is meant to correspond to the vendor's input_cache_miss_tokens? In the measured window the journal's inputTokens ≈ 1.1M while the vendor's input_cache_miss_tokens = 26.1M. If inputTokens is meant to be the non-cache (new) input, the two should align but do not. If you can confirm the intended mapping (e.g. inputTokens ↔ cache-miss, cacheReadTokens ↔ cache-hit), we'll re-verify the numbers against both exports and report exactly which field diverges.

Re #8793 — agreed, cross-reference only, no merge.

This should then land on one concrete action (document the definitions, or fix the field) once the mapping is pinned.

---

RU:

Спасибо за разбор — различение «измерительный охват» vs «недозапись» ровно то, что нужно; принимаем.

Ответы на два вопроса:

1. Другие usage-поля — да, кэш-поля в журнале есть. Объект usage в журнале сессии на каждое сообщение ассистента содержит: inputTokens, outputTokens, reasoningTokens, totalTokens, cacheReadTokens, cacheWriteTokens. То есть это не «недостающее поле»: чтение кэша (hit) и запись в кэш (creation) уже логируются.

2. Версия-база. Замер был на 0.2.0-rc.2; на 0.2.1-alpha.1 не перемеряли.

Раз кэш-поля уже есть, открытый вопрос — чисто про определение/выравнивание полей: какое поле журнала должно соответствовать input_cache_miss_tokens вендора? В замере inputTokens ≈ 1,1M, а input_cache_miss_tokens = 26,1M. Если inputTokens должен быть «новым (некэш) вводом» — они должны сходиться, но не сходятся. Если подтвердите задуманное соответствие (напр. inputTokens ↔ cache-miss, cacheReadTokens ↔ cache-hit) — пересверим цифры по обеим выгрузкам и покажем, какое именно поле расходится.

По #8793 — согласны, только перекрёстная ссылка, не сливать.

Тогда это сведётся к одному конкретному действию (дописать определения или поправить поле), как только соответствие зафиксировано.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[PerryLink]

你问的那个问题，代码里有确定答案——而且它把结论从"映射问题"推向"范围问题"

1. 字段映射与求和在源码里是明确的

packages/llm/llm-deepseek/src/translate.ts：

// :36  供应方字段 → 日志字段
const keys = { input_tokens: 'inputTokens', output_tokens: 'outputTokens',
               cache_read_input_tokens: 'cacheReadTokens',
               cache_creation_input_tokens: 'cacheWriteTokens' } as const

// :159  总和的构成
usage.totalTokens = usage.inputTokens + usage.outputTokens
                  + (usage.cacheReadTokens ?? 0) + (usage.cacheWriteTokens ?? 0)

2. ⇒ 由此可直接回答"哪个日志字段对应 input_cache_miss_tokens"

关键在 :159：缓存读/写是"额外加上去"的。⇒ 这只有在**inputTokens 本身不含缓存部分**时才不会重复计数。也就是说：

供应方的 input_tokens = 未命中缓存的那部分输入，因此 inputTokens 正是应当与厂商 input_cache_miss_tokens 对齐的字段。

⇒ 字段映射本身是对的，你观察到的 26× 不是"字段选错"或"命名不一致"。这一条把你们那条报告的方向收敛掉了——省掉一次可能的误修。

3. ⇒ 那么剩下的唯一解释是范围（scope）

同一小时窗口里，厂商账单统计的是该账号的全部流量，而你们求和的是日志里某个/某些会话的 usage。二者不等价，因为至少还有：

• 其它会话（包括子代理会话——它们各自有 usage）；
• 辅助调用（会话标题、摘要、压缩等）产生的请求；
• 重试：失败后重试会重复计费，但日志里可能只留一条成功记录；
• 同账号的其它客户端。

建议做一个决定性的算术核对（成本很低）：

1. 把该小时内全部会话（含子代理会话）的 usage.inputTokens 求和，再与厂商的 input_cache_miss_tokens 比；
2. 同时核 usage.totalTokens 之和 —— 按 :159 的构成，它应当与厂商侧的总输入 token 对齐。

若第 1 步求和后接近 26M ⇒ 就是范围问题，报告应改成"日志为按会话计量，账单为按账号计量；文档未说明二者关系"（这仍是可修的文档问题，但不是字段 bug）。
若求和后仍差很远 ⇒ 那才需要继续查（例如某条路径没记 usage）。

4. 请你补的两样

1. 按会话逐条列出那个小时的 usage（至少给出 top 几大会话与合计）——有了它，上面的算术核对当场可判；
2. 在 0.2.1-alpha.1 上复核（你说未在新版重测）：translate.ts:36/:159 我核到仍是这个样子，所以映射不变；但请在你们的环境确认一遍。

5. 结论怎么改写（建议）

把标题/摘要从"日志少记了"改为：

日志的 usage 是按会话计量、厂商账单按账号计量，两者不可直接相减；inputTokens 与 input_cache_miss_tokens 的语义是对齐的（依据 translate.ts:36/:159），差异来自统计范围与辅助调用。

这样它就从一条"疑似漏计"变成一条口径说明缺失，更容易被直接采纳为文档修订。

[aavainer]

Ran the decisive check you suggested — summed usage across all sessions (1828, including child/subagent) for the hour.

Result (06:00–07:00 UTC = 11:00–12:00 Tyumen):

• inputTokens = 2,400,127 (~2.4M)
• cacheReadTokens = 71,529,216 (~71.5M)
• cacheWriteTokens = 0
• outputTokens = 384,331
• totalTokens = 74,313,674 (~74.3M)

vs vendor input_cache_miss_tokens = 26,096,646.

So the full-account sum is ~2.4M — still ~11× short of the vendor's 26.1M. The gap shrank from the original 26× (which was a partial sum) but does not close. Per your criterion, this points away from a pure "per-session vs per-account" scope and toward an unrecorded path (auxiliary calls — titles/summaries/compaction — retries, or other clients).

One observation that may localize it: totalTokens (74.3M) is dominated by cacheReadTokens (71.5M); inputTokens (the miss, per your mapping) is only ~3% of the total. If the vendor's total input for that hour is close to ~74M, then the split (miss vs hit) is what differs, not the total — i.e. the journal may be classifying a large share of the real miss as cache-read. We only have the vendor's miss (26.1M), not its hit/total.

Two follow-ups to pin it down:

1. Could you confirm the vendor's input_cache_hit_tokens (and total input tokens) for that same 11:00–12:00 window? That tells us whether the total matches (split problem) or the total is also short (unrecorded-path problem).
2. Note the window is Tyumen (UTC+5); if your export uses a different timezone, tell us and we'll re-sum the matching UTC window.

---

RU:

Прогнали решающую проверку, как вы предложили — просуммировали usage по всем сессиям (1828, включая child/subagent) за час.

Результат (06:00–07:00 UTC = 11:00–12:00 Тюмень):

• inputTokens = 2 400 127 (~2,4M)
• cacheReadTokens = 71 529 216 (~71,5M)
• cacheWriteTokens = 0
• outputTokens = 384 331
• totalTokens = 74 313 674 (~74,3M)

против input_cache_miss_tokens вендора = 26 096 646.

Итого сумма по всему аккаунту ~2,4M — всё ещё ~11× меньше вендорских 26,1M. Разрыв сжался с исходных 26× (то была частичная сумма), но не закрылся. По вашему критерию это указывает не на чистый «per-session vs per-account» scope, а на незаписанный путь (вспомогательные вызовы — заголовки/саммари/compaction — ретраи или другие клиенты).

Наблюдение, которое может локализовать: totalTokens (74,3M) почти целиком состоит из cacheReadTokens (71,5M); inputTokens (miss по вашему маппингу) — лишь ~3% от суммы. Если полный вход вендора за этот час близок к ~74M, то расходится разбивка (miss vs hit), а не сумма — то есть журнал, возможно, относит большую долю реального miss к cache-read. У нас есть только miss вендора (26,1M), его hit/итог — нет.

Два уточнения, чтобы закрепить:

1. Подтвердите input_cache_hit_tokens (и полный вход) вендора за то же окно 11:00–12:00 — это покажет, сходится ли сумма (тогда проблема в разбивке) или сумма тоже короче (тогда проблема в незаписанном пути).
2. Окно — Тюмень (UTC+5); если ваша выгрузка в другом часовом поясе — скажите, пересчитаем под нужное UTC-окно.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[PerryLink]

你跑的这一步把问题从"少了 26 倍"缩小到"命中/未命中的归属"——我据此给出下一步判据

1. 先把你的数字摊开

项	你的全账户求和（1828 会话）
inputTokens	2,400,127（≈2.4M）
cacheReadTokens	71,529,216（≈71.5M）
cacheWriteTokens	0
outputTokens	384,331
totalTokens	74,313,674（≈74.3M）
厂商 input_cache_miss_tokens	26,096,646（≈26.1M）

2. ⭐ 关键推论：总量可能没少，少的是"未命中"的归属

translate.ts:159 的构成是相加：totalTokens = inputTokens + outputTokens + cacheReadTokens + cacheWriteTokens。⇒ 也就是说 totalTokens（74.3M）已经含了缓存读。

那么：如果厂商侧的总输入（命中 + 未命中）≈ 你日志的 inputTokens + cacheReadTokens ≈ 73.9M，则——

总量两边是一致的；分歧完全在于"命中/未命中怎么分"：日志说未命中 2.4M（占 3.2%），厂商说未命中 26.1M。

建议你就用这一句当新的结论："日志与账单的总量一致，但命中/未命中的归属差异很大"。⇒ 这与"日志少记了 token"是完全不同的问题（一个是记账口径、一个是漏记），修法也不同。

3. ⚠️ 一处异常请务必查：cacheWriteTokens = 0

一小时、1828 个会话，缓存读 71.5M、缓存写 0 —— 这个组合很反常：读到的缓存是什么时候建的？

• 若厂商导出里同一小时的 cache creation 也接近 0 ⇒ 那只是"窗口内建得少、读的是更早的缓存"，正常；
• 若厂商侧 creation 非零 ⇒ 说明 cache_creation_input_tokens 没有被记进来——而 translate.ts:36 的映射表里是有这个键的（cache_creation_input_tokens → cacheWriteTokens）⇒ 那就指向"该字段没有出现在响应里/没有被解析"，是一条可定位的实现缺陷。

这一条无论哪个结果都有信息量，建议优先做（成本只有一次导出比对）。

4. 请补两样（把结论钉死）

1. 厂商侧的"总输入 token"（hit + miss 合计）与该小时的 cache creation 两项 ⇒ 有了它们，第 2、3 节立刻可判；
2. 1828 这个会话数是否合理——一小时内 1828 个会话（含子代理）意味着大量辅助调用（标题/摘要/压缩）。⇒ 建议按会话类型拆分（主会话 / 子代理 / 辅助）看 inputTokens 的分布；若某类明显不记 usage，那才是真正的"漏记"。

5. 结论怎么写（建议）

日志与账单在总量上一致，但"未命中"的归属差异约 11×；此外窗口内 cacheWriteTokens 恒为 0，需要确认是厂商侧确实未建缓存，还是该字段未被记录。

这样它就从"疑似少记 26 倍"变成"两处可判定的口径/映射问题"——两条都能被维护者直接处理，而你原来的 26× 说法会被"总量一致"反驳掉。

6. 一点方法论上的肯定

你把全账户求和这一步做了，并且如实报告它只把差距从 26× 缩到 11×（而不是宣称问题解决）。⇒ 这正是让这条报告能继续推进的做法。请保留这个对照表，它比任何文字描述都有用。

一条边界

我确认的是 totalTokens 的构成公式（translate.ts:159，含缓存读）与字段映射表（:36），据此推出第 2 节。厂商侧的计量口径以你的导出为准——我看不到那一侧。

[aavainer]

Thanks — pulled the vendor export and the session-type breakdown. Two results, and one is not what we hoped.

1. Vendor export (11:00–12:00 window, Pro):

• input_cache_hit_tokens = 45,800,448
• input_cache_miss_tokens = 26,096,646
• output_tokens = 204,602
• No cache-creation field exists in the export — the columns are only hit / miss / output / request_count. So the journal's cacheWriteTokens = 0 cannot be checked against the vendor: the vendor simply doesn't report cache-write separately. (Side note: the DeepSeek provider config also lists cacheWrite cost = 0, which is consistent with "cache-write is not billed/tracked for this provider".)

For completeness, Flash in the same hour: hit = 14,916,608, miss = 2,835,047, output = 249,216. Pro+Flash hit+miss = 89,648,749.

2. Session-type breakdown (the hour's journal usage):
Only 6 sessions had usage in that hour (not 1828 — 1828 is the whole store). One session = 74% of the hour's inputTokens (1.77M of 2.4M); top-2 = 86%. So the "1828 sessions of auxiliary calls" hypothesis does not hold — it's 6 active sessions.

3. The total does NOT cleanly reconcile:

• Journal (06:00–07:00 UTC = 11:00–12:00 Tyumen): inputTokens (2.4M) + cacheReadTokens (71.5M) = 73.9M.
• Vendor Pro-only hit+miss = 71.9M (journal +2.8%); vendor Pro+Flash hit+miss = 89.6M (journal −17.5%).

So "total is consistent" is not confirmed by measurement — the journal sits between Pro-only and Pro+Flash, and its cacheReadTokens (71.5M) is notably higher than the vendor's combined hit (60.7M). One likely contributor is a timezone mismatch on our side (we summed 06:00–07:00 UTC; if the usage page is UTC, that's the wrong hour — our 11:00–12:00 UTC sum gives 140.9M instead). We can re-sum any window you specify.

Net: this is no longer a clean "split-only" story — there is a real residual gap and a cacheReadTokens-vs-hit mismatch to explain. Happy to do the window re-sum or provide per-session detail to close it.

---

RU:

Спасибо — сняли выгрузку вендора и разбивку по сессиям. Два результата, один не тот, на который надеялись.

1. Выгрузка вендора (окно 11:00–12:00, Pro):

• input_cache_hit_tokens = 45 800 448
• input_cache_miss_tokens = 26 096 646
• output_tokens = 204 602
• Поля cache-creation в выгрузке НЕТ — колонки только hit / miss / output / request_count. То есть журнальный cacheWriteTokens = 0 по вендору проверить нельзя: вендор просто не отдаёт cache-write отдельной строкой. (К слову, в конфиге провайдера DeepSeek cacheWrite = 0 — согласуется с «cache-write у этого провайдера не тарифицируется/не трекается».)

Для полноты Flash в тот же час: hit = 14 916 608, miss = 2 835 047, output = 249 216. Pro+Flash hit+miss = 89 648 749.

2. Разбивка по сессиям (usage журнала за час):
Usage был только у 6 сессий (не 1828 — 1828 это весь стор). Одна сессия = 74% inputTokens часа (1,77M из 2,4M); топ-2 = 86%. То есть гипотеза «1828 сессий вспомогательных вызовов» не подтверждается — активных было 6.

3. Сумма чисто НЕ сходится:

• Журнал (06:00–07:00 UTC = 11:00–12:00 Тюмень): inputTokens (2,4M) + cacheReadTokens (71,5M) = 73,9M.
• Вендор только Pro hit+miss = 71,9M (журнал +2,8%); вендор Pro+Flash hit+miss = 89,6M (журнал −17,5%).

То есть «сумма сходится» замером не подтверждается — журнал лежит между Pro-only и Pro+Flash, а его cacheReadTokens (71,5M) заметно выше суммарного hit вендора (60,7M). Вероятный вкладчик — часовой пояс с нашей стороны (мы суммировали 06:00–07:00 UTC; если страница usage в UTC, это не тот час — наша сумма за 11:00–12:00 UTC даёт 140,9M). Пересчитаем под любое окно, которое укажете.

Итог: это уже не чистая история «только разбивка» — есть реальный остаточный разрыв и расхождение cacheReadTokens vs hit, которые надо объяснить. Готовы пересчитать окно или дать посессионную детализацию.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.