Atria Dawn: GLM-5.2 underneath, and what its four launch numbers count

mdjsonmcpcopy↗ai

2026-10-15 · 23 min · agents · benchmarks · mixture-of-experts · glm · sparse-attention

Why read this

Notable· top 60%

Atria Preview measured from its headers and diffed against GLM-5.2, and each launch number traced to the metric it actually counts.

• Checked against the source
• Concrete numbers to act on
• Explained from first principles

·Agents & harnesses·Needs datacenter GPUs·MIT·Practitioner model

How this was scored

Is it new?

1 of 3: An incremental tweak

Can I trust it?

3 of 3: Reproduces the headline result, or shows from primary files it is wrong

Can I run it?

1 of 3: API-only, gated or restrictive licence

Will I understand it?

2 of 3: Mechanism from first principles with figures

Can I act on it?

2 of 3: A concrete recipe, numbers or comparison

Will it last?

1 of 3: Relevant for months

Does it affect many?

1 of 3: A specialist community

Only here?

2 of 3: A teardown or measurement few others did

Score 61 of 100, ranked 318 of 577 rated articles. Each question is answered 0–3 by hand, and a 3 is rare. How articles are scored

On 15 October the Atria team at the Shanghai Artificial Intelligence Laboratory announced Atria Dawn, "the official release". The post calls it "a 700B agentic foundation model for long-horizon tasks", says it was "upgraded from Preview" to a 512K context, and lists four numbers: AutomationBench 54.7%, WideSearch 84.8%, Workspace Bench 66.1% and MLE Bench 88.2%.

Three things are worth knowing before reading those numbers:

• Only the Preview has weights. The September Preview is on Hugging Face under MIT. Dawn itself is API-only; its row on GitHub says "Coming soon".
• It is not an InternLM model. The Hugging Face org is internlm, but the card says Atria is built on Z.ai's GLM-5.2. I checked that claim against the files, tensor by tensor, and it holds.
• The four numbers count four different things. One is a pass rate with no partial credit. One is an F1 score the release never names. One is an LLM judge's rubric score. And 88.2 on MLE-bench is a HumanRank: the share of Kaggle entrants the agent beats. It is not a medal rate.

Throughout, measured means I computed it from a file. Reported means the publisher's figure, not re-run. Reasoned means my arithmetic on the other two.

What is actually public

I searched the Hugging Face API under both internlm and atria-asi, queried ModelScope's Shanghai_AI_Laboratory namespace, and cloned the GitHub repo at commit 9182d35. (It was then named Atria-Dawn-Preview; by 16 October it had been renamed Atria-Dawn, and the old name redirects.) Here is what exists (measured, 15 October):

The GitHub README was updated for the launch. It lists Atria Dawn and Atria Dawn FP8 as "Instruct model (full release)", context 256K, with "Coming soon" where the download links go. The homepage's Hugging Face, GitHub and ModelScope buttons point at #. So the model you can download is the Preview, created on 11 September. The model the launch numbers describe is reachable only through the API.

That fixes how the rest of this page is labelled. Architecture facts come from the Preview's files and are measured. Dawn's improvements come from Atria's site and README and are reported. Nothing Dawn-specific can be checked from weights yet.

Under the hood: GLM-5.2, tensor for tensor

The Preview's config.json names the architecture GlmMoeDsaForCausalLM, model type glm_moe_dsa. That is the GLM-5 family's class, and the card says so in words: "Built on the 744B-parameter MoE GLM-5.2 foundation model". The paper, arXiv 2609.15818, says the same and cites Z.ai.

I diffed it against zai-org/GLM-5.2 four ways (all measured):

1. Config. Every architecture key is identical: 78 layers, hidden size 6,144, 256 routed experts, 8 per token, the same attention and indexer settings, the same 1,048,576 max_position_embeddings. The only differences are a bos_token_id Atria adds, a moe_router_dtype it drops, and the transformers_version string.
2. Tensor names. Both checkpoints hold exactly 59,585 tensors, and the symmetric difference of the two name sets is empty.
3. Tokenizer. tokenizer.json and tokenizer_config.json have the same content hash in both repos.
4. Weights. They are not the same. I range-read the first 64 KB of five tensors from Atria, GLM-5.2 and GLM-5.3, and compared each pair as a relative L2 distance.

Atria sits a few percent from GLM-5.2 and about three times further from GLM-5.3. That is the signature of a model fine-tuned from GLM-5.2, which is what the card claims. Five slices are a sample, not a proof that every tensor moved. Still, they rule out both a re-upload and a GLM-5.3 base.

So Atria is not built on InternLM or Intern-S2, the lab's own scientific MoE. The internlm org name is the lab's account, not the lineage. Everything new in Atria is post-training, on top of the base that the GLM-5.2 article takes apart. It is the same move Z.ai made with GLM-5.3, whose weights also sit on the identical backbone.

The mechanism, from the files

Because the architecture is GLM-5.2's, the interesting engineering is Z.ai's. It is worth walking through anyway, because it sets what Atria costs to run and what "700B" and "512K" can mean.

A sparse MoE: 256 experts, 8 per token

Each of the 78 decoder layers has an attention block and a feed-forward block. In layers 0 to 2 the feed-forward block is a dense SwiGLU MLP of width 12,288. In the other 75 it is a mixture of experts:

• 256 routed experts, each a SwiGLU of width 2,048: gate, up and down projections, $3 \times 2048 \times 6144 = 37{,}748{,}736$ parameters.
• 1 shared expert of the same shape, which every token runs.
• A router. It scores the 256 experts with a sigmoid, adds a learned per-expert bias for load balancing (topk_method: noaux_tc, the bias tensor stored in F32), keeps the top 8, renormalises their weights and scales the sum by 2.5.

Sum the shapes from the headers and the checkpoint holds 753,329,940,480 parameters (measured). 9,952,920,576 of those sit in layer 78, the multi-token-prediction (MTP) layer used to draft tokens for speculative decoding. Take it out and the backbone is 743,377,019,904. That is the "744B" on the card, and the same count the GLM-5.2 article gives. The launch post's "700B" is a rounding-down of it.

Routed experts are 96.2% of the checkpoint (reasoned: 724.8B of 753.3B). That ratio is why the model is cheap per token relative to its size. A token touches 8 of 256 experts in each MoE layer:

$N_\text{fixed}$ is everything a token always runs: attention, indexers, the dense layers, the shared experts, routers, norms and the output head. Here $k = 8$. That gives 41,250,530,304 with the embedding table counted and 40,298,947,584 without it (measured). Z.ai's "40B active" is the second.

The ledger above is that sum. Slide $k$ to see the active count move by 2.83B per extra expert per token (reasoned: $75 \times 37{,}748{,}736$), and toggle the embedding and MTP layer to see which convention a given "active" figure uses.

Attention: MLA plus a sparse indexer

Attention is DeepSeek-style Multi-head Latent Attention (MLA) with DeepSeek Sparse Attention (DSA) on top, both straight from GLM-5.2. The shapes in the headers (measured):

• Queries go through a rank-2,048 bottleneck (q_a_proj 6,144 to 2,048, then q_b_proj to 64 heads of 256).
• Keys and values are compressed into a 512-wide latent plus a 64-wide rotary key (kv_a_proj_with_mqa, 6,144 to 576). Only those 576 numbers per token per layer go into the cache. kv_b_proj expands the latent back into 64 heads at attention time.
• The indexer is a small 32-head scorer (index_n_heads: 32, head dim 128). For each query it rates every cached token and keeps the top 2,048. The main attention then reads only those 2,048 entries.

The last line is what makes long context affordable. At 256K tokens a query attends to 2,048 of 262,144 entries, 1/128 of them (reasoned). The indexer still looks at all of them, but it is cheap, and GLM-5.2 runs it in only 21 of the 78 layers: layers 0, 1, 2 and then every fourth. The other 57 reuse the nearest indexer's top-2,048 choice (indexer_types, measured). The headers agree: indexer weights exist in exactly those 21 layers, plus the MTP layer. This is IndexShare, which the GLM-5.2 article explains with its paper's figures.

What "256K" and "512K" cost

The cache is where context length turns into memory. Per token, MLA keeps $78 \times 576 = 44{,}928$ values, 89,856 bytes in BF16. The 21 indexer layers add $21 \times 128$ keys, 5,376 bytes (reasoned from the config; this assumes a BF16 cache, and serving engines often store it in FP8). For one sequence:

All reasoned. The architecture can hold 1,048,576 positions; the config says so, and GLM-5.2 ships with a 1M context. So a 512K Dawn would not need a new architecture, only serving and training at that length. But no Atria page I could find says 512K. The GitHub README lists 256K for Dawn and for the Preview. Its Codex and Kimi Code examples hard-code context_window: 256000 and max_context_size = 256000. The homepage's evaluation notes say every search benchmark ran with "a 256K-token context window". The 512K is in the launch post only, and I cannot verify it.

What Atria adds

The paper describes the post-training as a Verifiable Experience Pipeline. Each training task is tied to a real execution environment. The agent observes state, calls tools, produces artifacts and adapts to feedback. Then "final outcomes are verified through external signals such as tests, metrics, file state, geometric structure, source evidence, or human-defined criteria". Trajectories that are incomplete, contradictory or duplicated are dropped. Failure analysis drives the next round of tasks.

That is the whole recipe as published. There is no dataset size, no RL algorithm, no learning rate, no count of environments, and no ablation. The paper's 23 pages spend more space on how the team itself used agents than on how Atria was trained. I cannot check a recipe that is not written down, so I treat "verifiable experience" as a description of intent.

One change is visible in the files: the chat template keeps the model's reasoning across turns (measured). GLM-5.2's template re-emits an assistant turn's reasoning_content only for turns after the last user message, unless the caller sets clear_thinking to false. Atria's template drops that condition. Every past assistant turn is rendered with its <think> block intact. For an agent that runs hundreds of tool calls inside one user request, the difference is small. For a multi-turn session it means earlier reasoning stays in context and costs tokens. That fits a model trained on long, stateful trajectories.

The Preview is text-only. The README is explicit: the API rejects images with "is not a multimodal model". It ships a Codex catalog entry and a Claude Code hook that block image and PDF reads.

What the four launch numbers count

Every benchmark here reports "a percentage", and none of the four percentages measures the same kind of thing. The explorer below holds each number's definition and the same benchmark as run by other publishers this site has covered. The prose after it carries the same content.

AutomationBench 54.7: a pass rate, and nobody's numbers agree

AutomationBench is Zapier's benchmark of cross-application business workflows over REST APIs: Sales, Marketing, Operations, Support, Finance and HR. The agent must find the endpoints itself, follow a policy document, and leave the right data in the right systems. Grading is programmatic, on the end state only, and "we give no partial credit". A 54.7 means 54.7% of tasks completed exactly. The paper has 600 public tasks and a private evaluation set of 600 or more. At release it reported the best frontier model "below 10%". Atria says it ran v1.0.6 with a null-handling fix from PR #13; it does not say which split.

Atria's 54.7 leads its own table, 2.2 points ahead of GLM-5.3's 52.5 (reasoned). The trouble is that the comparators move between publishers:

• GLM-5.3 scores 48.2 in Z.ai's launch (GLM-5.3), 49.2 in Atria's Preview table, 52.5 in Atria's Dawn table, and 62.2 on Artificial Analysis's chart in Mistral's Large 4 post.
• Qwen3.8-Max scores 49.7 in Atria's table and 27.3 Pass@1 in Qwen's own (Qwen3.8-Max).
• Elsewhere on this site: Ultramarine 1 Flash 50.2, LFM2.5-24B-A2B 27.69.

The same model's score spans 22.4 points depending on who ran it (reasoned, Qwen3.8-Max). A cross-page comparison on AutomationBench is noise. Inside one table, run by one operator, Atria's lead is real but small. It also shrank: in the Preview-era table Atria led by 4.1, and GLM-5.3's number has since been revised up.

WideSearch 84.8: an F1 the release never names

WideSearch asks an agent to collect a large table of facts, such as every item in a category with several attributes each, across 200 questions. Its paper reports three metrics: a table-level success rate (the whole table must match), row-level F1, and item-level F1 (cell by cell). At publication the best success rate was 5%.

Atria never says which metric its number is. A score of 84.6 cannot be a success rate on this benchmark, so it is an F1, most likely item-level (reasoned). Read it as "finds and gets right most of the cells", not "completes 85% of the tasks".

The figure itself is inconsistent. The launch post says 84.8. The homepage table, the GitHub README and the chart in Figure 2 all say 84.6 (reported). The Preview's 81.9 is unchanged. Claude Opus 5, blank in the Preview table, now appears at 84.0, so Dawn's lead in this row is 0.6.

Workspace-Bench 66.1: a judge's rubric score, third in its own table

Workspace-Bench 1.0 builds realistic workspaces (20,476 files across 74 types), poses 388 tasks with file dependencies, and scores them against 7,399 rubric items. The paper's human baseline is 80.7. Atria ran it in the AgentCompass framework with Claude Code as the harness (Codex for GPT models) and Doubao Seed 2.0 Lite as the LLM judge. So 66.1 is a judge's rubric coverage, not a task success rate.

The launch post does not mention that 66.1 is not the top of Atria's own table. Qwen3.8-Max is at 68.0 and GLM-5.3 at 67.4 (reported), so Dawn is third. Both of those comparators were 63.9 in the Preview-era table. Across the 15 rows the two tables share, I count 18 of 90 comparator cells revised and 4 filled in, while all 15 of the Preview's own scores are unchanged (measured from the two tables). Re-running baselines is legitimate. A launch post that quotes a number without its row is less so.

MLE-bench Lite 88.2: HumanRank, not medals

This is the number that looked wrong, and it is not wrong; it is a different metric. MLE-bench usually reports the share of Kaggle tasks where an agent's submission earns a medal. The medal rates this site has covered top out in the low 70s. Malena medals on 62.5% of 30 tasks with GLM 5.2, AIRA explains why the metric is hard to move, and the strongest references on the 22-task Lite split reach 72.73% (below). An 88.2% medal rate would be a jump of 15 points.

Atria's footnote says the score is reported "only using the HumanRank score", following Frontis-MA1. That paper defines it: HumanRank "is the fraction of human leaderboard participants whose score is surpassed by the submitted solution, averaged across tasks and runs". An 88.2 means that, on an average task, the agent's submission beats 88.2% of the humans on that Kaggle leaderboard. A medal needs a place near the top, so the same run scores far lower on medals.

Frontis-MA1's Table 1 lets me put both metrics side by side, because Atria's comparators come from it (reported, Frontis):

GPT-5.6 Sol's 88.9 and Kimi K3's 85.8 in Atria's table are these HumanRanks, rounded. So Dawn's 88.2 sits between two models that earn medals on about 73% of tasks. It is second in its row, below GPT-5.6 Sol. Against its own base, GLM-5.2 in Claude Code, the gain is 8.7 HumanRank points (reasoned). That carries a caveat. Frontis ran its own configurations on one RTX 4090 capped at 12 GB per task, and Atria states only that it used Claude Code with a 12-hour limit, so the two runs may not share hardware. Atria publishes no medal rate, so I cannot say where Dawn lands on the usual metric.

Dawn against the Preview

When I first wrote this, the new table had 22 rows, 19 with a Preview score, and Dawn fell on three of them, SWE-bench Pro among them (59.6 to 59.4). Overnight Atria added a GDPval row and revised Dawn's SWE-bench Pro score to 61.7 (see 16 October). As of 16 October the table has 23 rows, 20 with a Preview score. Dawn improves on 17 of those, ties on Harbor-Index at 17.3, and falls on two: NL2Repo-Bench (51.4 to 50.0) and BrowseComp (92.5 to 91.3). The largest gain on a percentage scale is JobBench, 50.3 to 57.5 (GDPval is an Elo-style rating, 1,583.8 to 1,594.2). The others in the launch post are up 0.9 (AutomationBench), 2.7 (WideSearch), 1.1 (Workspace-Bench) and 2.0 (MLE-bench Lite). All reported, deltas reasoned.

Dawn holds the top score in 7 of 22 rows: AutomationBench, CyberGym, SkillsBench, WideSearch, Harvey LAB, BFCL V4 and DeepSearchQA. It is sixth of seven on Terminal-Bench 2.1 and, after the revision, fourth of seven on SWE-bench Pro (it was sixth at 59.4). Claude Opus 5 leads both, at 90.2 and 76.5. That is the honest shape of the release. The strengths are tool calling, search and office workflows. Repository-scale coding trails the closed frontier by double digits.

expand

The Preview's paper chart is the same layout, with the September comparator numbers:

expand

The other half of the paper

Atria's paper is subtitled "On the Evolving Roles of Human–AI Collaboration". Most of it is a study of the team's own development work, which is more interesting than its benchmark section. The team analysed 769 task records from 56 participants, plus agent logs (reported):

• 713 of the 739 tasks with a clear answer, 96.5%, involved AI.
• Of 455 completed AI-assisted tasks, participants rated 151, or 33.2%, infeasible without AI.
• On methods and parameters, "AI proposes, human selects" was the most common pattern at 55.4%. Humans made the final call on 85.5% of those decisions, and on 93.4% of goal and scope decisions.
• The median ratio of agent actions to human prompts rose from 11.0 to 28.5 between 7 August and 4 September.
• When a task hit its worst difficulty, 76.0% moved forward through human intervention and 23.0% through the agent recovering alone. Takeovers were 0.7%.

These are self-reports from the people who built the model, about the model's predecessors. That is a limitation the paper does not hide. Its reading, that "the scarce input is judgment rather than execution", is a reasonable summary of its own numbers.

expand

Running it

The Preview needs datacenter hardware. BF16 weights are 1,506.7 GB and the FP8 checkpoint is 755.6 GB (measured from the file listings). Add the cache from the table above. The card points to SGLang v0.5.13.post1+ and vLLM v0.23.0+, both through their GLM-5.2 recipes, because the architecture is GLM-5.2's. A community 4-bit MLX conversion exists at 457.6 GB (measured). That is still beyond any single workstation.

Settings from generation_config.json: temperature 1.0, top-p 0.95. The API caps output at 65,536 tokens, per the README's Kimi Code example.

16 October: the second launch post

At 15:52 UTC on 15 October the Atria account posted again: "Atria Dawn officially launches today. From research questions to verifiable results—now with a 512K context window and stronger performance vs. Preview", followed by three deltas: JobBench +7.2, WideSearch +2.7 and PaperBench +2.6. It links the homepage, the GitHub repo under its new name, and Intern Discovery's Token Plan page. The next morning I re-fetched each of them, and the Hugging Face and ModelScope listings, to see whether any of yesterday's findings had moved.

512K is still only in the posts. The homepage was redeployed on 16 October (its asset path is stamped 20261016). Its only context figure is in the evaluation notes for the search benchmarks, which still say "the context window is 256K tokens". The README was edited twice that morning, at commits eb98b9e and 318ac0a. Its model table still lists 256K for Atria Dawn, Dawn FP8 and both Preview checkpoints, and its Codex and Kimi Code examples still set 256,000 (all measured from the files). The Token Plan page is a single-page app whose model list, including a "Context Length" column, comes from an endpoint that answers 401 without a login. I could not read it, so the one page that might state 512K is the one I cannot check. Nothing about the architecture forbids 512K, as the cache table above shows. The claim remains unverified, not false.

Dawn's weights are still not out (measured, 16 October). Searching the Hugging Face API for Atria returns the three Preview repos, unchanged since 16 September, and one community MLX conversion of the Preview. ModelScope answers "record not found" for Atria-Dawn and Atria-Dawn-FP8. The README still says "Coming soon", and the homepage's GitHub, Hugging Face, ModelScope and Token Plan buttons still point at #. Asked "Huggingface?" in the replies, the account answered "Coming soon! We're preparing the Hugging Face release" (reported). With no Dawn checkpoint, there are no headers to read, so I cannot yet say whether Dawn keeps GLM-5.2's shapes or changes max_position_embeddings or the rotary settings. The Preview's config already allows 1,048,576 positions, so a 512K Dawn would not need a config change to fit.

The three deltas are right. Recomputed from the README and homepage tables, Dawn minus Preview is 57.5 − 50.3 = 7.2 on JobBench, 84.6 − 81.9 = 2.7 on WideSearch and 89.6 − 87.0 = 2.6 on PaperBench (reasoned). All three match the post. JobBench is the largest gain on a percentage scale in the whole table. Even so, Dawn is third on JobBench and third on PaperBench, behind Claude Opus 5's 68.0 and GLM-5.3's 58.2 on one, and Qwen3.8-Max's 94.1 and GPT-5.6 Sol's 92.8 on the other (reported).

WideSearch is now 84.6 everywhere except the first post. The second post's +2.7 only works from 84.6. From 84.8 it would be +2.9. The homepage table, the README and the release chart all say 84.6 (measured, 16 October). So the 84.8 in the first launch post looks like a typo that Atria's own arithmetic has since contradicted.

The table changed overnight. Comparing the README at 9182d35 with eb98b9e, two lines differ (measured). A GDPval row was added: Dawn 1,594.2 against the Preview's 1,583.8, sixth of seven, with Claude Opus 5 at 1,714.0. And Dawn's SWE-bench Pro score went from 59.4 to 61.7, with every other cell in the row unchanged. That turns a regression against the Preview into a gain of 2.1, and moves Dawn from sixth to fourth of seven in that row (reasoned). The commit message is "Update README.md". It gives no reason, no new run date and no note on the change. A re-run is a legitimate reason to change a score, but a silent revision of the one coding number that went backwards is worth knowing about. I have corrected the "Dawn against the Preview" section above and left a note there of what it said before.

Where this leaves the claims

The useful facts are the measured ones. Atria Dawn Preview is a capable, MIT-licensed GLM-5.2 fine-tune aimed at tool use and office workflows. You can serve it with the GLM-5.2 stack you may already run. Its launch numbers are real numbers, but each one needs its footnote, and one of them is not the number on the publisher's own page.