Tracking how AI models do at embedded firmware. Each model gets a frozen one-shot prompt and must write a complete bare-metal firmware from scratch: linker script, startup, drivers, build script, everything. It's compiled and run on Renode simulations of real Cortex-M boards and scored objectively from diagnostics (compiles → boots → behavioral checks). Every cell is run 3× and averaged; same prompts every run, so progress is comparable over time.
0–100. Reference firmware = 100. A score is how close to known-good on these tasks (see methodology below). Related API/CLI surfaces are grouped (best score shown; expand for detail).
| # | Model | Provider | Score | Frontier | Refusal % | Tasks | Released |
|---|
API vs agent CLI. We split raw HTTP APIs from coding agents (Claude Code, Codex, Grok Build) because they are different products: same model name, different safety gates and harnesses. On this suite the gap is real—e.g. Claude Opus 5 API often refuses firmware tasks the classifier tags as “cyber” (score 0, counted in Refusal %), while the Claude Code CLI answers them and lands much higher. Expand a grouped row to compare surfaces.
One cell per model per task, colored by score. R = provider safety refusal (score 0, counted in Refusal %); ! = infra/invalid (excluded until re-run). Click any cell → opens the full prompt, model output, build log, and Renode trace.
stop_reason=refusal) are not infra retries and are not silently routed to another model. Refusal % on the leaderboard is that policy tax. Optional product_fallback stacks are labeled +fallback and never mixed with the bare model id.