Qwen3.8-Max-0902: Same Price, 38 More Input Tokens per Call

The 0902 snapshot of Qwen3.8-Max costs exactly what the previous build costs, $2.00 per million input tokens and $6.00 per million output. It also spends 38 more input tokens on every request. We measured that gap on three prompts of different lengths and it was 38 tokens every time, with no variance. Everything below is from the live Ofox catalog and live API calls on 4 September 2026.

What We Measured

Same prompt, same parameters, two model strings. The only difference is which snapshot answers.

Those are usage.prompt_tokens from /v1/chat/completions, same request body except for the model string. A constant offset across three different prompt lengths means it is fixed overhead prepended to every call, not a tokenizer change that would scale with input length.

At $2.00 per million input tokens, 38 tokens costs $0.000076 per request. That is nothing on a handful of calls and real money at scale:

So the honest summary is: the per-token price did not change, the per-call floor did, and whether that matters is a function of your request volume rather than your token volume. High-frequency short-prompt workloads feel this most, because 38 tokens against a 28-token prompt more than doubles the input side.

The Price Sheet Is Identical

Read from the pricing object on the live /v1/models response, 4 September 2026. Every field matches. A snapshot that improves capability without raising the rate is the good case; the Qwen3.8 Max pricing and access guide covers how those rates compare to the previous flagship generation and to calling QwenCloud directly.

What Alibaba Says Changed

Coding, collaborative agent ability and visual understanding. The catalog description for the 2026-09-02 snapshot cites significantly enhanced coding and collaboration-agent capability with optimised visual understanding, while explicitly retaining the 1M context, the deep reasoning mode and image and video input from the previous build.

What that description does not include is a benchmark number, so there is nothing here to verify against a leaderboard yet. Treat the capability claim as the vendor’s, and treat the 38-token measurement as the part that is independently checkable, because it is.

The Context Window Row Needs a Caveat

Both builds are 1M-context models, but the catalog reports them differently. The undated build reports context_length: 1131072; the 0902 snapshot reports 1000000. Both descriptions say 1M, and both report the same 131,072-token maximum completion.

That looks like a capability cut and almost certainly is not one. 1,131,072 is 1,048,576 plus 82,496, which reads like an input ceiling plus some allowance rather than a clean advertised figure; 1,000,000 is the round marketing number. The safe reading is that the reporting convention changed, not the model. The unsafe reading is to assume from a smaller number that Alibaba shrank the window, and then design around a limit that may not exist.

If your workload actually approaches a million tokens of context, measure the real ceiling on the snapshot you intend to ship rather than trusting either number in the catalog. Everything below about 1,000,000 tokens is safe on both.

Everything Else Is the Same

The parameter list is byte-identical, which is what makes the migration a one-string change:

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

A Trap Worth Knowing: Empty Content

Both builds are reasoning models, and that produces a result which looks like a failure but is not:

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

Twenty completion tokens, all of them reasoning tokens, and content came back as an empty string. Nothing broke. With max_tokens set to 20 on a reasoning model, the budget was spent thinking before a single visible character was emitted, and the response was cut off at the ceiling.

The fix is to raise max_tokens, not to retry or to switch models. The practical rule: on a reasoning model, max_tokens has to cover the reasoning plus the answer, and reasoning is billed at the output rate whether or not you ever see it. Budgeting max_tokens as if it were answer length is how a working model looks broken.

Pin the Date, or Follow the Pointer

bailian/qwen3.8-max-0902 is frozen. bailian/qwen3.8-max is not.

Pin the dated string when:

• Output has to be reproducible, for example under a review or approval process.
• A large prompt library is validated against one build and re-validation is expensive.
• You want to control when behaviour changes rather than discovering it in production.

Use the undated string when:

• You would rather track Alibaba’s current recommendation without a redeploy.
• Your prompts are robust enough that a snapshot change is not a regression risk.

The trade is the usual one, and it has a cost either way: pinning means you stop getting improvements until you act, and following the pointer means the model under your product can change without you shipping anything. Whichever you choose, choose it deliberately, because the default of “whatever string I typed first” is how a pinned-forever model quietly ages out.

Where This Model Sits

Against the wider field, Qwen3.8 Max at $2.00 / $6.00 is a flagship-tier price. Qwen3.8 Max vs DeepSeek V4 Flash covers the cheaper-alternative question, and the Codex CLI configuration guide covers running it as a coding backend, which is the workload the 0902 snapshot claims to improve most.

Sources

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

Prices, context lengths, parameters and modalities were read from the live Ofox /v1/models endpoint on 4 September 2026. The 38-token difference was measured with three live /v1/chat/completions calls per model the same day, identical request bodies except for the model string.