The Vibe Father
Roundup
Embedded and IoT is the hardest place to ask "which AI model is best," because it's the workload furthest from what the benchmarks measure. The suites everyone quotes — SWE-bench Verified, Terminal-Bench, LiveCodeBench — are built almost entirely from Python and web-stack problems running on a normal machine with unlimited memory. Embedded is C and C++ on a microcontroller with 64KB of RAM, no operating system, hardware registers you poke directly, timing you can't get wrong, and a compiler that's older than the model's training data. There is no embedded benchmark, and the general scores are a weaker proxy here than anywhere else. So we rank by general reasoning ability and treat the numbers as a loose guide, not a verdict. The live board is at /benchmarks.
The general board, with a big caveat
Read this table knowing it measures general coding, not embedded specifically. For firmware, what you actually want is a model with the strongest reasoning and the widest exposure to systems-level C — which correlates loosely with the top of this board, but only loosely. Weight SWE-bench Verified (deep code reasoning) and discount the web-flavored parts.
| Model | SWE | TB | LCB |
|---|---|---|---|
 Claude Fable 5 | 95.0 | 83.1 | 89.8 |
| Claude Opus 4.8 | 88.6 | 78.9 | 87.8 |
 GPT-5.5 | 80.6 | 83.4 | 85.3 |
 Gemini 3.5 Flash | 79.3 | 76.2 | 87.6 |
| GPT-5.3 Codex | 74.8 | 78.4 | 87.3 |
 DeepSeek V4 Pro | 77.6 | – | 87.5 |
A dash means the suite isn't published yet, not a zero. Remember: none of these numbers were measured on firmware. They're a shortlist, not a ranking of embedded skill.
The pick for embedded: Claude Opus 4.8
For firmware and embedded C/C++, we default to the strongest general reasoner, because embedded errors are subtle and expensive and you want the model most likely to catch a race condition or a register-width bug. Opus 4.8 (88.6) is our everyday pick; Fable 5 (95.0) for the genuinely hard problems — a tricky interrupt handler, a memory-constrained algorithm, a driver for undocumented hardware. Their edge here isn't a benchmark line, it's that deeper reasoning transfers: a model that can hold a complex Python refactor in its head is also the one most likely to reason correctly about a volatile pointer or a DMA buffer. But keep expectations honest — even the best model has seen far less embedded C than web JavaScript, and it will confidently invent register names and misuse platform APIs.
The budget pick and the local option
Embedded work is often lower-volume than web work — you're not generating hundreds of files a day — so the cost pressure is gentler, but value still matters. DeepSeek V4 Pro at $0.435 / $0.87 per million tokens is a strong everyday pick for routine driver code and glue, capable enough for the bulk of firmware plumbing. There's also a real case for local models in embedded: firmware for hardware clients frequently comes with NDAs and can't leave the building, so an open-weight model you run on your own machine may be the only compliant option regardless of score. If that's you, our notes on self-hosting coding models and the best open-weight models are the place to start. The broader budget tier is in the cheapest coding models roundup.
The constraints benchmarks can't see
Three things determine whether AI-generated embedded code is any good, and none of them appear in a leaderboard. First, resource limits: a model trained on server code has no instinct for a 64KB heap, and will happily allocate like memory is free. Second, hardware truth: the datasheet is the authority, and the model hasn't read yours — it will guess register addresses and peripheral behavior. Third, timing and concurrency: interrupt-safe, real-time code is a class of correctness benchmarks don't test at all. So the workflow that works is tight-loop: small changes, compile against your real toolchain, test on real hardware, feed the errors back. The model is an assistant to the compiler and the datasheet, not a replacement for them.
Test it on your own hardware
This is the workload where testing yourself matters most, because the general scores are the weakest guide. Take a real task — a peripheral driver, a bit of RTOS glue, an optimization for a tight memory budget — and run the same prompt through two or three models. Judge them on: did it respect your resource constraints, did it use your platform's actual APIs instead of inventing them, and did the code compile and run on the target without a rewrite. Whichever model needs the fewest corrections against real hardware is your winner, whatever its SWE-bench line says.
What we'd run for embedded
One model: Opus 4.8 for its reasoning depth, Fable 5 for the hard 10%. For volume and routine drivers, DeepSeek V4 Pro; for NDA-bound firmware that can't leave your machine, a strong open-weight model run locally. Whatever you choose, keep the compile-and-test loop tight and never trust a register name you didn't verify against the datasheet. Bring your own keys to pay the lab's real rate — see bring your own keys. The board updates monthly at /benchmarks, and the best coding model roundup has the full frontier picture.
