What Muse Gadgets Can Do: Capabilities, Limits, Terms

Here's what Muse Gadgets can do: show Muse's status on a light or screen, display images Muse sends, take push-to-talk voice notes, take photos on one board, and run shell commands on a Raspberry Pi. They can't speak replies without extra work, go into a product you sell, or count on Meta for support. The code is open source, but the tokens that connect gadgets to Muse have their own terms.

What Muse Gadgets can do, tier by tier

Tier	Example boards	What you get	What you don't
Status light	ESP32-C5 DevKitC-1, ESP32-S3-DevKitC-1	A status light and a button	Screen, images, voice
Status screen or e-paper	ideaspark 1.9", SenseCAP Indicator, reTerminal E1001 and E1002	Status on a screen, images from Muse	Voice, on-screen settings
Voice with an LED ring	Home Assistant Voice Preview Edition	Push-to-talk, status on the ring, volume dial	Replies on the device (they show in the Muse app)
Full UI	Waveshare 1.75C, AIPI Lite, SenseCAP Watcher, M5Stack StickS3	Animated avatar, push-to-talk, settings, images on most boards	Spoken replies without your own text-to-speech
Linux	Raspberry Pi 3B+, 4, 5 and Zero 2 W	Shell commands, file read and write, health reports	Voice or a screen UI

Boards with PSRAM also run the home-network tunnel, which lets Muse reach devices you already own and anything you build with a local HTTP API. Boards without PSRAM, like the classic ESP32 and the ESP32-C6, skip it. You can also give Muse new commands of your own on both SDKs. Check a board you own with Does my board run Muse?, or compare them all in the Muse board guide.

Voice, screens and camera: the details

Voice

Voice input is push-to-talk. You press a button, the board sends a voice note, and Muse transcribes it and answers in writing. Boards with a screen show the answer as captions; on the Home Assistant Voice PE, replies show up in the Muse app. For spoken answers, you send each reply to a text-to-speech API of your choice at the SDK's start_tts hook.

Screens and images

Most full UI boards and several status boards show pictures Muse sends. E-paper is slow: a second or two per refresh on the reTerminal E1001, and about 30 seconds on the color E1002. Some boards without PSRAM, like the Waveshare C6 1.8, can't show images and get replies as scrolling text.

Camera

The Seeed SenseCAP Watcher is the only board with camera support, and it's off by default. Turn on CONFIG_MUSE_WATCHER_CAMERA=y and rebuild, and Muse can call camera.capture to get a JPEG. Photo attachments to voice messages are not included, and other boards' cameras, like the M5Stack CoreS3's, aren't used yet. The Watcher board page has the details.

What you need: account, app and computer

Muse. It's rolling out in the US, and Meta says it's "free for most of what people need, with subscription plans for people who want to do more".
The Muse app on iOS or Android. Gadgets pair under Settings > Devices with Developer mode on, and show up with a "MuseGadget" prefix.
An SDK token. Get one at gadgets.muse.ai under Account > SDK tokens. Every gadget needs one to pair, including ones you build for yourself.
For ESP32 boards: a USB cable that carries data, a computer running macOS or Linux, and ESP-IDF version 6.0.1. Other versions aren't supported.
For a Linux box: Bluetooth LE, Raspberry Pi OS Bullseye, Debian 11 or Ubuntu 22.04 (or later), and an account with sudo.

The SDK READMEs don't list a paid Muse plan as a requirement. Muse Home Link, Meta's own Wi-Fi gadget, is different: it's "Free with an active Muse subscription in the United States only, limit one per subscriber," and "Claiming holds your place in line; it isn't an order." The page doesn't say whether the free tier counts.

Limits and risks to know

It's a hobby project. Meta's page warns that side effects of tinkering "may include bricked boards, voided warranties, brownouts, or bankruptcies."
Pairing isn't verified. The SDK says pairing "has no manufacturer verification and can't prevent an active man-in-the-middle attack." Set gadgets up on a network you trust.
Your token ships in the firmware. Treat it as an identifier, not a password, and revoke it if it leaks. Meta also "strongly recommend[s] enabling NVS encryption" so stored Wi-Fi credentials can't be read off the board.
Linux gadgets get real access. Muse runs commands with the permissions of the account you install it for. In the README's words, "If it can use sudo, so can Muse."
Keep boards reflashable. Don't enable Secure Boot, flash encryption or CONFIG_HOMEHUB_PAIRING_EFUSE_AUTH on a board you want to keep reflashing.
The hardware isn't Meta's. "Devices shown here are made and sold by other companies, and Meta doesn't endorse or warrant them."

More in the home network security guide.

Muse Gadget SDK terms: the key points

The token terms are at gadgets.muse.ai/sdk-terms. Read them in full before you share a device. This summary quotes them where the wording matters, and it isn't legal advice.

Permitted use. Tokens are "for personal, non-commercial use with your own Muse account and for devices you build and share" under the terms' device-sharing section.
Device limits. "You may embed it in no more than 50 devices that you make available to others. A Token may be linked to no more than 50 total devices."
No selling. A token may not go into a device "that you sell for any payment or other consideration, that you advertise, offer, or list publicly or through any marketplace or application store", or one that's part of a promotion or reward.
Other distribution. "Any other distribution requires Meta's prior written permission." You also may not imply that Meta made or endorsed the device.
Other people's data. If you give a device to someone else, you must tell them what it does with their information before they pair it, and you may not keep or reuse their prompts or data.
No support. The SDK and tokens "are not a supported product and not a developer platform. They may change, stop working, or be withdrawn at any time".
Revocation. Meta may revoke a token. After that, you must "remove the Token from any device you have made available to others".
Code vs tokens. The code is Apache 2.0, but "The source code license does not grant any right to Gadget SDK Tokens."

The code license has exceptions too: the bundled minimp3 decoder is CC0-1.0, pixel_font.c is BSD-2-Clause, and "The Apache License does not cover the Jollybot avatar."

What the terms mean for your build

A gadget for yourself: this is the personal, non-commercial use the terms describe.
A gadget for family or a friend: allowed within the 50-device limits, if you tell them what it does with their information before they pair it.
Kits or finished gadgets for sale with a token inside: not allowed without Meta's written permission.
Forking or selling the code: Apache 2.0 allows it, commercial use included, as long as you keep the license and notices. The limit is on Muse-connected devices, not the code.

More on licenses in open source vs closed AI hardware.

Questions people ask

Can I sell a Muse gadget I built?

Not with a Muse SDK token inside. The terms bar tokens in any device you sell, advertise or list publicly, and any other distribution needs Meta's prior written permission. The SDK code itself is Apache 2.0, so you can fork it and sell your own code.

How many devices can one SDK token pair with?

A token may be linked to no more than 50 devices in total, and you may embed it in no more than 50 devices that you make available to others.

Do Muse gadgets need a paid Muse subscription?

The SDK READMEs list the Muse app, an SDK token and the hardware, not a paid plan. Muse Home Link is different: Meta offers it free with an active Muse subscription in the United States only, one per subscriber.

Can Muse gadgets talk back?

Not by default. Replies are text, shown as captions or in the Muse app. You can add spoken replies with a text-to-speech API at the SDK's start_tts hook.

Sources

Prices and details checked October 5, 2026.