Latest in AI
Simantic Launches Firmware Simulation for AI Agents: How It Works and Pricing
Virtual microcontrollers give coding agents a way to test embedded software, but the simulator's hardware coverage still sets the boundary.
Simantic introduced its firmware simulation tools to Hacker News on October 29, giving AI agents a way to run embedded code without waiting for a physical development board. The product combines a cloud simulator with a GitHub reviewer that checks firmware changes against simulated hardware.
That closes a practical gap in AI coding. Generating a plausible driver is useful, but an agent needs somewhere to exercise it before an engineer can judge whether the change deserves time on a bench.
What Simantic actually provides
In the founders' launch post, Simantic describes virtual development boards accessible through an API, automated firmware review and simulation in continuous integration. The cloud service is available now. The team says it rebuilt its simulation engine in Rust after initially using Renode.
The product page explains the review workflow more concretely. Simantic Bot builds a pull request's firmware, designs test scenarios from the changes, runs them and reports findings with suggested fixes. Its example tests whether an LED's physical output follows the program's messages, rather than accepting those messages as proof that the hardware behaved correctly.
The useful distinction is between reviewing code and checking an observable result. A coding model can explain why a register write looks reasonable. A simulator can provide a separate execution trace that either supports or contradicts that explanation.
Simantic pricing and access
The current pricing page lists these allowances:
| Plan | Published price | Included monthly credits | Concurrent simulations |
|---|---|---|---|
| Community | No subscription price shown | $10 | 3 |
| Developer | $100 monthly, or $1,000 annually, plus tax | $200 | 10 |
| Enterprise | Contact sales | Unlimited API usage | Unlimited |
Enterprise lists private hosting and separately billed GitHub integration. Credits should not be read as a fixed number of simulation hours: the table does not establish a universal conversion between credits and a particular workload.
Local execution has specific requirements
Simantic's CLI documentation describes a local binary for Apple Silicon macOS and x86-64 Linux. Windows uses the Linux build through WSL2. Python 3.12 or newer is required.
The simulator uses a deterministic virtual clock, so matching firmware and inputs should produce matching output. However, local execution still requires an account, and every run checks credentials with Simantic's backend. This is not an offline-only workflow.
Hardware support also needs checking at the exact chip level. The CLI distinguishes modeled, incomplete and unmodeled devices. A family name on a feature list is insufficient evidence that a particular peripheral or variant behaves as a project needs.
What simulation cannot establish yet
The founders say their hardware rigs compare simulation against real silicon, but acknowledge that public silicon-validation benchmarks have not been released. Their accuracy claims therefore remain claims to evaluate, rather than an independently established replacement for physical testing.
For a firmware team, the sensible first evaluation is a small set of known failures. Can the simulator reproduce bugs already observed on the board, and do its traces explain them? That test is more informative than asking whether an agent can generate a larger patch.
If simulation reliably rejects bad changes earlier, scarce bench time can go toward the cases that genuinely require hardware. The important measure is how much trustworthy evidence reaches the engineer before a board is flashed.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help technical founders turn engineering work and product launches into clear stories that developers can understand and share.