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

> Satyajit Ghana — Head of Engineering @ Inkers Technology
> canonical: https://ai.thesatyajit.com/articles/atria-dawn
> date: 2026-10-15
> tags: agents, benchmarks, mixture-of-experts, glm, sparse-attention

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.

<ModelCard repo="internlm/Atria-Dawn-Preview" />

## 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](https://github.com/atria-asi/Atria-Dawn) 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):

| Artifact | Where | Size | Licence |
|---|---|---|---|
| `Atria-Dawn-Preview` (BF16) | Hugging Face, ModelScope | 353 shards, 1,506.7 GB | MIT |
| `Atria-Dawn-Preview-FP8` | Hugging Face, ModelScope | 755.6 GB of safetensors | MIT |
| `Atria-Dawn-Preview-Ascend-w8a8` | Hugging Face | 802.9 GB of safetensors | MIT |
| `Atria-Dawn` / `Atria-Dawn-FP8` | nowhere: 404 on ModelScope, absent from every Hugging Face listing | n/a | n/a |

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](https://arxiv.org/abs/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.

| Tensor slice | Atria vs GLM-5.2 | Atria vs GLM-5.3 | GLM-5.3 vs GLM-5.2 |
|---|---|---|---|
| `embed_tokens` (first rows) | 6.3% | 21.6% | 21.1% |
| layer 40, expert 17, `down_proj` | 3.5% | 11.8% | 11.3% |
| layer 77, router `gate` | 3.7% | 9.8% | 9.5% |
| layer 20, `q_b_proj` | 1.6% | 5.9% | 5.6% |
| layer 0, `input_layernorm` | 0.9% | 3.5% | 3.4% |

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](/articles/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](/articles/glm-5-2) takes apart. It is the same move Z.ai made with [GLM-5.3](/articles/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](/architectures/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{active} = N_\text{fixed} + 75 \cdot k \cdot 37{,}748{,}736
$$

$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.

<MoeLedger />

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](/articles/glm-5-2) 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:

| Context | MLA cache | Indexer keys | Total |
|---|---|---|---|
| 256K (262,144 tokens) | 23.6 GB | 1.4 GB | 25.0 GB |
| 512K (524,288 tokens) | 47.1 GB | 2.8 GB | 49.9 GB |
| 1M (1,048,576 tokens) | 94.2 GB | 5.6 GB | 99.9 GB |

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.

<MetricExplorer />

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

[AutomationBench](https://arxiv.org/abs/2604.18934) 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](/articles/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](/articles/mistral-large-4).
- **Qwen3.8-Max** scores 49.7 in Atria's table and 27.3 Pass@1 in Qwen's own ([Qwen3.8-Max](/articles/qwen3-8-max)).
- Elsewhere on this site: [Ultramarine 1 Flash](/articles/ultramarine-1-flash) 50.2, [LFM2.5-24B-A2B](/articles/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](https://arxiv.org/abs/2508.07999) 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](https://arxiv.org/abs/2605.03596) 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](https://arxiv.org/abs/2410.07095) 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](/articles/minimal-ml-engineering-agent) medals on 62.5% of 30 tasks with GLM 5.2, [AIRA](/articles/aira-research-agents) 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](https://arxiv.org/abs/2607.28568). 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):

| Model, harness | HumanRank | Medal average |
|---|---|---|
| GPT-5.6 Sol, Codex | 0.8891 | 72.73% |
| Kimi K3, Claude Code | 0.8574 | 72.73% |
| GLM-5.2, Claude Code | 0.7948 | 59.09% |

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](#16-october-the-second-launch-post)). 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.

<Figure
  src="https://media.thesatyajit.com/ai/articles/atria-dawn/fig2.jpg?v=7525e298e92f6a4c"
  alt="Eight bar-chart panels comparing Atria Dawn (blue, with the Preview's lighter bar inside it) against DeepSeek V4 Pro 0813, Kimi K3, Qwen 3.8 Max, GLM 5.3, GPT 5.6 sol and Claude Opus 5. Atria Dawn's values: AutomationBench 54.7, CyberGym 86.8, SkillsBench 67.8, WideSearch 84.6, MLE-bench Lite 88.2, Workspace-Bench 66.1, PaperBench 89.6, JobBench 57.5. Tallest bars elsewhere: MLE-bench Lite GPT 88.9, Workspace-Bench Qwen 68.0, PaperBench Qwen 94.1, JobBench Claude 68.0."
  caption="The Dawn release chart. Note WideSearch at 84.6, not the launch post's 84.8, and that MLE-bench Lite here is a HumanRank score. All numbers are Atria's (Atria Dawn GitHub README and atria-asi.ai, evaluation chart)."
/>

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

<Figure
  src="https://media.thesatyajit.com/ai/articles/atria-dawn/fig1.png?v=7056fc53515eb17d"
  alt="Eight bar-chart panels for Atria Dawn Preview against six models. Preview scores: AutomationBench 53.8, SkillsBench 66.4, Workspace-Bench-Lite 68.2, GDPval 1583, CyberGym 86.5, MLE-Bench Lite 86.2, DeepResearch Bench II 51.1, SWE-Bench Pro 59.6. GLM 5.3 is 49.2 on AutomationBench here, and Claude Opus 5 leads SWE-Bench Pro at 74.7."
  caption="The Preview's benchmark chart from September. GLM 5.3's AutomationBench bar is 49.2 here and 52.5 in the Dawn chart (Atria Dawn paper, Figure 1)."
/>

## 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.

<Figure
  src="https://media.thesatyajit.com/ai/articles/atria-dawn/fig3.png?v=17a0c1bb1659a28f"
  alt="Four panels. (a) Research Object: a human runs plan, experiment and analyze while the AI is the object under study. (b) Task-Level Runner: a human directs a research workflow while the AI executes assigned tasks. (c) Project-Level Coworker: the human sets goals and guides decisions while the AI plans, experiments and evaluates in a loop. (d) What Comes Next?: a faded human and robot around a question mark, asking about recursive self-improvement."
  caption="The paper's framing of where agents sit in AI R&D today, stage (c), with the next stage left as a question (Atria Dawn paper, Figure 5)."
/>

## 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

| Claim | Verdict |
|---|---|
| "700B agentic foundation model" | 743.4B backbone, 753.3B stored, 40.3B active. GLM-5.2's architecture, fine-tuned (measured) |
| Dawn is the "official release" | of the API. Weights: Preview only, Dawn "Coming soon", still so on 16 October (measured) |
| "512K context" | repeated in the 16 October post; every official Atria page still says 256K, rechecked that day. The architecture allows 1M (measured; 512K unverified) |
| AutomationBench 54.7% | Atria's table; exact-pass metric; leads GLM-5.3 by 2.2 in that table, and other publishers' numbers for the same models differ by up to 22.4 (reported, reasoned) |
| WideSearch 84.8% | 84.6 on Atria's own site and README, and the second post's +2.7 only works from 84.6; an unnamed F1, not a success rate (reported, reasoned) |
| JobBench +7.2, WideSearch +2.7, PaperBench +2.6 vs Preview | all three recompute exactly from Atria's table; JobBench is the largest percentage-point gain in it (reasoned) |
| Workspace Bench 66.1% | LLM-judged rubric score; third in Atria's table (reported) |
| MLE Bench 88.2% | HumanRank on the 22-task Lite split; second behind GPT-5.6 Sol's 88.9, which is a 72.73% medal average (reported) |

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.