数え直し直後の最初の累積に前回の主なモデルが無いと reset を検出できず、少なく数える（#5402 の弱点） #5405

この Issue は、クローン teto の依頼で動くマネージャー層（ALT-DEV-Y、mgr-b071b83c）が起こした（2026-10-28）。#5402 のレビューで出た弱点の記録。実害は未確認で、少なく数える側に倒れる弱点。

背景

#5402 は、packages/core/src/usage.ts の detectReset を、「前回にあったモデルが今回の累積に無いこと」を reset としない形に直した（本番で 2026-10-26T23:16Z に、haiku を含まない累積が来て opus の約 108 億を二重に積んだ事象の修正）。reset は「今回にもあるモデルの値が前回より減ったとき」だけになり、次の基準は {...prev, ...next}（今回に無かったモデルの前回値を引き継ぐ）になった。

弱点

resume や /clear で SDK 側の累積が 0 から始まる本当の数え直しのあと、最初の累積に、前回の主なモデル（例: opus）が載らず、別のモデルだけが載ると、reset を検出できない。

• 今回にあるモデル（例: haiku）の値が前回以上なら「減った」と判定されず、reset にならない。
• 基準には前回の opus の大きな累積が残る（引き継ぎ）。数え直し後の opus は 0 から始まるので、新しい opus の累積が前回の値に追いつくまでの消費は、差分が 0（subtract の Math.max(0, …)）で、台帳に積まれない。
• 結果は、数え直し後の opus の消費の取りこぼし（少なく数える）。二重計上（fix: 累積に載らなかったモデルを数え直しと誤認して台帳へ二重に積む #5402 で直したほう）の逆向き。

発生には、数え直しの直後の最初の読みで主なモデルが載らず、かつ載ったモデルが減っていない、という条件が要る。頻度は未測定。

見え方・確かめ方

• 台帳の clone/session の 1 日分が、日誌の turn_usage の合計より少なく出る。turn_usage に reset が付かないまま、sessionId が変わる（または context_usage の増減から resume が読める）日がある。
• 本番の日誌で、turn_usage の sessionId が変わった直後の行の models に主なモデルが無いものを探す。

案（未決。判断が要る）

1. sessionId が変わったときは reset とみなす（ただし resume は同じ id のまま 0 に戻ることがある＝usage.ts の「session id は見ない」コメントの理由）。
2. 全体の cost（sumCostUsd）が前回より減ったときも reset とみなす（今回に無いモデルがあっても、合計が減れば数え直し）。今回に無いモデルがあるだけの fix: 累積に載らなかったモデルを数え直しと誤認して台帳へ二重に積む #5402 の場面（合計は減らない）は reset にならない。誤検出の恐れは小さいが、合計が減らない数え直しは拾えない。
3. 何もしない（少なく数える側は、過大に数えるより害が小さい。台帳は推定値）。

案 2 が最も小さい変更。試験は「数え直しの最初の累積に主なモデルが無い」場面を再現する（直す前は積まれず、直した後は全量が増分）。

触る所

packages/core/src/usage.ts（detectReset・foldUsageSnapshot）、packages/core/src/usage.test.ts。docs/・AGENTS.md は触らない。