Qwen 3.8 Max API Pricing: 16 Thinking Tokens Beat the Off Switch

Qwen 3.8 Max bills $2 per million input tokens and $6 per million output, and its cheapest reliable configuration is not the one the API seems to offer. Turning thinking off with reasoning_effort: "none" dropped our two-step arithmetic task from 4/4 correct to 1/6, while granting a hard budget of just 16 thinking tokens restored 6/6, averaging a fifth fewer output tokens than the default. Launch week produced loud capability claims and little to check them against: no model card, no public benchmark table, internal-only evals, which Hacker News was quick to flag. Billing behavior is different, because anyone with an API key can measure it. We measured qwen3.8-max on day one through the Synthorai gateway: every thinking control the surface accepts, the reasoning tax at each setting, the implicit cache’s floor and build lag, the 1M-context claim, and what carries over from Qwen 3.7.

TL;DR

• qwen3.8-max’s seven reasoning_effort values collapse into four measured behaviors: off, a 4,096-token cap, a 16,384 cap, and unbounded.
• thinking_budget is exact: request 16 tokens and the meter reads 16; the ceiling is 262,144.
• With thinking off, 2-hop math fell to 1/6 correct; a 16-token budget scored 6/6 for less.
• The implicit cache builds in under 0.3 seconds and reads at $0.25/1M, but nothing caches below roughly a 4,300-token prompt.
• Input caps are exact and fail-loud: 991,808 (thinking off), 983,616 (thinking on).

What do the thinking controls on Qwen 3.8 Max actually do?

Three parameters are live, and they are not the three the documentation lists. Third-party docs describe reasoning_effort with three values (low, medium, xhigh, default xhigh). The surface we measured accepts seven: none, minimal, low, medium, high, xhigh, and max; an invalid value is rejected with that exact allowlist. Alongside it, the native thinking_budget (a positive integer up to 262,144) and enable_thinking (boolean) pass through to the provider, which validates them itself: a budget of 0 or 262,145 comes back as a 400 quoting the bound.

On ordinary tasks the effort levels are indistinguishable. Across trivial Q&A, 2-hop math, and a medium combinatorics problem, low, medium, high, xhigh, and the default all burned reasoning tokens in the same noisy band; nothing separated them. The separation only appears on a task that wants to think for tens of thousands of tokens. On a prime-counting problem whose unconstrained run burned 45,129 reasoning tokens, the levels finally started to bind:

The mental model that fits every observation: each effort level is a preset thinking-budget cap, and the seven names collapse into four behaviors. Off is one (none and enable_thinking: false behave identically). Minimal and low share the same 4,096-token cap. Medium quadruples it to 16,384. High, xhigh, max, and the default form the fourth tier: none of them bound on this task, burning between 35K and 45K tokens across runs, which is ordinary variance at this depth. If the top three differ at all, the split sits above 45K thinking tokens, deeper than most production traffic ever goes; the docs’ claim that the default is xhigh is consistent with everything we measured. The split is stark: every capped run answered wrong, every uncapped run answered right. Below the cap, behavior is identical across levels, which is why the dial feels dead on everyday traffic. Above it, the cap truncates thinking mid-task. If you want a specific ceiling, skip the presets and set thinking_budget directly; the next section takes that parameter apart.

How does thinking_budget actually work?

It is enforced to the token, it is a ceiling rather than a quota, and a mid-sized cap can make a task cost more than setting no cap at all. thinking_budget is DashScope’s native integer parameter (1 to 262,144, documented default 131,072, inherited from the open-weight Qwen3 family) that sets the maximum reasoning tokens for a call. Requests of 0 or 262,145 are rejected with a 400 quoting the range. Below the ceiling nothing changes: a budget of 8,192 on a task that naturally thinks for a few hundred tokens burned 331 and 485, exactly as if no budget were set. At the ceiling, enforcement is token-exact: budgets of 16, 64, and 256 stopped reasoning at precisely 16, 64, and 256 in every run.

What happens at the cutoff is the interesting part. The model does not abandon the work; it stops reasoning and finishes the job in the visible answer. On a medium combinatorics task (count domino tilings of a 2x12 grid), every budget produced the right answer, but the totals are not what you would predict:

The curve is not monotonic. A 256-token budget cost 2.5x more than no budget: the model spent its allowance starting a reasoning chain, lost it mid-thought, and re-derived the answer step by step in the visible channel. The tightest budget beat the mid-sized ones because a 16-token allowance is too small to start anything, so the model goes straight to compact visible work. Three rules fall out. First, tiny budgets are a real lever on shallow-to-medium work: 16 tokens went 6/6 on our 2-hop math batch at 98-161 total tokens against the default’s 126-207. Second, never deploy mid-sized caps on traffic of unknown depth; they land in the dead zone where the cap truncates real reasoning and you pay for the work twice (the deep-task rows above, 4,096 and 16,384, are the same failure at scale, and there they also answered wrong). Third, a binding budget changes the shape of the output: capped runs answer with their work shown, which matters if a parser expects a bare result.

How much of the day-one documentation survives measurement?

About half, and the split is worth publishing because nothing else about this launch is independently checkable yet. Every number below is from our own meter and probes:

The pattern favors the billing plane: everything that decides what you pay is precise and honestly enforced, while the parameter documentation lags what the surface actually does.

Does turning thinking off save money?

It saves tokens and costs correctness, and there is a better trade two lines away. In our quotable batch of 2-hop arithmetic (1850 crates times 24 parts, 75% shipped, 3,120 arrive), the default configuration went 4/4 at 126-207 completion tokens per call. reasoning_effort: "none" produced 4-5 token answers and went 1/6. The same prompt with thinking_budget: 16 went 6/6 at 98-161 completion tokens, cheaper than the default and as accurate, on this task class. One-hop arithmetic stayed 3/3 even at none, so the off switch is safe for lookups and single-hop transforms; it is multi-step work that collapses. This is not a 3.8 regression: qwen3.7-max with thinking off went 3/6 on the identical batch.

The dead zone described in the budget section has a dollar figure on hard tasks. On the deep prime-counting run, the low preset burned its 4,096 thinking tokens, spilled 13,882 more of visible candidate-checking, and still answered wrong: $0.11 for an incorrect answer, versus $0.27 for the default’s correct one. The off switch shows the same physics on hard tasks: with thinking disabled outright, both 3.8 and 3.7 poured a 13-15K-token enumeration into the visible answer, one landing the count and one missing it by a single prime, in single shots each. A budget that binds mid-reasoning can raise total spend while lowering quality. Cap thinking on tasks you know are shallow; let deep tasks think.

Is the 1M-token context window real?

Effectively yes, with exact and honest limits. The API accepts up to 991,808 input tokens with thinking off and 983,616 with thinking on, and both bounds are enforced fail-loud: an oversized request is rejected with a 400 that quotes the exact limit, rather than silently truncating your document. Needle recall worked at every size we probed, 161K, 677K, and 919K tokens, returning the planted override code verbatim in 11 to 63 seconds. A 919K-token request costs about $1.84 at list price, so the window is real but a full-window call is a design decision, not a default.

What does the implicit cache deliver, and where is the floor?

The fastest cache build we have measured, behind an unusually high floor. Repeating a salted 6,103-token prompt produced a hit on the very next request 0.3 seconds later; there is no warm-up window to engineer around, unlike Gemini’s tens-of-seconds build. Hits kept coming at +5 and +15 minutes with no re-prime, and the entry was gone by +45, so the working lifetime sits somewhere between 15 and 45 minutes of silence. Reads bill at $0.25 per million, 0.125x the input rate, and there is no write premium; the discount arrived automatically in the cached_tokens field and the metered cost.

The floor is the catch. A 4,221-token prompt never produced a hit; a 4,360-token one did, and every first hit was exactly 4,096 tokens. Below roughly 4.3K tokens of prompt, this cache does not exist for you, a sharp contrast with Claude’s 1,024-token minimum and Kimi K3’s small-block automatic caching. Above the floor, hits quantize in 128-token blocks (we observed 4,096, 8,320, 12,544, and 16,768), but coverage of the primed prefix ranged from 51% to 96%, so budget on discounting most of a long prefix, not all of it.

Do structured output and tool calls pay the reasoning tax?

By default yes, and they are the safest place to cut it. Strict json_schema output works, and it is doing real enforcement: the same extraction without a schema came back wrapped in markdown fences. With the default configuration, a four-field invoice extraction burned 252 reasoning tokens before emitting 57 tokens of JSON. With reasoning_effort: "none" it produced valid, correct JSON in 54 total tokens, a 5.7x cut; thinking_budget: 16 sat in between. Tool selection behaved the same way: the model called the right function with thinking off at a third of the default’s tokens. Single-step extraction and routing are exactly the shape where the off switch is safe, and at $6/1M output the habit compounds.

One more billing note for agent builders: the API returns the full chain of thought in reasoning_content, and the docs instruct multi-turn clients to send it back unmodified. The instruction is not enforced. We replayed turns with the reasoning included, omitted, and deliberately tampered; all three were accepted, and short-chain accuracy was unaffected. Replayed reasoning bills as ordinary input tokens, so omitting it is a real saving on multi-turn traffic until you see quality reasons not to.

What carries over from Qwen 3.7, and what changed?

The tokenizer is unchanged and your token budgets port directly. Identical English, Chinese, Japanese, and code corpora tokenized to identical counts across qwen3.8-max, qwen3.7-max, qwen3.7-plus, qwen3.6-flash, and qwen3.5-flash, so per-language cost planning from our tokenizer-by-language study carries over unchanged.

Two things did change. First, 3.8-max carries a fixed prompt overhead its siblings do not: the same one-character message counted 49 prompt tokens on 3.8-max against 11 on every other Qwen we probed, a constant +38-token rider per call. It is noise on long prompts and a measurable percentage on short, high-frequency ones. Second, thinking is always available rather than a mode switch, with the seven-level dial and exact budget parameter above; 3.7’s controls were coarser. One pricing clarification, because two schemes circulated at the preview: the Token Plan subscriptions ($6 to $68 monthly, with deep off-peak discounts) price Alibaba’s own apps, not the API. Through the API you pay the $2/$6 list rate, and our gateway meter matched it to the fourth decimal on every call in the study.

FAQ

Can you turn off thinking on Qwen 3.8 Max?

Yes, fully: reasoning_effort: "none" (or enable_thinking: false) eliminates reasoning tokens entirely. Reserve it for single-hop work. On 2-hop arithmetic it scored 1/6 in our batch while a 16-token thinking_budget scored 6/6 at comparable or lower token counts, so the floor setting for multi-step traffic should be a small budget, not the off switch.

What is the minimum prompt size for Qwen 3.8 Max’s cache?

About 4,300 tokens in our probes: a 4,221-token prompt never hit, a 4,360-token one did, and first hits are always exactly 4,096 tokens. Below the floor no discount exists; above it, reads bill at $0.25/1M with no write premium and the entry is readable 0.3 seconds after priming.

Is reasoning_effort supported on Qwen 3.8 Max?

Seven values are accepted (none, minimal, low, medium, high, xhigh, max), but levels behave as thinking-budget caps that only differ once a task thinks past them. For deterministic control, set thinking_budget directly: it is enforced token-exactly, rejects 0, and tops out at 262,144. Client tooling currently disagrees about which tiers exist; the list above is what the surface accepted on day one.

Do you have to send reasoning_content back in multi-turn conversations?

The documentation says yes; the API does not check. Omitted and even tampered reasoning history was accepted without error or short-chain accuracy loss in our probes, and replayed reasoning bills as normal input. Skipping the replay is a legitimate cost lever until your own evals show quality loss on long chains.

Measured 2026-08-03 through the Synthorai gateway against qwen3.8-max (comparison arms on qwen3.7-max, qwen3.7-plus, qwen3.6-flash, qwen3.5-flash): dial-acceptance, garbage-value, and max_tokens boundary probes, a 45K-natural-burn deep task to bind the effort caps, a fixed quotable batch for the accuracy cliff (n=4-6 per arm, salted), salted cache pairs with 2-3s pacing plus gap ladders, needle and overflow probes at 161K-919K tokens, and identical four-corpus tokenizer counts. Dollar figures are billed-cost readings from the gateway meter at list rates ($2/$6 per 1M). Preview-period discounts, rates, and behavior may change; verify against your own usage records.

← Back to blog