Optio クレジットの仕組み — Jev API のコストモデル

計算式

すべてのリクエストは ceil(入力トークン / 1,000) クレジットかかり、1 呼び出しの最低は 1 クレジットです。出力トークンは常に無料 — 1 つの判断は数十トークン程度で、これには課金されません。リクエストが失敗した場合（上游エラー、タイムアウト、プロバイダーの過負荷）、課金はゼロです：クレジットはモデルの実行前に確保され、失敗時には確保分が返還されます。

呼び出しの前、ゲートウェイはペイロードを約 4 文字 = 1 トークンとして概算を確保します。呼び出しの後、モデルの usage レポートに基づく実際の入力トークン数で精算されるため、台帳の記録は概算ではなく実態を反映します。3 つの数字 — 概算、実際、課金額 — は usage.input_tokens、usage.credits と台帳で確認できます。

実サイズでの計算例

• 1 行チケットのはい／いいえ判定、入力約 150〜300 トークン → 1 クレジット。
• サポートトリアージ：チケットに 3 つの質問（はい／いいえの緊急度、ルーティングの選択、フラストレーションのスコア）、約 400〜500 トークン → 1 クレジット。
• ポリシーの段落を state に入れた JSON ツール呼び出しに対するエージェントガードレール、約 1,600 トークン → 2 クレジット。
• CV 全文を state に入れた履歴書スクリーニング、約 8,000 トークン → 8 クレジット。

この数字に隠れたバッチングの法則：最低値は質問単位ではなくリクエスト単位なので、同じ状態に対する最大 8 質問までなら、合計が 1,000 トークン未満に収まる限り 1 クレジットを超えません。同じ作業を質問ごとの呼び出しに分けると、何倍ものコストになります。

パックの内容

• Starter — $10 → 100,000 クレジット。最低クレジットの判断 1 回あたり $0.0001。
• Pro — $100 → 1,000,000 クレジット。クレジット単価は同じ。強みはより高いレート制限（600 対 120 req/min、同時 10 対 3）とチャージ回数の減少です。
• Team — $1,000 → 11,000,000 クレジット。10% のボーナスとコラボレーション付き：招待したチームメイトが残高を共有します。
• Free — 新しいワークスペースには 5 クレジットが付与され、Playground はブラウザで無料です（クレジットには一切触れません）。

クレジットに有効期限はなく、ワークスペース間でも移動しません。使わない月のコストは $0 — 利用のタイミングを合わせるべきサブスクリプションは存在しません。

プラン別のレート制限

同時実行数と 1 分あたりリクエスト数は、ワークスペース内で最も上位のプランに従います：

• Free：20 req/min、同時 1 件。
• Starter：120 req/min、同時 3 件。
• Pro：600 req/min、同時 10 件。
• Team：2,000 req/min、同時 30 件。
• Enterprise：6,000 req/min、同時 100 件 — 要相談。

いずれかの上限を超えると、Retry-After ヘッダーに加えて X-RateLimit-Remaining と X-RateLimit-Reset 付きの 429 が返ります — バックオフすべきことを示す、リトライ安全なシグナルです。

トラフィックからの予算見積もり

課金は決定論的 — トークン数だけ — なので、請求は予測できます：1 日の判断数 × 判断あたりの平均クレジット。判断の半分が 1 クレジットの最低値に乗り、1 日 50,000 件走るなら約 50,000 クレジットで、Starter 価格でおよそ $5/日です。Team パックを積むと実効単価は約 3 分の 1 削減されます（$1,000 で 1,100 万クレジット 対 $100 で 100 万クレジット）。

節約になる 2 つの運用習慣

第一に、質問をバッチングする。1 つのリクエストが同じ状態に対するはい／いいえ 1 件、choice 1 件、score 1 件を乗せているなら（サポートトリアージを 1 リクエストに）、1 クレジットの最低値の中で 1 回の課金です。同じ 3 つを 3 つのリクエストとして送ると 3 クレジットの課金になります。最大 8 質問まで一緒に乗せられるので、state は一度組み立て、分岐の可能性があるものはすべて尋ねてください。

第二に、質問ではなく state を削る。課金はペイロード全体の入力トークン数で計算されるため、1 行の質問のために 20,000 文字の文書を state に貼ると請求の大半を占めます — ceil(20,800/1,000) = 21 クレジットで、1 ではありません。該当するのが 1 段落だけなら、送る前に自分でその段落を抽出してください。モデルは指定された部分を読みますが、トークン数を決めるのは自分です。

2 クレジットが 1 クレジットに勝つとき

• 一度取得して複数の判断で再利用する 2,400 トークンのポリシー文書 — 同じリクエストで 3 つの質問を尋ねれば 3 クレジットの 1 回で済み、1 質問ずつの呼び出しで 3 回再送する（同じ作業で 9 クレジット）より安くなります。
• 約 8,000 トークンの履歴書を 8 つの必須要件で 1 回スクリーニングする：8 質問の単一リクエストなら 8 クレジット。state を毎回個別に載せるなら 1 呼び出し 8 クレジット × 8 回…
• 実のところこの比較は反復です：state が乗るのは必要なリクエストだけです。本当のレバーは 1 クレジットの最低値です：1,000 トークン未満なら追加の質問は無料。超えると state の 1 キロバイトごとにさらに 0.25 クレジットです。

台帳に記録されるもの

精算されたリクエストごとに、ダッシュボードの台帳に行が書き込まれます：reserved（概算）、charged（実際の入力トークン / 1000、最低 1）、request_id、そしてどの API キーが消費したか。失敗したリクエストは課金ゼロの返金行として書き込まれるため、月末の突合は request_id でフィルタするだけです。課金がおかしいと思ったら、サポートがログの request_id から追跡できます — 値を伝えてください。