Meta has published the Muse Gadgets project, allowing developers to build peripherals around an ESP32 board or a Linux computer. The repository contains device SDKs and firmware, not the Muse model or a complete local copy of Meta's service.

The distinction matters at the first design review. A gadget can collect an input, show a response or execute a narrowly defined command, but pairing still requires an SDK token and the Muse app. The practical question is therefore not simply whether the code is open. It is whether the hardware, account, network path and service permissions remain acceptable for the job.

What Meta has opened

The Muse Gadgets README describes separate ESP32 and Linux Device SDKs. The ESP32 route is aimed at displays, audio and sensors. The Linux route can turn a Raspberry Pi or another Linux host into a gadget with custom commands, including commands connected to a Home Assistant setup.

That division puts the physical interface on the developer's side and leaves Muse to interpret requests through Meta's service. It is useful for testing a button, a small display, an audio input or a limited home-automation action. It does not make every ESP32 board compatible, and it does not give the developer control over the model's weights, Meta's cloud environment or the service's retention rules.

TechCrunch reported that Meta described Muse as being powered by its Muse Spark model. That report provides context about the agent, but it is not evidence that the model or its runtime is part of the open-source gadget repository. The public documentation also does not establish that a complete gadget can operate without the app, an account, a token or a network connection.

ESP32 and Linux solve different prototype problems

ESP32 boards are a reasonable starting point when the prototype has one narrow interaction. A button can trigger a request, a display can show a short response, and a sensor can supply a defined input. Developers still need to check the board's pins, memory, power supply, peripheral drivers and firmware settings. The ESP32 product information from Espressif describes the platform family, not a compatibility list for Muse Gadgets.

Linux is better suited to a prototype that must call an existing local service, maintain a database connection or expose several custom commands. A Raspberry Pi host can use ordinary Linux tools, but that flexibility widens the failure surface. A command with excessive permissions could alter files, restart services or reach home devices. Start with read-only status checks, a dedicated non-administrator account and an allowlist of commands. Keep a manual way to stop the system.

The board price is only one cost. Firmware debugging, power testing, network setup, token handling, service changes and replacement hardware all affect the total effort. A successful demonstration on one board and one account proves only that that combination worked under those conditions.

A comparison of a microcontroller peripheral prototype and a Linux host integration

How pairing and integration work

Before flashing or pairing, the README directs developers to obtain an SDK token and review the Gadget SDK Terms. The documented pairing sequence uses the Muse app on iOS or Android: enable Developer mode under Settings > Devices, then look for a device whose name begins with “MuseGadget.” Every gadget needs a token to pair.

The token should be treated as a credential. Do not commit it to a public repository, put it in an issue report or leave it in ordinary logs. Record how it can be revoked or replaced before testing. Also document what happens if the phone is offline, the account cannot authenticate, the token expires or Meta changes the pairing flow.

Draw the data and control path before connecting a microphone, camera, sensor or household device. Mark where input enters, which component sends it onward, who receives the response and which commands can produce a real-world effect. Hardware access to a sensor does not by itself explain how the app or service processes the resulting data.

Licensing and maintenance boundaries

The repository says that Muse Gadgets is licensed under Apache License 2.0, while several listed third-party files retain their upstream licenses. The published license file grants the standard Apache copyright and patent permissions, subject to its conditions. The README also says that dependencies fetched at build time have their own licenses and that the Jollybot avatar is outside the Apache license.

That is enough for a personal code experiment only if the files actually used are tracked. Publicly distributing firmware, bundling images or selling a product adds a review step: preserve the relevant commit, list dependencies, keep their notices and check the Gadget SDK Terms. “Open source” describes the covered code; it is not a blanket permission for every asset, service or dependency in the project.

Physical risks remain separate from software licensing. Incorrect wiring, unstable power, heat and firmware errors can damage a board or connected equipment. Test with a disconnectable setup and a low-impact load. Do not make a new service dependency the only way to control a lock, heater, power circuit or other safety-sensitive device.

How this plays out outside Taiwan

For a developer in the United States, the United Kingdom, Singapore or Australia, the first purchase question is not a confirmed Muse price. The public README identifies the SDK token, app and terms as prerequisites, but it does not publish a universal hardware bundle, subscription price or country-by-country service table. A practical budget should therefore separate the board, display, power supply and shipping from engineering time and any account or service charges. Check the current Muse Gadget SDK Terms and the account's own settings before ordering parts; a low-cost ESP32 board is not evidence that the complete path is available in a particular market.

Hardware choice also depends on what each market can actually source. A US or Australian developer can use the official Raspberry Pi 5 product page to check the computer's published specifications and links to retailers, while an ESP32 buyer should start with the Espressif product information and then verify the exact board vendor, radio certifications, power adapter and local warranty. Those pages describe the platforms; neither page confirms Muse pairing or service availability. In the UK, Singapore and Australia, a reseller's stock page can change without changing Meta's service conditions, so the developer should test the intended board before designing an enclosure or ordering a batch.

Privacy work starts before a microphone or sensor is connected. In the UK, the Information Commissioner's Office says data protection by design and by default applies from the design stage through the product lifecycle. Its guidance points teams toward purpose limitation, data minimization, access controls, deletion schedules and a Data Protection Impact Assessment when processing is likely to create high risks. For a Muse prototype, that means writing down whether audio is sampled continuously or only after a button press, whether raw input is retained, which account can inspect logs and how a user can stop collection. If a prototype handles another person's information, the developer should identify the controller and processor roles rather than assuming that the hardware supplier carries every obligation.

Singapore's Personal Data Protection Commission describes the Personal Data Protection Act as governing the collection, use and disclosure of personal data by organizations. Its official introduction to the PDPA guidelines directs organizations to read the relevant guidance together with the Act. A Singapore team testing a home assistant should therefore document the purpose of each sensor, the notice given to people in the room, retention, access and deletion. The same checklist is useful elsewhere, but the legal answer depends on the country and the role of the organization.

In Australia, a team should identify the applicable privacy obligations and check the current guidance from the Office of the Australian Information Commissioner before collecting voice, household or account data. In the United States, a consumer project may face different state and sector rules depending on the data and use. Neither market should be treated as the default for a global English reader. The safe engineering step is the same: minimize the input, isolate the device, keep credentials out of logs and write a shutdown path before granting a custom command access to a real device.

Regional availability is also a service question. If the Muse app cannot be installed, the account cannot obtain a token or the terms exclude the intended use, a compatible board does not solve the problem. Record the country, app version, account type, board model and date of the test. That record makes a failed pairing reproducible and prevents a prototype result from being mistaken for a general availability claim.

Who should try it first

Muse Gadgets is best treated as a contained developer experiment. A team already comfortable with ESP32 firmware or Linux service management can begin with one non-sensitive input, one visible response and one reversible action. A status display or test notification is easier to audit than a system that can edit files or control household equipment.

Do not use a newly published SDK as the sole controller for life-safety equipment, access control or a service that must run continuously. If the requirement is fully offline operation, a replaceable model, no phone account or long-term vendor support, those requirements should be tested against the current documentation before hardware is purchased.

  1. Define the smallest low-impact action and its stop condition.
  2. Match the board, peripheral and build steps to the current SDK README.
  3. Confirm the app, Developer mode, token, account and regional terms.
  4. Use least-privilege commands and non-sensitive test data.
  5. Record the data path, dependency versions, failure behavior and credential-revocation process.

The useful result of a first test is not merely that a gadget responds. It is a documented answer about which parts are controlled by the developer, which depend on Meta and which need to be checked again when the board, account, app or service changes.

Frequently asked questions

Which devices does Muse Gadgets support?

The project provides ESP32 and Linux Device SDKs, with Raspberry Pi and other Linux hosts used as examples. The current SDK directories are the source for board and peripheral support; developers should not assume that any ESP32 board or Linux computer will pair without changes.

Can Muse Gadgets work offline?

The public README requires an SDK token for pairing and describes pairing through the Muse app. It does not establish that the full workflow can run offline. Plan for a service or network interruption to affect the prototype until Meta documents a different operating mode.

Can someone without hardware experience build one?

They can start by reading the code or using a simple, low-risk board exercise, but assembly involves firmware, wiring, power, pairing and troubleshooting. A first build should avoid locks, heaters and other equipment where a mistaken command could cause harm.