TL;DR — Qwen3.8-2.4T-A95B is a 2.4 trillion parameter mixture-of-experts model with 95B active parameters per token and a 1,048,576-token context window. Probes showed it nailing a coding task and a math word problem cleanly, but returning nothing at all on a simple JSON extraction after burning 700 completion tokens and 19.3 seconds. It's a model almost nobody self-hosts — this is a rent-it-by-the-token release, priced at $2/$6 per million tokens.
At some point in a 30-day tour of open-weight models, you stop being surprised by big numbers. Then you see 2.4T in a model name and you're surprised again. Qwen3.8-2.4T-A95B is, per its own Hugging Face ID, exactly what it says: 2.4 trillion total parameters, with 95 billion active per token. That's not a typo-friendly round number — it's the largest open-weight release this series has covered, and it forces a question that matters more than the parameter count itself: who is this actually for?
The shape of the thing
Mixture-of-experts math means the 2.4T figure and the 95B figure aren't in competition — they're both true at once. Every token routes through a 95-billion-parameter slice of the network, but which slice varies token to token, which means the full 2.4T of weights has to be reachable, not just the active fraction. That's the part people miss about MoE at this scale: you don't get to load a "95B model." You need the whole 2.4T resident somewhere, active experts change every forward pass.
The context window is the other headline number: 1,048,576 tokens, exactly 1Mi, per the metadata. Combined with the compute needed to reach that context economically, this reads like a model built for institutional-scale batch work — full repositories, full case files, full transcript archives — not chat turns. Pricing on the hosted API is $2 per million prompt tokens and $6 per million completion tokens, meaning a single maxed-out 1M-token context request costs a bit over $2 just for the input, before you've gotten a word back.
What the probes actually showed
Two of three probes looked genuinely solid. The coding task — write merge_intervals and state its complexity — produced correct, idiomatic code: sort by start, walk once, merge on overlap, and it correctly named the complexity as O(n log n) for the sort, not a lazy O(n) guess. That took 5.1 seconds and 222 completion tokens, about 43.4 tokens/second.
The reasoning probe — a two-pump tank-filling problem — was answered with a clean four-step derivation: net fill rate of 30 L/min for the first 20 minutes, 600 liters added, 1,800 liters remaining, then 20 more minutes at pump A's 90 L/min alone. The arithmetic checks out at every step, and the final answer (20 minutes) is correct. This one ran faster and cheaper in relative terms — 3.8 seconds, 235 tokens, 61.8 tokens/second.
The third probe is the interesting one. A simple instruction — extract vendor, date, and total from an invoice into strict JSON, return only the JSON object — took 19.3 seconds, generated 700 completion tokens, and returned an empty string. Not malformed JSON, not a garbled attempt — nothing visible in the output at all. Whatever those 700 tokens were doing, none of them surfaced as the requested object. For a model this large, on a task this trivial, that's a real miss worth flagging plainly rather than smoothing over. Scale bought correctness on the harder-looking reasoning task and lost it entirely on the "just format this" task — which is a useful reminder that parameter count and task reliability aren't the same axis.
Who can actually run this
This is the section that matters more than any benchmark claim: almost nobody self-hosts a 2.4T-parameter model. Even at aggressive 4-bit quantization, 2.4 trillion parameters lands somewhere north of a terabyte of weights that all need to be reachable for routing, before you add KV cache for a context window that stretches past a million tokens. That rules out a single workstation, a single 8-GPU node, and most private clusters. What's left is exactly what the API pricing implies: this is a rent-it model, served by whoever operates the inference cluster, consumed over an API the same way you'd consume a closed frontier model from a proprietary lab.
So the honest use cases skew toward organizations that have already accepted API-based inference as their operating model and want an open-weight option in that mix — for reasons like avoiding vendor lock-in on model choice, auditing weights for compliance reasons, or fine-tuning downstream on infrastructure they control even if base inference runs elsewhere. A legal team processing thousand-page discovery sets in one context window, a research group needing whole-codebase reasoning without chunking, or an enterprise wanting a second frontier-class model to benchmark against a closed provider's output — those are workloads where the 1M context and 95B active compute earn their price. Casual chatbots, latency-sensitive customer support, or anything running on a laptop are the wrong jobs for this model; a distilled or Nano-class open model wins on cost and latency for those every time.
The other honest use case is signaling: a lab willing to open-weight a 2.4T model is making a statement about where the ceiling on "open" now sits, separate from whether most teams should reach for it. It's the model you point to when someone claims open weights can't compete with closed frontier scale — not necessarily the model you put in production this quarter.
What it says about the open-vs-closed line
Vendor framing around trillion-plus-parameter open releases tends to lean on raw scale as the headline, and Qwen3.8-2.4T's spec sheet — 2.4T total, 95B active, over a million tokens of context — is genuinely at the frontier tier by the numbers alone. But the empty-output result on the JSON probe is a useful counterweight to that framing: scale is necessary for some classes of problem and irrelevant to others, and "biggest open model released this season" doesn't automatically mean "most reliable model for a given task." The coding and reasoning probes suggest real capability sits behind the parameter count. The structured-output miss suggests that capability doesn't automatically generalize to every task shape, even a trivial one. Judge the number on its own terms — it's a serious release — and judge the behavior separately, because they don't always agree.
Tomorrow closes out the season with GLM-5.2 — worth watching to see whether the newest closed-adjacent open release handles the boring tasks as well as the hard ones.
The numbers (measured, not quoted)
I ran three quick probes against Qwen3.8-2.4T (A95B MoE) via a hosted API today before writing this. Small sample, one snapshot in time, routed hardware I don't control — treat these as a smell test, not a benchmark:
| Probe | Wall-clock | Output tokens | Tokens/sec (effective) | Result |
|---|---|---|---|---|
| Code | 5.1s | 222 | 43.4 | completed |
| Reasoning | 3.8s | 235 | 61.8 | completed |
| Structured output | 19.3s | 700 | 36.2 | completed |
Effective tokens/sec includes queueing and time-to-first-token — it's what you actually experience, not peak decode speed.
Model card: context window 1,048,576 tokens · hosted pricing $2/M input · $6/M output · weights: Qwen/Qwen3.8-2.4T-A95B on Hugging Face
Credits — where it's due
- the Qwen team at Alibaba Cloud — for training Qwen3.8-2.4T (A95B MoE) and releasing the weights openly: Qwen/Qwen3.8-2.4T-A95B. Open releases like this are why a series like this can exist at all.
- OpenRouter — the hosted API used for today's live probes and the pricing/context figures.
- The quantizers and runtime maintainers — the mostly-unpaid people who turn every open release into something that runs on real hardware within days.
Top comments (0)