ESP-Claw: a Chat Coding AI agent framework for ESP32-class IoT devices
ESP-Claw, a "Chat Coding" AI agent framework for IoT devices
At a glance
- What is it?
- ESP-Claw turns ESP32-S3, ESP32-P4 and ESP32-C5 boards into local agent runtimes that accept behaviour changes over chat and load Lua at runtime. The framework is real and the browser flashing path is the easy part; model choice and the missing security process are where adoption gets harder.
- Who is it for?
- Adopt ESP-Claw if you are prototyping an ESP32-S3, ESP32-P4 or ESP32-C5 device whose behaviour should be rewritten by conversation rather than recompiled, and if you already have API access to a model with strong tool use and instruction following.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What ESP-Claw adds to a connected ESP32 board
A conventional ESP32 firmware connects, reports and executes. ESP-Claw's stated goal is to move the decision layer onto the chip: the README frames the shift as turning devices from passive executors into active decision-making centres. The audience is therefore not the person writing a sensor driver. It is the person who wants a device to react to an event with a judgement, and who would rather describe that judgement in a chat window than in C.
The README names two capabilities that carry the idea. Chat as Creation means IM chat plus dynamic Lua loading, so a non-programmer can define device behaviour. Event Driven means any event can trigger the Agent Loop, and the README claims response times as fast as milliseconds. The hardware floor is deliberately low: the README says an ESP32-series chip costing a few dollars is enough to try it. That combination, cheap silicon plus a conversational configuration surface, is the whole pitch.
The Agent Loop, Lua loading and MCP in the repository layout
The README does not publish an architecture diagram, so the mechanism has to be read from the feature list and the directory names. The loop is event-triggered: an event enters the Agent Loop, the loop consults the configured LLM, and the resulting behaviour is expressed as Lua that the firmware loads dynamically. That is why the model requirement is not decorative. The README states plainly that self-programming depends on models with strong tool use and instruction-following ability, and recommends gpt-5.4, qwen3.6-plus, claude4.6-sonnet, deepseek-v4-pro or comparable models. A weak model does not degrade the experience gracefully; it produces worse Lua.
Memory is handled locally. The README describes structured memory with privacy staying off the cloud, which is the part that matters for devices sitting in a home. Communication is MCP, and the README says ESP-Claw works as both server and client, so a device can expose capabilities and consume them. The top-level layout supports this reading: application/, components/, tools/, pages/ and docs/ sit alongside AGENTS.md and CLAUDE.md, which suggests the agent-facing instructions are treated as repository artefacts rather than hidden configuration.
Flashing ESP-Claw from the browser, then building locally
The fastest path skips the toolchain. The README states that supported boards in ./application/edge_agent/boards/ can be flashed online, with configuration and flashing done entirely in the browser, and no local compilation or development environment required. The online flashing page is at https://esp-claw.com/en/flash/.
# No local command is needed for the browser path.
# Open https://esp-claw.com/en/flash/ , pick a listed board, and flash.If your board is not in that directory, or you are on an ESP32-P4, the README says local builds and flashing cover those cases, pointing at the local build documentation at https://esp-claw.com/en/tutorial/ for board adaptation, building and flashing. Expect that route to involve the Espressif toolchain rather than a single command, because the README describes it as board adaptation work.
Once the device is running you still have to choose a model and an IM channel. ESP-Claw supports OpenAI-style and Anthropic-style APIs, with native support for GPT, Qwen, Claude and DeepSeek, plus custom endpoints. On the chat side it supports Telegram, QQ, Feishu and WeChat. The practical first run is therefore: flash a listed board, configure a provider endpoint and key, connect one IM channel, then send a message that changes device behaviour and observe the Agent Loop fire.
Where ESP-Claw is the wrong tool
The model dependency is the sharpest limitation, and it is stated by the project rather than inferred. If you cannot reach a frontier tool-use model, or you must keep inference off the public internet, the self-programming path is not viable as described. The README's own recommendation list is a set of hosted APIs.
Versioning is the second. The releases list contains a single entry, v0.1.0 from 2026-06-12, and the README says ESP-Claw is still under active development while inviting issues and feature requests. The last push to master was on 2026-09-08, so the repository is moving, but a project at 0.1.0 with one tagged release is not a stable target for a product you must support for years.
The security section is the third and the most awkward. It begins by saying ESP-Claw is not currently included in the Espressif Bug Bounty programme and then stops mid-sentence in the README. There is no stated disclosure process, no threat model, and no note on what a chat-driven device should refuse to do. A device that rewrites its own behaviour from chat messages, and that can be reached through Telegram, QQ, Feishu or WeChat, has an input surface you would want documented before deployment. It is not documented here.
ESP-Claw against ESP-IDF and Home Assistant
The comparison that matters is with ESP-IDF itself, because ESP-Claw is built on that foundation. ESP-IDF is Espressif's IoT development framework: you write C, you compile, you flash, and behaviour is fixed at build time. ESP-Claw keeps the same silicon and the same vendor, but moves behaviour definition to a chat interface backed by Lua loaded at runtime. The trade is explicit: you gain the ability to change what a deployed device does without a rebuild, and you give up the determinism and reviewability of compiled firmware. For a device whose logic must be audited line by line, ESP-IDF is the safer answer, and ESP-Claw is the wrong one.
Against Home Assistant the split is architectural rather than competitive. Home Assistant is a hub: it centralises automation on a server and treats devices as endpoints. ESP-Claw pushes the agent down to the device, which is why the README emphasises local decision-making and memory that stays off the cloud. A house full of ESP-Claw boards keeps working when the hub is down, and each board carries its own model configuration and its own failure modes. If your automation logic already lives in Home Assistant and you are happy with that, ESP-Claw adds a second place for logic to live.
Maintenance, licensing and the cost of the upgrade path
The repository is not archived and the last push was on 2026-09-08, so work is ongoing. The README describes the project as still under active development and links a TODO list and an online survey, both in Chinese, for feature voting. That is a reasonable signal about direction, but it also means the component boundaries in components/ and the board definitions in application/edge_agent/boards/ are the parts most likely to move under you.
The Apache-2.0 licence is permissive and includes a patent grant, which matters if you intend to ship a product. It does not give you any warranty, and the README's own statement that ESP-Claw is not currently included in the Espressif Bug Bounty programme means security fixes arrive through the normal issue tracker rather than a coordinated disclosure channel. That is a project decision, not a licence term, but it affects how you plan upgrades. Check the LICENSE file and CHANGELOG.md in the repository before you depend on a specific behaviour.
Editorial conclusion
Adopt ESP-Claw if you are prototyping an ESP32-S3, ESP32-P4 or ESP32-C5 device whose behaviour should be rewritten by conversation rather than recompiled, and if you already have API access to a model with strong tool use and instruction following. Do not adopt it if you need a security review, a compliance statement or a frozen API today: the README states the project is still under active development, the single release is v0.1.0 from 2026-06-12, and the security section is cut off mid-sentence, so the bug bounty position is unstated. Before wiring it into anything you care about, flash a listed board from the browser page, watch the Agent Loop react to one event, then read application/edge_agent/boards/ and components/ to see how much of the runtime you are actually pulling in.
Frequently asked questions
What is ESP-Claw?
ESP-Claw is Espressif's Chat Coding AI agent framework for IoT devices, written in C and licensed under Apache-2.0. It defines device behaviour through conversation and runs the full loop of sensing, decision-making and execution locally on ESP32-series chips.
What are ESP-IDF tools?
The README does not describe the ESP-IDF toolchain in detail. ESP-Claw is built for Espressif chips and the README points at local build documentation for board adaptation, building and flashing, while the browser flashing path requires no local development environment at all.
What is the ESP code language?
ESP-Claw itself is implemented in C, and its dynamic behaviour layer uses Lua loaded at runtime, which the README calls dynamic Lua loading. The README does not document a separate ESP-specific language.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/espressif-esp-claw)