astra、sol、terra、lunaの選び分け

四つのモデル、一つのエンドポイント、一つの予算。新しいアカウントが本当に抱える問いは、どれが一番強いかではありません。手元の仕事のどの部分をどれに回すか、です。そしてその答えが一つの名前だけになることはありません。これはリクエストの種類ごとに一度下すルーティングの判断であり、そのあとで自分のポータルに並ぶ明細と突き合わせて確かめるものです。以下が、その判断を下すべき順番です。

まず terra から

terra は妥協案ではなく既定値です。公表されている役割は日常のアシスタント業務 — RAG、エージェント、ツール、コーディング — であり、これだけで製品が実際に送るリクエストの大半が収まります。ふつうの会話、決まった構造を埋める抽出、そして考えるより打つ時間のほうが長いコーディング補助です。入力では sol の半分、sol の 1 に対して 0.5、出力の重みは sol の 5 に対して 3 です。

ですから新しい種類のリクエストはまずそこで走らせ、結果には正直でいてください。terra の答えがそのまま出せる品質なら、正しいモデルを見つけたうえで請求の下半分しか払っていないということです。上に移すのは、指し示せる証拠 — 人に見せられる失敗例 — があってから下す判断であって、念のために上げておくものではありません。

リクエストの一群を sol に上げるとき

sol は料金表全体の基準点です。sol の入力トークン一つが一クレジットで、このページの他のすべての数字はそれに対する比率です。sol の公表された役割は深い推論、難しいコーディング、Codex型のタスク、リサーチ — この一文がそのまま移行の判定基準になります。推論の深さが目に見えて効くときに、その種類のリクエストを sol に上げてください。terra が周りを回り続ける難しいバグ、途中の各段階が正しくなければ結論も正しくならない多段の分析、ファイル全体を同時に頭に入れないと通らない変更です。

この移行の代償は terra の入力の二倍、出力は三分の二増しです。0.5 と 3 に対して 1 と 5。うまくいっていなかった種類のリクエストが通るようになるなら安い値段ですし、もともと問題のなかった種類に払うなら高い値段です。移すのはアプリケーションではなくその種類だけにしてください。この四つのどれも全体設定ではありませんし、このページで一番安いのは、そもそも上げなかったリクエストです。

astra は何のためにあるのか

astra は100万トークンのコンテキストウィンドウで動く最先端の推論で、最も難しい仕事のためのモデルです。そして意識して使うように値付けされています。入力 2.5、出力 12.5、sol の 1 と 5 に対して。これは警告ではなく使い方の指示として読んでください。astra は、出す前の最終確認、誰かがそれを見て動く分析、二度と読み返されない一発勝負の作業 — つまり答えを間違えた代償が使ったトークンより高くつく仕事のためのものです。

この判断に入らないものが一つあります。長さです。ここではどのモデルにも長いコンテキストの割増はありません。各モデルの長コンテキスト料金は自分の短コンテキスト料金と一行ずつ同じなので、長い文書だからといって送り先のモデルが変わることはありません。仕事の難しさで選び、入力の大きさはそのままにしておいてください。

luna が裏の量を引き受ける

製品が送るものすべてに推論モデルの価値があるわけではありません。分類、タグ付け、短い要約、その項目がどのキューに入るかの判定 — すべてのレコードに対して走り、単体では誰も読まない処理 — は luna の担当で、その公表された役割は高速な下書き、分類、要約、大量のチャットです。入力 0.05 は sol の二十分の一で、出力の重みは 0.3 です。

ただしプロンプトは軽く保ってください。そうでなければ節約分をそのまま返上することになります。裏で回るジョブに文脈全部は要りません。主力アシスタントを賢くしている長い system prompt は、分類器の中ではたいてい死んだ重りです。単価が二十分の一という節約は、トークンを二十倍送った時点で消えます。対象の項目とラベルだけを送り、それ以外は送らないことです。

四つを混ぜ、そのうえで請求を確かめる

トークンあたりのクレジットを、モデル別・種別に。このサイトが他のすべてを値付けしているカタログからそのまま引いたもので、上の各段落が比率として語っていたのはこの四行です。

ここまでのどれも、一度選んだら固定される設定ではありません。四つのモデルは一つのエンドポイントと一つのキーを共有していて、モデルはすでに送っている body の中の一つのフィールドです。安く済ませたいリクエストで一語、絶対に正しくあってほしいリクエストで一語、書き換えるだけです。

POST /v1/chat/completions

{
  "model": "terra",
  "messages": [
    {"role": "user", "content": "このチケットを一行で要約してください。"}
  ]
}

コードがすでに OpenAI 流のモデル名を指定している場合は、それが属する階層として読まれます。ですから何に変えるか決めている間も、いまの設定のまま動き続けます。混ぜて試すのが安上がりなのはこのためです。一種類のリクエストを一週間だけ別のモデルに流すために、何かを移行する必要はありません。

ループを回すエージェントには、さらに二つ守るべきことがあります。一つは、毎ターンの先頭を安定した前置きに保つこと — system prompt、ツール定義、ターン間で変わらない指示です。キャッシュされた前置きから読み戻されたトークンは、そのモデル自身の入力料金の十分の一で課金されます。毎ターン prompt を組み直すループは、同じ言葉に毎周フル料金を払うことになります。もう一つは、階層のルーティングを習慣ではなく意図で決めることです。次に何をするか決めるプランナーはたいてい sol か astra に値し、その手順を実行するワーカーは terra、結果を後から整理して片づける一巡は luna です。一つのエージェント、三つのモデル、意図してそうしています。

そのうえで確かめてください。すべてのリクエストは上の表の料金に照らしてポータルに一件ずつ明細化されます — どのモデルか、どの種別のトークンか、何クレジットか。ですから自分が回しているつもりの組み合わせは、推測ではなく検証できるものになります。上に書いたすべてを意見ではなく手順に変えるのは、この部分です。このページのルーティングをそのまま持っていき、自分の実トラフィックを一週間通し、そして明細を読み返してください。