How to Use Simantic: The Beginner's Guide

CodexFuse Team · 2026-11-02T21:24:46.470Z · 14 min read min read

Simantic simulates firmware on virtual STM32, ESP32 and RP2040 boards so AI coding agents can test what they write. This beginner guide covers the first simulation, the @simantic-bot GitHub review, and CI validation.

How to Use Simantic: The Beginner's Guide

An AI coding agent can write your firmware in seconds — but until recently, testing it meant finding a physical board, wiring it up, and flashing the code. Simantic removes that bottleneck: it gives the agent (and you) a virtual microcontroller that runs your actual firmware ELF, so the code can be tested, debugged, and reviewed before it ever touches hardware. This Simantic tutorial walks through the virtual-board lesson, your first simulation, the @simantic-bot review arc, and the CI arc — written for a US beginner audience, with every fact sourced from Simantic's own docs, its YC page, and its launch coverage.

The Virtual-Board Lesson: Why Firmware Needs a Fake Chip First

The core mental model is this: an AI agent writes firmware fast, but firmware without a test target is just a guess. A physical board gives you one serial target at a time; a virtual board gives you every target your CI can afford, with a deterministic clock — the same ELF with the same inputs produces the same output, byte for byte (Simantic's own determinism claim). Say it once: if you let Claude Code, Anthropic's terminal-based AI coding agent, write your embedded code, test that code in simulation before a single real chip sees it.

Firmware bugs are expensive in the physical world. A bad GPIO sequence can cook a motor driver; a runaway loop can drain a battery before you notice. In Simantic, the same bug shows up as a trace you can replay. That is the whole pitch: the virtual MCU is not a toy — it is where the agent's output gets interrogated.

What Is Simantic, Exactly?

Simantic is a firmware simulator built for AI coding agents, launched on Hacker News on October 29–30, 2026 as part of YC's Fall 2026 batch. Founded in 2025 in Waterloo, Canada, the four-person company was started by Ahnaf Shahriar (formerly an embedded software engineer at Neuralink on implants/chargers and an AI hardware engineer at Tesla on Dojo/Autopilot) and Seungmin Hong (formerly a firmware engineer at Tesla, Simbe Robotics, and Rapyuta Robotics, with ML work at Ericsson) — both computer engineering graduates of the University of Waterloo, per the company's YC page. The product has three pieces: a local CLI that runs your compiled ELF on a virtual chip, a Cloud Sim HTTP API for virtual MCUs over the wire, and an AI code-review bot (@simantic-bot) that simulates your pull request's firmware and backs every runtime claim in its review with a recorded run.

One disambiguation that matters: Simantic (simantic.com) is NOT Siemens' SIMATIC — the industrial PLC simulator whose pages sometimes surface on the same search — and it is NOT SigmanticAI, a separate "AI teammate for chip design" that generates Verilog and UVM testbenches. Different company, different product, different problem.

Before You Start: What You Need

You need three things: a compiled firmware ELF, a Simantic install, and (for the cloud and bot arcs) a free Community account. The CLI installs with one command on macOS Apple Silicon and Linux x86-64 — on Windows it only supports WSL2:

curl -fsSL https://simantic.com/install | sh

Homebrew users can tap the vendor's formula instead:

brew tap simantic-dev/simantic

Your ELF can come from any toolchain — the review bot demonstrably handles STM32CubeMX/Makefiles, CMake, pico-sdk, ESP-IDF, and Zephyr projects, per the vendor's demo coverage. Build the firmware exactly as you would for hardware; simulation takes the same binary. And one agent-safety note before the fun starts: if AI agents are anywhere near your hardware toolchain, the Heldkeys beginner guide is worth a read first — the agent-safety lesson applies double when untested code can physically damage a board.

Your First Simulation: Flash an ELF on a Virtual Board

Here is the full first-run arc, start to finish, on a local machine:

1. List the virtual boards. sim models prints every MCU the CLI knows — it works offline, because the chip definitions ship with the binary. The current docs show RP2040 (264KB RAM / 2048KB flash), STM32F072RB (16KB / 128KB), STM32F401RE (96KB / 512KB), the STM32H743 family (AG–ZI) and STM32H753 family (AI–ZI) — plus ESP32-C3/C6/P4 boot-from-ROM support and ESP32-S3/C3 coverage from the launch. The homepage promises "STM32, ESP32, nRF and more," and the list has been expanding since the October launch.
2. Run your ELF. sim STM32F401RE run --elf build/hello-world.elf boots the virtual chip and executes your firmware. Add --ascii for readable UART output and --timeout 15 so a runaway loop does not run forever.
3. Watch the pins, not just the UART. The simulator models GPIO, so you can observe exactly what your firmware does to the outside world — the whole point of the virtual board.
4. Make it fail on purpose. Add --expect "LED ON" to assert that string appears in output, or --expect-absent "hardfault" to fail the run if it does. The simulator becomes a test harness, not just a viewer.

That is the hello-world of the Simantic firmware simulator: pick a board, flash the ELF, inspect the behavior. Everything after this is automation around the same loop.

The Local CLI, Decoded: The Commands You'll Actually Use

The CLI surface is small and deliberate. These are the commands the vendor documents:

The run command carries the useful flags: --expect and --expect-absent for assertions, --gpio-in to inject pin states, --board to pick a specific virtual dev board, --uart-tcp to expose UART over TCP, --gdb to attach a debugger, --record <DIR> to capture the run, and --control-port for interactive control. There is also a Python SDK for scripting the same thing: pip install simantic, then from simantic import Sim with Sim(elf="fw.elf", mcu="STM32F401RE", uart="usart2"), plus sim.expect(), sim.inject_gpio(), and sim.read_u32() — currently in alpha (v0.4.2).

Assertions and Scenarios: Making the Sim Check Itself

A single run with --expect is a smoke test; a scenario file is a test suite. sim run --scenario test.yaml executes scripted sequences — boot, inject GPIO, wait, assert UART, read memory — so your firmware's behavior becomes a repeatable, version-controlled specification. This is where the AI-agent angle gets serious: an agent can generate scenarios alongside the firmware it writes, and the scenario file lives in the repo next to the code, so "does it behave?" is answered by running a command, not by a human squinting at an oscilloscope.

Practical pattern for beginners: one scenario per hardware feature. Boot-up UART message. Button press → LED state change. ADC read → expected value range. Keep each scenario small; a failing scenario tells you exactly which feature regressed. Use sim check --scenario to validate the scenario file itself before trusting its results.

Cloud Sim: Running the Same Firmware Over an API

The local CLI runs the sim on your machine; Cloud Sim runs it on Simantic's infrastructure behind an HTTP API — useful when the test target is an AI agent with no local hardware toolchain. The flow is a multipart POST:

curl -X POST https://cloud.simantic.com/v1/runs \
  -H "Authorization: Bearer smtc_YOUR_TOKEN" \
  -F mcu=STM32F401RE \
  -F uart_encoding=ascii \
  -F firmware=@build/hello-world.elf

That returns a run ID; you poll GET /v1/runs/$RUN_ID/output (it answers 409 until the run finishes). Clients ship as a TypeScript SDK (npm install @simantic/cloud-sim) and an MCP server (npx -y @simantic/cloud-sim-mcp) that wires straight into Claude Code via claude mcp add — so the agent that wrote the firmware can flash the virtual board itself, read the output, and iterate. The vendor's starter project is an STM32CubeMX "hello-world" for the STM32F401RE, published as github.com/simantic-dev/cloud-sim-examples. The Python SDK and a CLI client for Cloud Sim are both marked "Coming soon" on the vendor's site as of this writing.

Notice what changed for the agent workflow: testing is no longer a human-shaped step. The agent writes the ELF, posts it to the API, reads the deterministic output, and fixes the bug — the same closed loop a human would run, at machine speed.

The Bot Arc: Getting @simantic-bot to Review Your Pull Request

The @simantic-bot review is Simantic's most distinctive piece, and its rules surprise people. The reviewer is an on-demand assistant, not CI: nothing runs on a push. It runs only when a PR comment mentions it — e.g. @simantic-bot review — and that is a deliberate design choice, said once so you do not wait for a review that will never arrive.

What the bot actually does, per the vendor's reviewer documentation as reported by the independent walkthrough at lockergnome: it builds your PR's firmware, runs it on a simulated chip, and posts one review in which every runtime claim is backed by a recorded run. When a claim could not be simulated, the review marks it static instead of pretending. The famous demo: a PR titled "blinky: drive the LED through BSRR" on an STM32F072RB swapped an ODR read-modify-write for GPIOA_BSRR = on ? (1u << LED_PIN) : (1u << (LED_PIN + 15)). The bot ran a 3-second simulation recording UART and PA5; the firmware's log claimed the LED went off at 1.0s and 2.0s, but the simulated pin trace showed PA5 never goes low. Verdict: "Changes requested" — the reset half is off by one bit. The fix: change + 15 to + 16 on line 78 of main.c. One bit, caught by simulation, in a review you can replay.

The bot is included on every pricing tier including the free Community tier, per lockergnome's reporting — reviews draw down your monthly included usage, and with less than about $1.50 of credit left it declines to run. If your team lives on pull requests, the GitHub beginner guide pairs well here: the bot's whole theater is the PR.

The CI Arc: Validate Every Commit Against Simulated MCUs

The fourth arc closes the loop: run the simulator in CI so every commit is validated against simulated MCUs. The pattern is simple — on each push, build the ELF, run the scenario file with sim run --scenario, and fail the pipeline when assertions fail. The founders' HN launch post describes exactly this: CI/CD pipelines validating firmware "on every commit," with early users running flight-controller, EV, robotics, and even satellite firmware through it — one space startup reportedly tested satellite firmware at a hundredth of the cost and time (the company's claim, not an independent measurement).

If you have never wired a pipeline before, the GitHub Actions beginner guide and the Git beginner guide to branches and commits cover the mechanics; the Simantic step is just another job in the workflow. Deterministic simulation is what makes this sane in CI: no flaky hardware, no queue for the one dev board, no "works on my desk" — the same ELF, the same inputs, the same output, on every runner.

Simantic vs Renode and QEMU: What Actually Differs

The natural question is why a new simulator exists when Renode and QEMU already simulate chips. The founders answered this directly in their HN launch post — and this is their account, flagged as a vendor claim, not an independent benchmark:

Treat the performance and fidelity claims as the vendor's until independent benchmarks exist. The part you can verify yourself is the determinism: run the same ELF twice and diff the outputs. That property is the entire foundation of the CI arc — if you cannot trust the sim to repeat itself, none of the automation above is worth anything.

Pricing: What the Free Tier Actually Gets You

Simantic's pricing page lists three tiers, verified at write time:

The free Community tier is the honest starting point: $10 of monthly credit is enough to run first simulations, try the bot on a PR, and feel the loop. Watch your credit balance — lockergnome's reporting notes the bot refuses reviews when under about $1.50 of remaining credit.

6 Beginner Mistakes That Waste Your First Hour

Sources

1. Simantic company page, Y Combinator — founders, backgrounds, batch, team size: https://www.ycombinator.com/companies/simantic
2. Simantic launch post, Hacker News (item 50291116, Oct 29–30, 2026) — Rust engine origin, hardware rigs, CI every commit, early users: https://news.ycombinator.com/item?id=50291116
3. "Simantic Launches Rust Firmware Simulator for AI Coding Agents," aiweekly.co (Oct 30, 2026) — launch-day chip list, Cloud Sim, review bot, pricing framing: https://aiweekly.co/alerts/simantic-launches-rust-firmware-simulator-for-ai-coding-agents
4. "Simantic Bot Runs Firmware on Simulated Chip, Catches Off-by-One — LED Never Turns Off," lockergnome (Oct 30, 2026) — @simantic-bot demo walkthrough, mention-only behavior, free-tier inclusion: https://lockergnome.com/simantic-bot-runs-firmware-on-simulated-chip-catches-off-by-one-led-never-turns-off/
5. Simantic CLI documentation — commands, flags, chip list, determinism claim: https://simantic.com/docs
6. Simantic Cloud Sim — HTTP API, MCP server, TypeScript SDK, starter project: https://simantic.com/cloud-sim
7. Simantic pricing — Community / Developer / Enterprise tiers: https://simantic.com/pricing
8. simantic Python package v0.4.2, PyPI — Python SDK, install, ESP32 boot-from-ROM support: https://pypi.org/project/simantic/0.4.2/
9. Simantic homepage — "STM32, ESP32, nRF and more" chip framing: https://simantic.com/
10. SigmanticAI — chip-design AI teammate (disambiguation): https://www.sigmanticai.com/index.html
11. Simantic launch roundup, realfeedapp (Nov 2026): https://realfeedapp.com/en/a/49822/

Frequently Asked Questions

Is Simantic free?

The Community tier is free and includes $10 of monthly credit, 3 concurrent runs, the full API clients, and GitHub integration — which includes the @simantic-bot reviewer, per third-party reporting on the vendor's own reviewer docs. Reviews draw down your credit balance, and the bot reportedly refuses to run when under about $1.50 of remaining credit. The Developer tier is $100/month with $200 of monthly credit and 10 concurrent runs.

Is Simantic the same as Siemens SIMATIC?

No. Siemens SIMATIC is the industrial automation / PLC ecosystem. Simantic (simantic.com) is a YC F26 startup that simulates microcontroller firmware (STM32, ESP32, RP2040) so AI coding agents can test embedded code without physical boards. The names collide on search pages; the products do not.

Which chips does Simantic support?

The documented list includes RP2040, STM32F072RB, STM32F401RE, the STM32H743 and STM32H753 families, and ESP32-C3/C6/P4 boot-from-ROM images, with ESP32-S3/C3 in the launch coverage — and the homepage says "STM32, ESP32, nRF and more." The list has been growing since the October 2026 launch, so run sim models for the current roster rather than trusting any static list.

Does @simantic-bot review every pull request automatically?

No — and this is the detail most people get wrong. The bot is an on-demand assistant, not CI: nothing runs on a push. It reviews only when a PR comment mentions it, e.g. @simantic-bot review. When it does run, it builds the PR's firmware, simulates it, and posts one review where every runtime claim traces to a recorded run; claims it could not simulate are marked static.

Can Simantic fully replace my physical test board?

Not entirely. It replaces the logic-verification loop — GPIO sequences, UART behavior, timing, protocol handling — with a deterministic, replayable, CI-friendly version of it. What simulation cannot give you is the electrical reality: analog behavior, EMI, power draw, and the quirks of your specific silicon revision. The vendor itself runs 24/7 hardware rigs to validate the sim against real boards, which tells you where they think the boundary is: simulate to iterate, flash to confirm.