[bong-water-water-bong]

436930 text-generation models on HF, 344583 with an architecture (3050 architectures).

	models	share
mapped (a backend's code accepts the architecture)	325177	94.37%
checked (passed serve_e2e on Strix Halo)	219300	63.64%

backend	mapped	checked
hrx	94.37%	63.64%
npu	55.14%	9.45%

Unmapped architectures with the most models:

• Step1MoEForCausalLM: 2882
• ParlerTTSForConditionalGeneration: 1585
• ChessForCausalLM: 970
• LlavaLlamaForCausalLM: 453
• OpenLMForCausalLM: 266
• DynamicAlibiForCausalLM: 245
• DynamicForgettingForCausalLM: 240
• BertLMHeadModel: 212
• BartForConditionalGeneration: 176
• MobileLLMForCausalLM: 176

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Data Consistency The census data includes new architectures and updated model counts, but the PR description does not provide measured hardware performance data to validate the claims about backend coverage (e.g., "94.37% mapped" and "63.64% checked"). Without actual measurements on Strix Halo or other hardware, these percentages cannot be confirmed as accurate. { "date": "2026-11-12", "coverage": { "definitions": { "mapped": "the pinned backend's code accepts this HF architecture class (registry/architectures.json names a backend for it); it is a property of the ARCHITECTURE, so every model of a mapped class counts as mapped whether or not that model was ever run", "checked": "the architecture has a PASSING serve_e2e at the pin -- not that this model was run. It is the same per-architecture property, which is why the npu figure is essentially one architecture's model population rather than a count of models anyone exercised", "declined": "a human reviewed the class and deliberately did not map it (registry/significant.json, `watch: \"report\"`). Counted separately and excluded from top_unmapped: it is a recorded decision, not work remaining. The denominator is unchanged -- declined models are still `with_architecture`", "with_architecture": "models whose HF card names an architecture this census can look up; models with no architecture are excluded from every percentage above" }, "declined_models": 822, "declined_architectures": 23, "models": 436930, "with_architecture": 344583, "architectures_seen": 3050, "mapped_models": 325177, "mapped_pct": 94.37, "checked_models": 219300, "checked_pct": 63.64, "per_backend": { "hrx": { "mapped": 325177, "checked": 219300, "mapped_pct": 94.37, "checked_pct": 63.64 }, "npu": { "mapped": 189999, "checked": 32574, "mapped_pct": 55.14, "checked_pct": 9.45 } }, Architecture Counting The architectures_seen count increased from 3042 to 3050, but the PR description does not specify how this increase was measured or validated on the hardware. This could indicate a discrepancy if the new architectures were not actually tested or mapped on the hardware. "architectures_seen": 3050,

[bong-water-water-bong]

Reviewed the regenerated artifact structurally rather than as text, because a census bump is exactly where a silent revert hides. The regeneration is correct, and it closes a loop I opened earlier:

1. OpensciForCausalLM correctly leaves top_unmapped. Main's census (date: 2026-11-11) still carries coverage/top_unmapped[15] = {architecture: "OpensciForCausalLM", models: 122} — the pre-fix state, because registry/significant.json gained the reviewed watch: "report" entry (engine#2189) but the generated census.json was never regenerated afterwards. Yours (date: 2026-11-12) drops it entirely and it does not appear in declined_architectures either, which is the right outcome for a watch: report class: mapped-for-watching, not refused. So this PR is the first artifact to carry that fix.

2. One architecture took its slot, and it is not tracked: NanoChatForCausalLM (75 models) is new to top_unmapped, and registry/significant.json on main has 0 entries matching nanochat. That is the thing worth deciding in this PR rather than after it: either add it as a reviewed class with its reason, or record why it is not significant. Otherwise the next census re-surfaces it and the --check-gaps pass still says nothing about it (that check asserts reviewed classes are mapped, not that unmapped ones were reviewed — the silent direction).

3. The rest is ordinary drift, and I checked it for reversals: K2HorizonForCausalLM 157→155, Spark2_5ForCausalLM 149→152, BailingMoeV3ForCausalLM 85→87; raw.total 436,207→436,930 (+723), with_architecture 344,259→344,583. No architecture's count moved in a way that suggests a truncated scan.

Not a verdict — the head is too fresh for me to be the reviewer who also just read the previous one; this is the artifact check, which no reviewer of the diff would have done.

[bong-water-water-bong]

VERDICT at 1c10fc0: READY

This is a generated PR, so I checked it as one: that it is a pure tool output, and that its description matches its artifact.

• It is a pure refresh. The diff is counts only — declined_models 695 → 822, declined_architectures 22 → 23, models 436,207 → 436,930, mapped_models 324,887 → 325,177 — and the definitions block, which is prose, is untouched. Nobody has hand-edited semantics into a machine-written file, which is the failure mode that turns a census into an opinion.
• It comes from the workflow, not a laptop. census.yml runs python3 tools/census.py | tee census.txt, exits early on git diff --quiet -- registry ("no change"), and opens the PR with python3 tools/census.py --pr-body. So the body is generated from the same run as the data.
• And the description does match the artifact: I ran python3 tools/census.py --pr-body at this head, which reprints the PR body from the committed registry/census.json, and it reproduces the same figures — 436,930 models, 344,583 with an architecture (3,050), 325,177 mapped (94.37%), 219,300 checked (63.64%). A body that disagreed with the file would mean the PR was describing a different run than it shipped.

The definitions block is the best thing in the file and worth protecting: "checked" is defined as "the architecture has a PASSING serve_e2e at the pin — not that this model was run". That is the sentence that stops a reader turning 63.64% into a coverage claim about 219,300 models, and "declined" is defined as a human decision recorded in registry/significant.json — which is exactly what #2281 is doing with Bagel and Oleander.

One thing to expect rather than fix: the declined_* counts derive from registry/significant.json, and #2281 adds two declines there. Whichever of the two merges second, registry/census.json will lag one cron run, so the counts and significant.json will disagree for up to a day. That is normal for a periodic artifact — worth knowing so the next reader does not treat it as a contradiction, and not a reason to hand-edit a generated file.

[bong-water-water-bong]

VERDICT: READY at 1c10fc0 — the numbers are the kind that only mean something with a denominator, and this one carries its denominators.

What the census says, and why the shape matters

436,930 text-generation models on HF, 344,583 with an architecture (3,050 architectures)
mapped   (a backend's code accepts the architecture)   325,177   94.37%
checked  (passed serve_e2e on Strix Halo)              219,300   63.64%

Two percentages over two different denominators is the right way to publish this: 94.37 % of identifiable architectures are mapped (a statement about the registry), and 63.64 % have been checked by serving (a statement about evidence). Collapsing them into one number would have hidden the gap that matters — a third of the mapped surface has never been run, and that is the honest state of a model matrix this size.

The uncovered tail is a worklist, which is the point of listing it

Step1MoEForCausalLM              2882
ParlerTTSForConditionalGeneration 1585
ChessForCausalLM                  970
LlavaLlamaForCausalLM             453
OpenLMForCausalLM                 266
DynamicAlibiForCausalLM           245
DynamicForgettingForCausalLM      240
BertLMHeadModel                   212
BartForConditionalGeneration      176
MobileLLMForCausalLM              176

Ordering by model count is the right ordering: Step1MoEForCausalLM (2,882) and ParlerTTS (1,585) dwarf the rest, so the list doubles as a priority queue. And several are clearly not gaps in the interesting sense — BertLMHeadModel, BartForConditionalGeneration, LlavaLlama are older architectures whose absence is a decision rather than a backlog item, which is exactly the distinction #2281 recorded two entries for.

Two asks

1. mark the reviewed decisions inline — several of these ten are almost certainly "reviewed, not an alias/won't serve" rather than work (as registry: Bagel and Oleander reviewed as not aliases (census 2026-11-12, engine#2280) #2281 did for BagelForCausalGeneration and OleanderForCausalLM). One clause per line (— reviewed 2026-11-12: <reason>) turns a 10-line worklist into a 10-line worklist plus the decisions already taken, and it stops the same class being re-reviewed next census;
2. say the delta against the previous run — registry/census.json is diffable, and "mapped 94.37 % (was X), checked 63.64 % (was Y)" is the sentence that tells a reader whether this cycle moved. A snapshot without its previous value is a fact; with it, it is progress or a regression, and this fleet has spent all night on the difference between those.