MimiClaw: Running an AI Assistant on a $5 ESP32-S3 Chip

What MimiClaw Actually Solves

The problem MimiClaw targets is concrete: running an AI assistant without a server. Most self-hosted assistants need a Linux box, a Node.js runtime, or a cloud VM. MimiClaw replaces all of that with a single ESP32-S3 dev board. The README describes the project as "the world's first AI assistant(OpenClaw) on a $5 chip" with "No Linux. No Node.js. Just pure C." Whether or not that first claim holds up, the design goal is clear.

The intended user is someone who already has an ESP32-S3 board and a Telegram account. You plug the board into USB power, connect it to WiFi, and message it through Telegram. The board picks up the message, runs an agent loop, and replies. Memory is stored locally on flash, not in a cloud database. The README states the device draws 0.5 W and runs 24/7 on USB power.

This is not a general-purpose server. It is a constrained device. The agent loop runs on a microcontroller, so the tool set, context window, and concurrency are all bounded by what fits in 8 MB of PSRAM. The README does not publish those limits, which is a gap worth noting before you commit hardware.

How the Agent Loop Runs on a Microcontroller

The data flow described in the README is short. A Telegram message arrives over WiFi. The ESP32-S3 feeds it into an agent loop where "the LLM thinks, calls tools, reads memory" and then sends the reply back to Telegram. The LLM itself is remote: the board calls either Anthropic (Claude) or OpenAI (GPT) as the provider, and the README says the provider is switchable at runtime via the serial CLI.

What runs locally is the orchestration. The firmware handles WiFi, the Telegram bot protocol, the agent loop, tool dispatch, and memory reads and writes. Memory lives on the board's flash, described in the README as "all your data stored locally on flash." The CLI exposes this directly: memory_read shows what the bot remembers, and memory_write appends content to a file called MEMORY.md.

Two optional search integrations are wired in: Brave Search and Tavily, with Tavily described as "preferred." Both require API keys supplied at build time or through the CLI. The repository also includes a skills/ directory and a spiffs_data/ directory, which suggests the firmware ships a SPIFFS filesystem image alongside the application binary, though the README does not document the contents of either directory.

The architecture is therefore a thin local shell around a remote model. That is the right call for a $5 chip, but it means the device is useless without network access and a valid API key.

Installing MimiClaw and Sending a First Message

MimiClaw builds with ESP-IDF v5.5 or later. The README points to the Espressif getting-started guide for ESP32-S3 and gives a clone-and-set-target sequence. You need an ESP32-S3 dev board with 16 MB flash and 8 MB PSRAM, a USB Type-C cable, a Telegram bot token from @BotFather, and an Anthropic or OpenAI API key.

Start by cloning the repository and setting the target chip:

git clone https://github.com/memovai/mimiclaw.git
cd mimiclaw

idf.py set-target esp32s3

On Ubuntu or macOS, the README provides setup scripts rather than asking you to install every dependency by hand. On Ubuntu the sequence is:

./scripts/setup_idf_ubuntu.sh
./scripts/build_ubuntu.sh

On macOS the equivalent scripts are setup_idf_macos.sh and build_macos.sh. The README lists baseline requirements including Python 3.10 or later, CMake 3.16 or later, Ninja 1.10 or later, flex, bison, gperf, and dfu-util.

Configuration is two-layer. Build-time defaults live in main/mimi_secrets.h, and runtime overrides set through the serial CLI are stored in NVS flash and take priority. Copy the example file first:

cp main/mimi_secrets.h.example main/mimi_secrets.h

Then edit the defines for WiFi credentials, the Telegram token, the API key, and the model provider. The README shows the provider as either "anthropic" or "openai". After any change to mimi_secrets.h, the README requires a clean build:

idf.py fullclean && idf.py build

Flashing requires the correct USB port. The README warns that most ESP32-S3 boards have two USB-C ports and that you must use the one labeled USB (native USB Serial/JTAG), not the one labeled COM. Find the port, then flash and open the monitor:

ls /dev/cu.usb*          # macOS
ls /dev/ttyACM*          # Linux

idf.py -p PORT flash monitor

Once the monitor is open, the CLI prompt appears. You can change settings without recompiling, for example switching the provider or setting a proxy:

mimi> set_model_provider openai
mimi> set_model gpt-4o
mimi> config_show

After configuration, send a message to your bot on Telegram. The README says the board picks it up over WiFi and replies. If nothing arrives, wifi_status and heap_info in the CLI are the first things to check.

Where MimiClaw Breaks Down

The most obvious limitation is the hardware requirement. Despite the "$5 chip" framing, the README's own bill of materials specifies an ESP32-S3 dev board with 16 MB flash and 8 MB PSRAM, and cites the Xiaozhi AI board at roughly $10. A bare $5 module will not have the PSRAM the firmware expects. Budget for the dev board, not the chip.

The second limitation is network dependence. The agent loop runs locally, but the model does not. Every reply requires a round trip to Anthropic or OpenAI. If your WiFi drops or your API key expires, the device stops being an assistant. The README does not describe an offline fallback mode.

The third limitation is operational. The README documents config_reset, which clears NVS and reverts to build-time defaults, and restart, which reboots the board. It does not document any rollback mechanism for firmware itself. If you flash a build that fails to boot, recovery depends on the ESP32-S3's own bootloader behavior, not on anything MimiClaw provides. For a device you may mount somewhere out of reach, that matters.

Finally, the release cadence is thin. The repository has two releases: v0.1.0 on 2026-02-09 and v0.1.1 on 2026-03-17. The last push to the repository was on 2026-08-21. That is recent enough that the project is not abandoned, but the version numbers indicate early-stage software. Treat it as such.

MimiClaw vs Running OpenClaw on a Raspberry Pi

The natural alternative is running an assistant stack on a Raspberry Pi or a small VPS. That approach gives you a full Linux environment, a Node.js or Python runtime, persistent storage measured in gigabytes, and the ability to run the model client, the bot, and any database on the same machine. You can also SSH in, read logs, and roll back a bad deploy by checking out a previous commit.

The difference in approach is where the agent loop lives. On a Pi, the loop runs in a general-purpose runtime with virtual memory and a filesystem. On MimiClaw, the loop runs in C on a microcontroller with no OS, no process isolation, and flash-backed storage. That gives MimiClaw a power envelope and physical footprint a Pi cannot match, at the cost of debuggability and headroom.

The README also references a related project called OpenClaw, describing MimiClaw as an AI assistant built around it. If you already run OpenClaw on a server, MimiClaw is not a replacement; it is a constrained port of the same idea to hardware. Choose based on whether the constraint is the point. If you want a device that sits on a desk, draws half a watt, and has no OS to patch, MimiClaw is the fit. If you want to iterate quickly on prompts and tools, a Pi will be less frustrating.

Maintenance, Licensing, and Upgrade Cost

MimiClaw is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are included. That is permissive and imposes no copyleft obligation on your own code. It does not, however, grant any rights to the Anthropic or OpenAI APIs the firmware calls, and it does not cover the Telegram Bot API. Those are separate services with their own terms, and you are responsible for the keys you embed in mimi_secrets.h. Note that API keys compiled into firmware are extractable from the flash image, so treat a flashed board as holding a secret.

Upgrade cost comes from the two-layer config design. Build-time values live in mimi_secrets.h and runtime values live in NVS flash. The README states that CLI values take priority over build-time values. That means a board you configured over serial will ignore changes you make to mimi_secrets.h until you run config_reset or overwrite the relevant key. This is a sensible design for field devices, but it is also a common source of confusion during upgrades: you rebuild, flash, and see no change because NVS still holds the old value. The CLI command config_show prints the current configuration with values masked, which is the way to confirm what the board is actually using.

There is no documented migration path between releases. The README does not describe how NVS data is versioned or what happens to stored memory when the firmware layout changes. If you keep anything valuable in MEMORY.md, read it out with memory_read before flashing a new build.

Editorial conclusion

MimiClaw suits engineers who already own an ESP32-S3 board, are comfortable with ESP-IDF, and want a Telegram bot that stores memory on flash without a server. It is the wrong tool if you need a stable API, a web dashboard, or any guarantee of rollback after a firmware update, because the README does not document rollback and the project is at v0.1.1. Before flashing, verify that your board has 16 MB flash and 8 MB PSRAM, confirm which USB-C port is labeled USB rather than COM, and have a Telegram bot token and an Anthropic or OpenAI API key ready.

Frequently asked questions

Official sources

1. License: MIT
2. memovai/mimiclaw on GitHub
3. Project website
4. README
5. Releases