The firmware targets 171 board variants, not one reference device
XiaoZhi ESP32 is the device half of a voice assistant. It captures audio, streams it to speech and language-model services, plays the reply, and can add a display, camera, battery reporting, or physical controls. The README lists 171 release variants in 138 board directories across ESP32, C3, C5, C6, S3, and P4 chips. That breadth is the attraction, but it also means the board name and revision are part of the software decision.
The checkout makes the scale visible: our commit bb9122a clone contained 1,658 files and about 122,960 lines of source in 9.1 MB. Networking can use Wi-Fi, Ethernet, USB RNDIS, or named 4G modules. Audio travels over WebSocket or MQTT plus UDP, with Opus, wake-word support, and full-duplex interaction on hardware that supplies acoustic echo cancellation. Displays can show expressions, and supported boards can send camera input.
MCP controls GPIO while the voice model stays elsewhere
MCP is used on both sides of the device boundary. Device-side tools expose hardware such as the speaker, LED, servo, and GPIO. Cloud-side tools can reach services such as smart-home controls, desktop operations, search, or email. XiaoZhi is therefore useful when spoken interaction must end in a physical action, not just another text response. The microcontroller remains an endpoint; the language model and most speech processing live behind the selected service.
That split matters before buying parts. The beginner firmware connects to xiaozhi.me by default, where a personal account configures the model. The README also points to separate Python, Java, and Go server repositories for personal deployment. Our 3-CPU, 8 GB sandbox did not exercise any of those backends, because the supplied measurement covered this firmware repository only. A private deployment requires choosing, securing, and maintaining another project alongside the board.
What happened when we ran it
Our sandbox install failed in 1 second at commit bb9122a. CMake reached CMakeLists.txt, then could not find /tools/cmake/project.cmake. It next reported idf_build_set_property as an unknown command and stopped configuration. Those messages establish that the plain CMake environment could not configure this checkout. They do not show a compiler failure, a faulty board target, or a problem in the firmware itself.
No build or test step followed the failed install. The repository scan found 1 CI workflow file, no Dockerfile, and no tests directory. That result is useful because XiaoZhi is easy to mistake for an ordinary C++ checkout. Its documented source path starts with ESP-IDF and its editor plugin, so a fresh Debian container with CMake alone does not reproduce the expected development environment.
The README currently prefers ESP-IDF 6.0.2 and a stable 6.0 or later release. ESP-IDF 5.5.2 remains only for documented legacy boards, while the ESP32-S31 variant needs 6.1 or later. Those version boundaries should be pinned per product. Upgrading the SDK because another board needs it can change the component and driver behavior of a device that already works.
Flashing prepared firmware avoids the failed source path
Beginners do not have to compile. XiaoZhi links to a firmware builder and a flashing guide, and the prepared image connects to the official service. That is the sensible first trial for a listed board: confirm its microphone, speaker, display, network, and provisioning behavior before installing a 6.0.2 toolchain. A successful flash still tests only that exact hardware combination, not all 171 variants.
Source work is a different commitment. The documented setup uses Cursor or VS Code with the ESP-IDF plugin, and the project says Linux gives faster compilation with fewer driver issues than Windows. Custom boards need their own board definition and hardware choices. Wake words, fonts, emoji, and backgrounds have a separate web asset generator. Each extra layer is documented, but none is part of the 1-second CMake command our sandbox attempted.
Specific board revisions still produce specific failures
GitHub listed 673 combined issues and pull requests when fetched, so that number must not be read as 673 bugs. Recent reports are still instructive. Issue 2178 describes an M5Stack Tab5 with ESP32-P4 revision 1.3 rebooting before app_main; issue 2186 reports a black panel after display initialization on that device family. Issue 2213 covers another ESP32-P4 revision 1.3 board that crashes before app_main.
The activity is current rather than abandoned. The repository was last pushed on August 21, 2026, after release v2.4.2 arrived on August 6. That release added or repaired several board definitions, including LCD Wiki, Waveshare, M5Stack, and ESP32-S31 entries. Board work is clearly moving. It also shows why a product team should freeze the exact board, SDK, firmware commit, and service endpoint after validation instead of treating the compatibility list as interchangeable hardware.
XiaoZhi is strongest as a supported-board shortcut
A maker with a listed board can get an unusually complete device experience from one firmware family: 39 interface languages, several network paths, wake words, display expressions, camera input, and MCP hardware control. The prepared-image route is the best way to learn whether that combination fits. It avoids interpreting our failed CMake configuration as a verdict on hardware we did not run.
For a commercial device, the wide matrix cuts both ways. Release v2.4.2 shows active maintenance, while the open revision-specific reports show the validation burden does not disappear. XiaoZhi is a good shortcut when its assumptions match your board and backend. It is a poor foundation for a team that expects generic CMake, a single self-contained server, or proof that every advertised board behaves alike.