Reachy Mini: the $300 open source robot you can actually hack — Andres Marafioti, Hugging Face

At a robotics club in Zurich, Andres Marafioti watched humanoid robots box. The experience was impressive and a little disturbing: machines were becoming capable enough to fight, while companies were proposing home robots that could water plants or scroll TikTok. Marafioti, who introduces himself as Andy and leads multimodal research at Hugging Face, starts with the gap between that progress and who can afford to experiment with it.

Marafioti puts the robots he is discussing at roughly $50,000 and upward. He estimates Waymo vehicles in the mid-six figures; his aside about their presence in London is something he has heard, not seen. These are expensive platforms on which to discover what an everyday interaction with a robot should feel like.

Their shapes impose another constraint. A humanoid looks familiar, which helps someone form an expectation of its capabilities. But hardware does not have to follow biology. Marafioti proposes a spider-shaped machine as a potentially faster, more agile, more stable alternative. Copying a human body narrows the design space before anyone has explored what other forms might offer.

The practical test is a classroom: a high school is unlikely to buy ten $50,000 humanoids for students to play with. Enterprise-oriented machines are also difficult to adapt, and their appearance does not necessarily invite connection. Robotics capability is advancing faster than access to robotics experimentation.

Voice software offers a different starting point. Commercial options include Gradium, GPT Realtime, and the ubiquitous, if imperfect, Siri. Open models include Voxtral and Kokoro, which Marafioti highlights as an 80-million-parameter model that sounds good. Speech-understanding models and Hugging Face’s speech-to-speech pipeline provide the pieces for assembling a voice agent yourself.

Having those pieces does not settle how people should talk with robots. Marafioti wants that experience to develop through broad experimentation, much as computers developed through a hacker culture, rather than being determined by a single company or group. Reachy Mini is designed for hackers, researchers, students, and anyone with a computer who wants to try something.

Its expressive, nonhuman form is deliberate. It can be something you talk to without presenting itself as a replacement person. That changes the starting question from how to imitate a human to what kinds of relationships and behaviors this new object might support.

Reachy Mini ships unassembled. Building it is meant to teach owners how its parts fit together, so replacing a broken component becomes a familiar operation: order the part and swap it. Marafioti reports positive feedback on assembly and sees that knowledge as central to repairability. Ease of use, he acknowledges, is still improving; the hardware comes with software tools intended to make development approachable.

The talk presents two hardware options at the following historical prices; the official overview has since updated its pricing.

The cheaper version suits people who do not need onboard compute or a battery. Marafioti says it is also sold in bulk to high schools and universities for experimentation.

Community modifications make the idea concrete. One owner turns the robot into a Halloween pumpkin using 3D-printed parts, replacement antennas, a covering over the body, and lights. The underlying robot needs no major redesign: changing its exterior is enough to give it a different character.

Another owner discovers that petting the robot and having it react can be enjoyable in its own right. An audience member asks whether it purrs. Marafioti’s answer is that you can make it purr—not that purring is already a built-in behavior. These experiments let owners develop their own intuition for what the robot should be.

Taking out a keyboard to address a humanoid would be an awkward default interaction. Voice is a more natural candidate, so the Reachy Mini Conversation App supplies tools for building that experience. Marafioti introduces a prerecorded demonstration, filmed on his phone that morning.

The robot begins with a lobster-themed personality: it is functioning within acceptable parameters, but a good lobster joke would improve its day. Asked to take a photo and describe what is in front of it, it reports a person taking a mirror selfie, wearing a white T-shirt with a yellow emoji and orange pants. It then turns the visual description into another lobster joke, this time at the pants’ expense.

The interlocutor promises to change before the talk, then asks the robot to show happiness. Its spoken response agrees, while warning against expecting a lobster-themed dance of joy. The sequence brings together personality, a camera request, a visual description, and an emotion request within one conversation. After the recording, Marafioti offers attendees the chance to talk to the physical robot themselves.

Marafioti describes the models and agents as open source, but running them locally still requires compute that many owners do not have. Hosted inference makes the conversation app accessible without a local GPU. Marafioti reports 7,500 robots shipped and says conversation is their most-used app. That creates a serving problem as well as a robot-control problem.

The system has three layers. At its center is the speech-to-speech project Marafioti has maintained at Hugging Face for about two years. Its turn-processing path is:

1. Detect speech. Voice activity detection identifies when someone is talking.
2. Transcribe incrementally. Parakeet converts speech to text. Marafioti says the deployment transcribes every 150 milliseconds and returns partial transcriptions so the robot can react before the utterance is complete.
3. Generate a response and actions. The completed transcription goes to an LLM, which can reply and call tools for movement or camera use.
4. Synthesize speech. Qwen3-TTS turns the response into audio.

Above that pipeline, the robot application owns the physical interaction: microphone input, speaker output, echo cancellation, tool dispatch, emotion behaviors, camera access, and face tracking. Echo cancellation matters because the robot must hear the person without treating its own speech as fresh input. Tool dispatch connects the language model’s requested actions to the robot’s capabilities. Owners can modify or replace the speech pipeline; the default service runs on Hugging Face Inference Endpoints.

The deployment layer scales conversation compute according to the number of connected robots, while LLM inference runs on separate endpoints. Marafioti says the team is using Qwen 3.5 27B, having made it fast enough for this application. Conversation workers have a practical concurrency limit before latency rises too far, but their connection count alone does not describe the LLM load.

Consider his example: one worker has eight users talking frequently, while another has eight users who are silent. Both workers have the same number of connections, yet their demand for language-model inference is very different. Separating LLM capacity from conversation workers allows it to scale with actual usage, reducing resources tied up behind quiet connections.

Qwen3-TTS offered the speech quality Marafioti had been waiting for, but the released implementation did not deliver the latency he expected from the technical report. He spent roughly two weeks working with Codex to improve it. The distinction is between the released implementation and the paper’s serving system: the latter used an internal vLLM engine with compilation and CUDA graph optimizations. Its latency results were not measurements of the default implementation.

The first obstacle was output delivery. The implementation generated the whole response before returning audio. For a ten-second utterance, a listener had to wait until all ten seconds had been generated before hearing the beginning. Streaming separates the start of playback from completion of generation: the first available audio can be delivered while later audio is still being produced.

The next obstacle was repeated CPU–GPU coordination during autoregressive generation. Marafioti describes this as 500 steps per audio packet, with coordination at each step. The optimization target is the repeated host involvement in that loop. Capturing and replaying GPU work can reduce the overhead, but the model’s dynamic key-value cache was changing shape as the input grew, obstructing the execution strategy he wanted.

The team replaced the dynamic cache with a static KV cache, allocating more memory up front to keep its shape stable. That enabled CUDA graph capture and faster generation.

These changes address different parts of the delay: streaming advances delivery, while stable GPU execution accelerates the work producing the audio.

Marafioti reports a generation-speed factor rising from 0.8 to 5.8 times real time. Interpreting those numbers as audio seconds produced per wall-clock second makes their reciprocal the time needed to generate one second of audio:

for speed in (0.8, 5.8):
    milliseconds_per_audio_second = 1000 / speed
    print(f"{speed:.1f}x real time: {milliseconds_per_audio_second:.0f} ms")

That gives approximately 1,250 milliseconds and 172 milliseconds, respectively, consistent with his corrected verbal approximation of about 1.2 seconds versus 200 milliseconds. Marafioti also reports that time to first audio fell from several seconds, depending on the output, to a few milliseconds. The talk does not specify hardware, workload, or warmup conditions for these figures.

A second recorded demonstration shows a Hugging Face Space cloning selected voices and synthesizing pasted text in real time. One sample gives the recurring lobster a new voice; another describes reconstructing a voice from a short fragment of sound. The demonstration makes the intended interaction tangible: choose a voice, supply text, and begin hearing the result promptly.

The synthesized demo narration claims first-token latency under 200 milliseconds and generation at four times real time. These are separate claims from the preceding spoken figures, with different terminology and no shared measurement conditions supplied. Marafioti names the open-source implementation FasterQwen3TTS, available independently or through Reachy Mini’s voice agent. The current repository’s benchmark table also distinguishes throughput from relative speedup: a 5.8-fold speedup is not the same quantity as generating at 5.8 times real time.

Marafioti says the online demo has seen consistent daily use since its release roughly two months earlier. But the model’s time to first audio is only part of what a listener experiences. Requests and audio must also pass through the serving infrastructure. In this deployment, Marafioti says infrastructure overhead takes about as long as model processing. Once synthesis becomes fast, that surrounding overhead becomes a substantial part of the user’s wait. A responsive voice agent therefore needs an end-to-end latency budget, not just a fast model measurement.

The supplied conversation experience is a starting point. Marafioti wants people to develop their own interactions, with that work open to a community rather than gated behind expensive robots. Providing hardware, models, and application tools serves the same goal: letting more people participate in deciding how robots behave around us.

For the movement application running on the onstage robot, Marafioti says he gave Codex the robot repository and a description of the desired behavior, and it produced the app in one shot. He uses that example to invite even noncoders to begin experimenting. The result he points to is a specific movement app, demonstrating how an accessible repository can shorten the path from an idea to a behavior on the robot.

The Q&A first clarifies where applications execute. Many apps that do not require a GPU can run directly on the Raspberry Pi-equipped robot, within that hardware’s limits. A laptop can supply compute instead. Marafioti names Java and Python as possibilities and tentatively suggests HTML; this is a claim about flexibility in building applications, not a list of established SDKs. The official hardware overview explicitly documents Python support.

Hardware extensibility requires more hands-on work. Asked about plugins, extra servos, or making the robot move around a room, Marafioti says some hacking is necessary. The team tries to make its open-source robots fit together: he cites the SO-100 and SO-101 arms, and a three-wheel base called Kiwi designed to accept Reachy Mini. He has not seen that mobile combination implemented, though he says the parts were designed to fit. Physical composability is an invitation to build, not a demonstrated turnkey mobility system.

The final question returns to Qwen3-TTS: beyond streaming and speed, what was missing? Marafioti describes the original implementation as functionally quite complete but generally slow, with the feel of a research implementation. He says Qwen’s hosted API is fast and speculates that the gap might encourage API use; that commercial explanation is his interpretation.

His own optimized implementation has a different maintenance burden. Users report cases that do not work because the model supports more behaviors than his initial optimization covered. Those reports require additional implementation. The closing distinction is useful for anyone adapting research software: preserving a model’s range of capabilities while making its common path fast is ongoing engineering work.