The feature list is a starting point. The experiment is to keep extending what the device can do around the things I actually want to use, with a physical keyboard, screen and microphone to bring the result back into my hands.

Watch the full project walkthrough, with English and Russian subtitles:

https://www.youtube.com/watch?v=_0f9UTwefmo

Before going into the workflow, there is one useful question: which part runs in my hand, and which part runs on the host?

The real Cardputer ADV during the Chess demonstration. Photo frame from my project footage.

Three parts, with different jobs

The device handles physical interaction and local apps. The bridge, agent services and build tools run on the host.

The Cardputer owns the interaction. Its ESP32-S3 handles the keys, display, microphone recording, speaker playback and local applications. Focus timer, notes, calculator and games are firmware features; local tools do not need a model to run. Settings live in NVS, with optional media on microSD.

The bridge connects the two sides. A Node.js service translates device HTTP and WebSocket calls into the OpenClaw gateway’s session protocol. It handles the configured conversation, its history, media and update assets. Each bridge instance has one device identity, its own token and explicit routing.

The host supplies the agent environment. OpenClaw, configured model and speech services, and firmware build tools belong on the computer or server. The Cardputer does not run an LLM. It carries a constrained bridge token; the gateway credentials remain on the host.

Follow one voice turn

With voice configured, a push-to-talk interaction travels through several stages:

• The device records the microphone input and sends it to the bridge.
• Host-side speech services transcribe the request.
• The configured agent produces a response.
• Speech output is generated on the host and played by the device.

The public bridge also exposes text turns, so voice is not the only way to talk to the agent. Starting with text makes the initial setup easier to inspect: send a question and check for its answer on the actual screen.

For readers who want to explore the implementation, these are three useful entry points:

The architecture documentation explains the surrounding ownership and routing rules. Use it with the implementation when writing a client.

Extending the device adds another loop

A conversation setup gives me an interface to the agent. Changing what the handheld can do adds source changes, a firmware build, review, an offered update, installation and a physical test.

That is the broader experiment: keep the tools that already work, then add the next useful thing. The physical result matters because a successful build can still feel awkward when the screen is small and the input is a tiny keyboard.

The development automation requires its own host services and permissions. It is optional, site-specific configuration beyond the basic chat installation. An agent connection alone does not configure a firmware development service or authorize an unattended update.

Trying the project

The supported starting point is the M5Stack Cardputer ADV. First setup needs a USB data cable, Wi-Fi, a computer with Python and PlatformIO, and a working OpenClaw environment with a supported Node.js runtime. Voice adds FFmpeg and configured STT/TTS backends on the host.

The getting-started guide begins with text, then adds push-to-talk voice. This is experimental software. The public README currently notes that public builds have not yet been tested on a freshly provisioned physical device, so a complete new-user installation still needs validation.

Follow the build or contribute

The full film, I Built an AI OS That Evolves on Demand, shows the device and workflow. The source and setup guides are on GitHub.

Attribution and license details for the source and its contributors are preserved in the repository. Full credits.

What would you ask your AI OS to build first?

Prepared with AI assistance from my project documentation and footage. Architecture drawing is explanatory; hardware photographs are real frames from the project.