Compiles in your browser. No build queue.
Mokxi compiles your sketch with a real clang running inside your own browser tab, so a build never waits for a shared server. Here is how long it takes from opening a sketch to a running simulation, measured in a real browser by a script you can run yourself, with the method beside every number.
The machine as it is
No throttling: our cloud build server, served from the same machine, so the first-visit column is the compiler starting and building, not a network.
| Sketch | First visit, link to running | Coming back, link to running | Each edit after, Run to running |
|---|---|---|---|
| Blink on an Arduino Uno Arduino Uno (AVR) | 12.3 s (10.8 s of it after Run) | 3.3 s (2.0 s after Run) | 0.9 s |
| An SSD1306 OLED on an Uno, with the Adafruit libraries Arduino Uno (AVR) | 13.7 s (12.4 s of it after Run) | 6.0 s (4.3 s after Run) | 2.1 s |
| An LED chaser on a Raspberry Pi Pico Raspberry Pi Pico (RP2040) | 14.4 s (12.8 s of it after Run) | 3.7 s (2.5 s after Run) | 1.1 s |
| Blink on an ESP32 DevKitC ESP32 (Xtensa) | 13.9 s (12.9 s of it after Run) | 3.6 s (2.5 s after Run) | 0.9 s |
Measured 2026-10-05: median of 3 runs per sketch, Chromium 153.0.8010.12, Intel(R) Xeon(R) Processor @ 2.80GHz, 4 cores, 16 GB, load average 6.46 when the run began.
With a 4x CPU slowdown and a 20 Mbit/s network
The same build under Chrome DevTools’ 4x CPU slowdown and a network capped at 20 Mbit/s down, 5 up, 40 ms: a stand-in for a school Chromebook on a shared connection.
| Sketch | First visit, link to running | Coming back, link to running | Each edit after, Run to running |
|---|---|---|---|
| Blink on an Arduino Uno Arduino Uno (AVR) | 62.6 s (58.7 s of it after Run) | 14.8 s (10.3 s after Run) | 1.6 s |
| An SSD1306 OLED on an Uno, with the Adafruit libraries Arduino Uno (AVR) | 63.9 s (59.2 s of it after Run) | 17.8 s (13.7 s after Run) | 3.3 s |
| An LED chaser on a Raspberry Pi Pico Raspberry Pi Pico (RP2040) | 66.1 s (61.3 s of it after Run) | 15.0 s (10.7 s after Run) | 1.6 s |
| Blink on an ESP32 DevKitC ESP32 (Xtensa) | 68.3 s (64.1 s of it after Run) | 16.1 s (11.7 s after Run) | 2.0 s |
Measured 2026-10-05: median of 3 runs per sketch, Chromium 153.0.8010.12, Intel(R) Xeon(R) Processor @ 2.80GHz, 4 cores, 16 GB, load average 9.22 when the run began.
What each column is
Three moments a visitor actually waits through.
First visit is a brand-new browser profile with nothing cached: from opening the sketch’s link to the simulation running a fresh build of it. It includes downloading the compiler, 94.1 MB for the AVR, ARM and RISC-V boards and 96.8 MB for the Xtensa ESP32 boards, sent uncompressed today, and building the board’s runtime library once. That is the slowest number on the page, and it happens once per browser.
Read the first-visit column of the throttled table with that download in mind. At 20 Mbit/s, 94.1 MB takes about 38 seconds by arithmetic alone, so most of that minute is the network. The server can already send a compressed copy of the compiler when one is published next to it; none is published yet, and that is the first thing to fix on this page.
Coming back is a new tab in the same browser: the compiler and the runtime come out of the cache, and only your sketch is compiled. Each edit after is pressing Run again after changing the sketch in the same tab: the compiler is already loaded, so this is the compile, the link and the simulator starting.
The number in brackets is the part after Run is pressed. The rest is the editor page itself loading. An untouched example runs its prebuilt program with no compile at all, so the script adds a comment to every sketch before pressing Run: each number here is a real compile.
How we measured, and how you can too
One script, committed to the repository, that drives a real Chromium.
The script is web/scripts/bench-first-run.mjs. It uses Playwright to open the editor on each built-in sketch, waits for the simulator to load, types a comment at the end of the sketch, presses Run and waits for the Run button to turn into Stop, which happens when the build has finished and the simulation has started. It does this in a fresh browser profile, then in a new tab of the same profile, then once more in that tab, and reports the median of three samples. Nothing is smoothed and no sample is dropped.
Run it yourself with node scripts/bench-first-run.mjs from the web folder for mokxi.com, or with --serve dist for a local build. --profile throttled adds the slow profile and --json out.json keeps every sample. The samples behind the tables above are in proofs/fast/ in the source code.
One board is missing on purpose. While we were measuring, an edited ESP32-C3 sketch failed to build in the browser: the compiler crashes while it builds that board’s runtime library, and the prebuilt ESP32-C3 examples still run. A failed build is not a time, so the ESP32-C3 is left out of the tables until it is fixed, rather than shown with a number that would mean nothing.
The throttled profile is Chrome DevTools’ 4x CPU slowdown, applied to the page and to every worker it starts, the compiler’s included, plus a network capped at 20 Mbit/s down and 5 Mbit/s up with 40 ms of latency. It stands in for a school Chromebook on a shared connection. It is a stand-in, not a Chromebook, and a real one may be faster or slower.
Where these numbers come from, plainly: our build machine is a shared cloud Linux server, not a laptop on a desk, and its network reaches the internet only through a proxy that made timing mokxi.com itself meaningless. So the script served a production build of this site from the same machine, with the compiler sent uncompressed exactly as mokxi.com sends it. Under the unthrottled profile that means the download costs almost nothing, and the first-visit column there is the compiler starting and building, not your network; the throttled profile puts a 20 Mbit/s network back. Other jobs were sharing the machine, which the load average shows. Run the script and you will have your own numbers instead of ours.
Nobody else’s build is ahead of yours
A compiler on a server is shared; a compiler in your tab is not.
Wokwi compiles sketches on its servers. It is an excellent simulator, its paid plans include monthly fast build minutes, and a server build is what lets it take any library from the Arduino Library Manager. On its free plan, though, people have reported waiting on a busy shared build server for years, in public, on Wokwi’s own issue tracker and on the Arduino Forum:
- wokwi-features #1136 (September 2026): the compiler "hitting a wall at 100+ seconds before rendering a ‘Build server busy’ error window"
- wokwi-features #1108 (April 2026): "I was waiting for build server load to normal but everyday is always full"
- wokwi-features #1062 (December 2025): "Build servers busy" with the simulator stuck loading, on the free plan
- Arduino Forum (November 2024, in German): simple sketches compiling "with a runtime approaching infinity"; the reply puts it down to more logged-in users sharing CPU time
We have not measured Wokwi, and none of the numbers on this page are Wokwi’s. The quotes are its users’ own words, linked so you can read them in full. What we can say is structural: a build in your browser cannot be queued behind somebody else’s, because there is no somebody else.
More on the two tools, including where Wokwi is the better pick: Mokxi and Wokwi, compared fairly.
Questions
Does Mokxi have a build queue?
No. The compiler, a real clang and lld built for WebAssembly, runs inside your own browser tab, so nobody else’s build is ever ahead of yours and there are no build minutes to run out of. The trade is a one-time download of the compiler on the first build in a fresh browser.
Why is the first run slower than the rest?
The first build in a fresh browser downloads the compiler and builds the board’s runtime library once. Both are kept in the browser’s cache, so a return visit compiles only your sketch, and an edit after that recompiles only what changed.
Can I run the benchmark myself?
Yes. Check out the repository, run npm install in web, and run node scripts/bench-first-run.mjs. It opens the editor in Chromium against mokxi.com, or against a local build with --serve dist, and prints the same table this page shows.
Is a compile in the browser slower than on a server?
Per build, a fast dedicated server can be quicker than a browser on a slow laptop, and on a Chromebook-class machine the first build is the slowest number on this page. What the browser removes is the wait for a shared server: a build here is never queued behind anyone else’s.
Time it yourself
Open the editor, change the blink delay and press Run. The compiler is already on its way into your browser.