GPT-6 Astraの記事は、発表の要約かベンチマーク表の抜粋か、触った形跡のない仕様の言い換えがほとんどだ。どれも「週枠を管理しながら使う側」の情報を持っていない。私はDevin CLIから gpt-6-astra-medium を業務で回しており、先週は週枠を使い切るペースになった。

そこで、枠がどこで溶けたのかを手元の記録で確定した。Devin CLIはローカルにsession DBを持ち、すべての呼び出しのinput token実数が残る。これを5日分・49セッション分集計し、自作の週次ゲージ較正 (前に書いた整数% flip法) の実測logと突き合わせた。結果、両者は小数点以下まで一致し、内訳は想定と違っていた。最大の支出は、Reply with exactly: t1 — 「t1」とだけ返すよう求める計測用セッション ($13.61) だった。

この記事を読み終えた時、手元に残るもの:

枠の会計方法 — session DBのどこを読み、どう単価を掛けるか (再現script同梱)
ゲージと手元計算が一致することの検算 (2 window・円単位で一致)
前windowの消費内訳 — 計測テスト約8割・X投稿起草約2割弱・記事起草は僅少
枠が溶ける3つの構造 — ターン毎の全文脈再送・固定文脈26.7k・軽タスクの階層ミス
階層ルーティングの節約額 — 同じ行動をLuna階層で行った場合の比較

枠の会計方法 — session DBの読み方

Devin CLIは ~/.local/share/devin/cli/sessions.db (SQLite) に全sessionを記録する。課金に直結するのは message_nodes テーブルの metadata に入る num_tokens_preceding — そのassistant応答時点でモデルに送られた文脈のtoken数 (API応答由来の実数)。

ここで1つ、集計基準の選択が効く。課金量は「合計 (sum) 基準」で数える。 multi-turnの会話では、毎ターン全文脈が再送される。1ターン目は27k・2ターン目は28k…と送信ごとに課金対象になるため、セッション内の全assistant nodeの num_tokens_preceding を足したものが、そのセッションのinput課金量になる (「最大値」でも「最終値」でもない)。ここを間違えると、後で示すmulti-turnセッションの消費を桁で低估する。

単価は devin models list のrate card表示。astraは:

gpt-6-astra-medium  [1M context, $10 / 1M Input · $1 / 1M Cached input · $50 / 1M Output]

サブスク枠のゲージはこのrate cardの定価換算で動いている — cap自体 (週$32.0・日$16.0・日曜17:00リセット) は、整数%表示の連続flip間隔から確定した較正値で、方法は前に書いた (末尾にリンク)。

検算 — ゲージと手元計算が一致するか

まず会計方法が正しいことの確認。2つのwindowで、上記のsum基準・定価換算をAstra全セッションに適用し、ゲージ実測log (毎日16:57に記録している) と比べた。

window	session数	input tok (sum)	input$	output$	手元計算	ゲージlog
08-30〜09-06	25	2,468,207	$24.68	$1.28	$25.96	$25.96
09-06〜 (水17時時点)	24	671,996	$6.72	$0.10	$6.81	$6.81

2 windowとも、小数点以下まで一致した。output側はassistant応答の文字数をtoken数の近似に使っているが、金額がinput支配 (Astraはinput単価が$10/Mと最重量) なので誤差は埋まる。この一致が取れる限り、「今週あとどれだけ使えるか」をDBから事前に計算できる。

前windowは全体で$42.19の消費 — cap表示$32.60に対して超過していた。この超過の内訳に行く。

内訳 — 最大の支出は「t1」

前windowのAstra消費 $25.96 を、セッションの目的別に分解する (input側のみ・定価換算):

順位	セッション	assistant応答数	input tok (sum)	金額	目的
1	09-06 11:52	57	1,361,453	$13.61	会話累積の計測
2	09-06 12:29	24	317,652	$3.18	同上
3	09-06 12:22	12	158,502	$1.59	同上
4	09-06 03:49	4	56,341	$0.56	記事起草
5〜	(多数)	2	約27kずつ	約$0.28ずつ	X投稿起草・記事起草

目的別の合計はこうなる:

計測テスト3セッション: $19.14 (約8割)
X投稿の起草 (品質が飽和している軽タスク・毎朝cronで6〜8件): $4.11 (約2割弱)
記事起草 (長文): $1.43 (残り僅少)

1位のセッションの中身を示す。Reply with exactly: t1、Reply with exactly: t2…と1行応答を要求するメッセージを順に送り、文脈がどう累積するかを見る計測だ (cacheの挙動を確かめるために自分で組んだもの)。所要23秒・57応答。各応答の num_tokens_preceding は約26.7kでほぼ一定 — 会話本体は1行ずつなのに、毎ターン約26.7kの固定文脈ごと再送されている。これを定価で掛けると57 × 約26.7k = 136万token = $13.61になる。

つまり先週の超過は、高額モデルでの「計測」が主因だった。書きたかったのはX起草の無駄だが、DBを開くまで計測側が最大支出であることは見えていなかった。

当window (09-06〜) は別の顔になる: $6.81のうちX起草17件で$4.61 (約7割)。計測をAstra以外に移してからは、今度は毎朝の軽タスクが主因になった。

枠が溶ける3つの構造

上記を一般化すると、枠の消費は3つの構造の掛け算で決まる。

ターン毎の全文脈再送 (複利)。 multi-turnでは毎ターン全文脈が課金対象に乗る。1行応答ですら57ターンで$13.61に達する。セッションのターン数が、タスクの重さと独立に課金を決める。
固定文脈26.7kが毎呼び出しに乗る。 1回の呼び出しのinputのほぼすべてが、こちらが書いていないCLI側の文脈 (システム文・rules・skills一覧) である。X起草のpromptは数百tokenなので、inputのほぼ全額が固定文脈に対する課金になる。この構造自体は前回の記事でSHA1比較により確定済み。
軽タスク・計測が最高単価で走る。 品質が飽和しているタスクや、応答が1行の計測を、input $10/Mの階層で実行すること。タスクの重さと単価のミスマッチが、頻度 (毎朝6〜8件) で積み上がる。

cacheが効けば構造1と2は安くなる — cached inputは$1/M (定価の10分の1) で、同一会話での連続利用には効く。公式docsも "requests to the same model leverage caching and reduce overall token usage" と案内しており、前回の記事で18ターンの実測を行い、定価換算$4.77相当の会話が実課金$0.95に収まることを確認した。ただし本稿の検算はone-shot主体のwindowで取っているため、「枠ゲージの単位にcache割引がどこまで反映されるか」は本稿では測っていない。分けて書くべきところを混ぜないため、ここまでにしておく。

運用設計 — 階層ルーティングによるコスト削減

3つの構造それぞれに対応を割り当てる。LLMの階層 (Astra/Sol/Luna) への振り分けは、品質が飽和したタスクから順に下げるのが原則になる。比較のため「同じ行動を別階層で行った場合」の定価換算を並べる (Luna = gpt-5-6-luna-medium, input $0.2/M):

対象	Astraで実行	Lunaで実行	割合
計測3セッション (前windowの実績)	$19.14	$0.38	50分の1
X起草1件 (in 約27.1k + out 300)	$0.28	$0.006	47分の1
記事起草1件 (難物長文)	$0.29〜$0.56	(品質要件次第)	—

計測・テストはLuna階層で、回数を設計して。 計測の目的は数を数えることで、モデルの能力は不要である。前windowの超過はこれだけで防げた。
X投稿起草はLunaへ。 3行の起草で品質は飽和している (過去の実タスク比較でも、軽タスクのモデル差は小さかった)。毎朝6〜8件 × $0.28が、$0.006に落ちる。
multi-turnの作業セッションはターン数を意識する。 前回記事のworkaround (MCPサーバーを1つにまとめて文脈を安定させる) でcacheを実効させられる。
Astraは難物長文に温存する。 長文の記事化でお手本水準を満たす品質を出せる場所に残す価値はある (実タスク比較の判定と一貫)。

週capが$32の環境で、Astraを使う場所を「難物長文のみ」に絞ると、X起草と計測をLuna階層へ落とすだけで、週の大半の枠が自由になる。逆に、何も管理しなければ — 先週のように — 1.5日前後で枠に達する。

限界 (実測できていないこと)

集計は当machineのsession DBのみ。別マシンの利用は載らない (実績として週あたり$12程度ある)。よって「残り」の正本は直近のゲージ読取であり、本稿の内訳も当machine分の内訳である
cap ($32.0/$16.0) は自環境の較正値で、公式に公表された仕様ではない。Devin側の変更で動く
output tokenは文字数近似 (thinking分は本地では見えない)。input支配のため検算は一致したが、output主体のワークロードではこの方法は使えない
2 window分 (5日間) のn=2である。週ごとの構成が違えば内訳も変わる
cache割引のゲージ反映の有無は、one-shot主体のwindowでは検証していない (本文の通り、前回記事の課金側実測と分けて記載した)

参考

週次ゲージのcap較正 (整数% flip法): https://qiita.com/jinno_ai/items/8110c5e1b94010b5bc84
固定文脈26.7kのSHA1確定とcache workaround: https://qiita.com/jinno_ai/items/d9eea3a72922ff77f699
実タスクでのモデル階層判定 (軽タスクは下位階層で十分): https://qiita.com/jinno_ai/items/0d46c7cb0f36343943cf

本稿の生データ (抽出SQL・window再計算script・セッション別集計・ゲージlog) は assets/qiita/astra-quota-burn-record/ に置いた。recompute.py で検算を再現できる。

なお、この計測・運用はJapan LaunchOpsで行っている。モデル別のコスト管理・階層ルーティングの設計相談は日本語AI評価のページで受け付けている。