Qwen3.8-Max-0902：価格は据え置き、1 回あたり入力 38 トークン増

Qwen3.8-Max の 0902 スナップショットは前のビルドとまったく同じ料金、入力 100 万トークンあたり $2.00、出力 $6.00 です。同時に、リクエストごとに入力トークンを 38 個多く使います。 長さの異なる 3 つのプロンプトでこの差を測ったところ、毎回 38 でばらつきはありませんでした。以下はすべて 2026 年 9 月 4 日のライブ Ofox カタログと実際の API 呼び出しからのものです。

実測した内容

同じプロンプト、同じパラメータ、2 つのモデル文字列。 違いはどちらのスナップショットが応答するかだけです。

これらは /v1/chat/completions が返す usage.prompt_tokens で、リクエストボディはモデル文字列以外まったく同じです。長さの異なる 3 つのプロンプトで一定のオフセットが出るということは、入力長に比例して伸びるトークナイザーの変更ではなく、すべての呼び出しの先頭に付く固定のオーバーヘッドだということです。

入力 100 万トークンあたり $2.00 なら、38 トークンは 1 リクエストあたり $0.000076 です。数回の呼び出しなら無に等しく、規模が出ると実際の金額になります。

正直にまとめるとこうです。トークン単価は変わらず、呼び出し 1 回あたりの下駄が変わった。それが問題になるかどうかはトークン量ではなくリクエスト回数の関数です。高頻度で短いプロンプトのワークロードが最も影響を受けます。28 トークンのプロンプトに 38 トークンが乗れば、入力側は倍以上になるからです。

価格表は同一

2026 年 9 月 4 日のライブ /v1/models レスポンスの pricing オブジェクトから読み取り、すべてのフィールドが一致します。料金を上げずに能力が上がるのは良いケースです。これらの料金が前世代のフラッグシップや QwenCloud 直接呼び出しとどう比べられるかは、Qwen3.8 Max の料金とアクセスのガイドにあります。

Alibaba が変わったと言っていること

コーディング、協調エージェント能力、視覚理解です。 2026-09-02 スナップショットのカタログ説明は、コーディングと協調エージェント能力の大幅な強化、視覚理解の最適化を挙げつつ、前のビルドの 1M コンテキスト、深い推論モード、画像と動画の入力を明示的に維持するとしています。

この説明に含まれていないのはベンチマークの数字なので、いまリーダーボードに突き合わせて検証できるものはありません。能力の主張はベンダーのものとして扱い、38 トークンの実測を独立に確認できる部分として扱ってください。実際にそれは確認できるからです。

コンテキストウィンドウの行には注釈が要る

どちらのビルドも 1M コンテキストのモデルですが、カタログの報告の仕方が違います。 日付なしのビルドは context_length: 1131072、0902 スナップショットは 1000000 を報告します。説明はどちらも 1M と書き、最大補完もどちらも 131,072 トークンです。

これは能力の削減に見えますが、ほぼ確実に違います。1,131,072 は 1,048,576 に 82,496 を足した値で、きれいな公称値というより入力上限に余裕を足したもののように読めます。1,000,000 のほうが丸いマーケティング上の数字です。安全な読み方は、変わったのはモデルではなく報告の慣習だ、というものです。危険な読み方は、数字が小さくなったから Alibaba がウィンドウを縮めたと決めつけ、存在しないかもしれない制限に合わせて設計することです。

ワークロードが実際に 100 万トークンのコンテキストに近づくなら、カタログのどちらの数字も信用せず、出荷する予定のスナップショットで本当の上限を測ってください。1,000,000 トークン未満はどちらのビルドでも安全です。

それ以外はすべて同じ

パラメータ一覧はバイト単位で同一で、だからこそ移行は文字列 1 つの変更で済みます。

- "model": "bailian/qwen3.8-max"
+ "model": "bailian/qwen3.8-max-0902"

知っておく価値のある罠：空の content

どちらのビルドも推論モデルで、そのため失敗のように見えて失敗ではない結果が出ます。

{"usage": {"prompt_tokens": 66, "completion_tokens": 20,
           "completion_tokens_details": {"reasoning_tokens": 20}}}

補完トークン 20、そのすべてが推論トークンで、content は空文字列で返りました。壊れてはいません。推論モデルで max_tokens を 20 に設定すると、目に見える文字が 1 つも出る前に予算が思考に費やされ、レスポンスは上限で打ち切られます。

直し方は max_tokens を上げることで、リトライでもモデルの切り替えでもありません。実用的なルールとして、推論モデルでは max_tokens が推論と回答の両方をまかなう必要があり、推論はあなたが見るかどうかに関わらず出力料金で課金されます。max_tokens を回答の長さのつもりで見積もることが、動いているモデルを壊れて見せる原因です。

日付を固定するか、ポインタに追随するか

bailian/qwen3.8-max-0902 は固定されており、bailian/qwen3.8-max は固定されていません。

日付付きの文字列を固定するのは次の場合です。

• 出力が再現可能でなければならない。たとえばレビューや承認のプロセスの下にある。
• 大きなプロンプトのライブラリが 1 つのビルドに対して検証済みで、再検証のコストが高い。
• 挙動がいつ変わるかを、本番で気づくのではなく自分で制御したい。

日付なしの文字列を使うのは次の場合です。

• 再デプロイせずに Alibaba の現在の推奨に追随したい。
• プロンプトが十分に頑健で、スナップショットの変更がリグレッションのリスクにならない。

トレードオフはいつものもので、どちらにもコストがあります。固定すれば、自分で動くまで改善が届かなくなる。ポインタに追随すれば、何もリリースしていないのに製品の下のモデルが変わりうる。どちらを選ぶにせよ、意識して選んでください。「最初に打った文字列そのまま」という既定こそが、固定されたままのモデルが静かに時代遅れになる道筋です。

このモデルの位置

より広い顔ぶれの中では、$2.00 / $6.00 の Qwen3.8 Max はフラッグシップ帯の価格です。より安い代替という問いは Qwen3.8 Max 対 DeepSeek V4 Flash が扱い、コーディングのバックエンドとして走らせる話は Codex CLI 設定ガイドが扱っています。後者はまさに、0902 スナップショットが最も改善したと主張しているワークロードです。

出典

• https://ofox.io/models/bailian/qwen3.8-max-0902
• https://ofox.io/models/bailian/qwen3.8-max

価格、コンテキスト長、パラメータ、モダリティは 2026 年 9 月 4 日にライブの Ofox /v1/models エンドポイントから読み取りました。38 トークンの差は同日、各モデルに対してリクエストボディをモデル文字列以外同一にした /v1/chat/completions の実呼び出しを 3 回ずつ行って測定しました。