コスト目安と計測

まず中央値を初期予算に使う

SpecRunnerの表示額はproviderの請求額ではなく、記録したtokenを内蔵価格表へ当てたUSD概算です。契約プラン、quota、割引、価格改定、未計測tokenはproviderの請求明細で確認します。

docs/cost.mdに記録された2026-06-10時点のスナップショットです。このproject自身のarchive 278 requestを、当時のAnthropic list rateで集計しています。

基準値。 初回は1 requestあたり$8.58前後を粗い基準にし、同じrequest typeを5〜10件実行した後にjob statsの自分の中央値へ更新します。

token総数だけで高い・安いを決めない

follow-up、output repair、再実行で取得したusageもrunner内で加算されます。resumeは完了済みstepを飛ばしますが、再開後に発生したturnは新しいusageとして記録されます。

fresh inputを見るときだけcache readを引きます。 内部評価資料ではfresh input = inputTokens − cacheReadInputTokensとして読みます。これはcontextの再利用率を見る指標で、SpecRunnerが表示するUSD計算式そのものではありません。

main checkoutから3段階で確認する

# 1 runのstep別見積もり
npx specrunner job show <job-id>

# 1 requestのtoken内訳
npx specrunner usage my-feature

# 全runの分布と機械集計
npx specrunner job stats
npx specrunner job stats --json

1. 01
   個別run

   job showで高いstepとmodelを特定します。

2. 02
   同種run

   job statsでcost中央値、duration中央値、convergence平均を並べます。

3. 03
   時系列

   --jsonを保存し、request typeやmodel構成を変えた前後で比較します。

usage <slug>はtoken内訳、引数なしのusageはarchive集計とcost、job statsはactiveとarchiveを含むrun統計です。目的を混同しません。

4種類のtokenをmodel単価で合算する

estimated USD =
  inputTokens / 1,000,000 × input rate
+ outputTokens / 1,000,000 × output rate
+ cacheReadInputTokens / 1,000,000 × cache-read rate
+ cacheCreationInputTokens / 1,000,000 × cache-write rate

単位はUSD / 1M tokens。価格表の基準日はAnthropicが2026-06-07、OpenAIが2026-06-12です。[1m] variantは別keyとして解決されますが、現行表では対応するbase modelと同じflat-rate近似です。

OpenAIの複数modelは近似値です。 現行ソースは個別の公開価格がないmodelをo3 tierなどで近似しています。$?やnullだけでなく、数値が出ても近似かどうかをこの表で確認します。

認証方式と実際の支払いを分ける

credentialの解決順とruntime別の環境変数は権限・認証・環境変数を参照してください。

金額capではなく増加要因を制御する

現行SpecRunnerにmaxCostUsdのような金額上限はありません。provider側のspend alertを最終境界にし、SpecRunnerでは高コスト化する条件を狭めます。

1. 01
   requestを絞る

   受け入れ基準と非対象を明記し、不要なdesign・fixer往復を減らします。

2. 02
   modelを役割で分ける

   品質が必要なstepだけ高単価modelを使い、既知の軽作業は低単価modelを検証して使います。

3. 03
   turnと時間を制限する

   Claude localではsteps.*.maxTurns、各runtimeではtimeoutMsを明示します。

4. 04
   反復を観測する

   cost急増時はjob statsのconvergenceとjob showのstep内訳を確認します。

5. 05
   請求側で止める

   providerのbudget・alert・quotaを設定し、SpecRunnerの推定値だけに依存しません。

model、maxTurns、timeoutMsの設定例は設定レシピで確認できます。

0・不明・部分集計を区別する

pricing.tsは会計台帳ではありません。 価格表は静的で、請求条件を自動取得しません。月次予算ではjob stats --jsonを運用指標、provider明細を金額のsource of truthとして扱います。