Apps, AI Integration and the Hugging Face Ecosystem

5.1 The genuinely novel part

Everything documented so far — a Stewart-platform head, a documented SDK, a local HTTP daemon — is good engineering that other companies could have done. The part of Reachy Mini that has no real precedent in this hub is how software reaches it.

Reachy Mini applications are published as Hugging Face Spaces. A Space is the ordinary unit of a hosted application on the Hugging Face hub — the same object people already use to publish model demonstrations. An application for this robot is not a special artefact in a proprietary store. It is a normal repository on a platform that already had millions of them.

From the robot’s dashboard, a browser interface served by the daemon, a community application is installed with one click. No code is required to install or run one.

5.2 Why publishing on existing infrastructure matters

This choice is worth examining because it is the clearest expression of why Hugging Face buying a robotics company produced something structurally different from a robotics company building an app store.

An app store is expensive: hosting, identity, discovery, moderation, payments, review. Building one for a niche robot is not economic, which is why most small robots have no software ecosystem, and the ones that do have a handful of vendor-written demonstrations. The Cozmo dive in this hub is the illustration — its “ecosystem” was Code Lab, an official SDK and one volunteer library.

Pollen and Hugging Face did not build any of that. They reused a distribution system that already existed, that developers already had accounts on, and whose conventions they already knew. The marginal cost of the Reachy Mini app store was close to zero.

The durability consequence is the interesting one. Because applications are ordinary repositories, they are:

• cloneable — an application is a git repository, not a store entry
• inspectable — the source is the distribution format
• forkable — an abandoned application can be picked up by anyone
• portable in principle — nothing about the format requires Hugging Face to serve it

That is a materially better position than a proprietary store, where an application that is delisted ceases to exist for everyone.

5.3 The dashboard and the REST API

The dashboard is the no-code surface: browse, install, start and stop applications.

Underneath, the same operations are available over the daemon’s REST API. The documentation names endpoints for starting an application (POST /api/apps/start-app/), stopping the current application, and listing installed applications.

Both routes reach the same daemon described in Vol 4. There is no privileged path — the dashboard is a client like any other.

5.4 Writing an application

The published recipe is short:

1. Call the application’s logic from a specific run method.
2. Wrap it as a Python package.
3. Publish it as a Space.

A Reachy Mini App Assistant is documented as generating the boilerplate.

The robot ships with more than 15 pre-loaded behaviours, so a new owner has something to run before writing anything.

5.5 AI integration

This is the reason the robot exists, and it should be described precisely rather than enthusiastically.

Reachy Mini is positioned as the physical front end for machine-learning models, and it plugs into LeRobot, Hugging Face’s robotics and imitation-learning library. The documentation carries a section on connecting large language models and building applications around them.

The architecture from Vol 4 is what makes this practical. Because the SDK is a network client of the daemon, model inference does not have to run on the robot. A large model can run on a workstation, or against a hosted endpoint, while the daemon on a Raspberry Pi Compute Module handles only motion and sensing. The robot is a body for software that runs wherever it runs best.

Set against the Anki machines in this hub, the difference is architectural rather than one of ambition. Vector also used remote computation for its language features — but through a single vendor endpoint that the owner did not control and could not replace, which is precisely why it went silent. Here the remote computation is whatever the owner points the application at. The capability is similar; the dependency is not.

5.6 The honest caveat: this is where a vendor dependency does exist

Every other volume of this dive has argued that Reachy Mini is built to survive its vendor. This volume is where that argument needs a qualification, and it would be dishonest to leave it out.

The one-click app store is a Hugging Face service. If Hugging Face changed its Spaces product, restricted it, or disappeared, the convenience of installing community applications would change with it. The dashboard’s install button points at somebody else’s infrastructure.

Three things bound that risk, and they are why it is a qualification rather than a refutation:

• The robot does not need the store to work. The daemon, the SDK, the simulator and any locally installed application are entirely local. A Reachy Mini with no internet connection is a working robot.
• Applications are git repositories, so an application that matters can be cloned and kept.
• Nothing in the format is proprietary — a Python package with a run method could be served from anywhere.

Compare the failure this hub has already documented: when Vector’s cloud went dark, the robot lost a core capability and stayed broken until volunteers built a replacement server. If Hugging Face’s Spaces disappeared, Reachy Mini owners would lose a convenient way to discover and install applications and would keep every application they had already installed, plus the ability to write more.

Those are different magnitudes of problem. But the dependency is real, it is the only one in this dive, and it belongs on the record.

5.7 What is not established

• Curation and moderation policy for Reachy Mini applications on Spaces was not established during this research.
• The size and activity of the application catalogue was not surveyed. The distribution mechanism is documented; how much has actually been published through it is not assessed here.
• Whether the app format has been used outside Hugging Face in practice, as the portability argument above suggests it could be.

Sources

• huggingface.co/docs/reachy_mini, “Building & Publishing Apps” — the run method, the Python package structure, publishing as a Space, and the App Assistant.
• huggingface.co/docs/reachy_mini, “Core Concepts & Architecture” and the SDK documentation — the dashboard, the REST endpoints for starting, stopping and listing applications, and the AI integration section.
• huggingface.co/blog/pollen-robotics/make-and-publish-your-reachy-mini-apps — the one-click install flow from the dashboard.
• huggingface.co/blog/reachy-mini — the “15+ robot behaviours” figure and the LeRobot integration.
• huggingface.co/spaces/pollen-robotics/Reachy_Mini — the Space presence.
• The Anki Vector dive in this hub — for the cloud-dependency comparison drawn above.