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

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

まず terra から

terra は妥協案ではなく既定値です。公表されている役割は速く効率的な日常業務 — エージェント、ツール、コーディング、コンピューター操作、視覚タスク — であり、これだけで製品が実際に送るリクエストの大半が収まります。ふつうの会話、決まった構造を埋める抽出、考えるより打つ時間のほうが長いコーディング補助、そして画面を読んで操作するエージェントの一手です。入力は 0.55、出力は 2.75 で、どちらも sol-6.1 や sol-6 の半分です。

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

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

sol-6.1 は料金表全体の基準点です。sol-6.1 の入力トークン一つが1.1クレジットで、このページの他のすべての数字はそれに対する比率です。sol の公表された役割は深い推論、難しいコーディング、エージェント型のタスク、リサーチ — この一文がそのまま移行の判定基準になります。推論の深さが目に見えて効くときに、その種類のリクエストを sol に上げてください。terra が周りを回り続ける難しいバグ、途中の各段階が正しくなければ結論も正しくならない多段の分析、ファイル全体を同時に頭に入れないと通らない変更です。terra が動かしているモデルについて、提供元自身の案内も同じことを言っています。最も複雑なコーディングには、sol-6.1 と astra のほうが引き続き強い選択肢です。

sol-6.1 か sol-6 に移すと、その種類のリクエストの費用は倍になります。入力は terra の 0.55 に対して 1.1、出力は terra の 2.75 に対して 5.5 です。うまくいっていなかった種類のリクエストが通るようになるなら見合う値段ですし、もともと問題のなかった種類に払うなら高い値段です。移すのはアプリケーションではなくその種類だけにしてください。この五つのどれも全体設定ではありませんし、このページで一番安いのは、そもそも上げなかったリクエストです。

astra は何のためにあるのか

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

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

luna が裏の量を引き受ける

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

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

sol-6.1、sol-6とluna-6、GPT-6世代

SolのGPT-6.1モデル。ファミリーで最も新しく、入力トークン1つが1.1 AIクレジットです。 SolのGPT-6世代。入力トークン1つが1.1 AIクレジットです。 LunaのGPT-6世代。ここで公示している中で最も低い単価です。 既存の連携のため、sol と luna は引き続きモデル名として使えます。現在は sol-6.1 と luna-6 で動作し、両モデルの料金で課金されます。GPT-5.6 Terra を指定したリクエストは terra が処理し、terra は GPT-6.1 で動作します。sol-6.1やluna-6を自分で指定するのも、このページのほかの変更と同じく一語の書き換えです。かかった分はポータルの明細でリクエストごとに確かめられます。

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

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

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

POST /v1/chat/completions

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

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

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

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