Moxie Robot Is Gone: What Happened in 2026
Embodied shut Moxie down in 2024. A new owner revived it in 2025 and closed in June 2026. What the two shutdowns…
Section
Coding Robots
Two completely different products get sold under the same name. A programmable robot is a machine a child writes instructions for. A companion robot is a machine that talks back. They share a shape and a price bracket, and they teach opposite things — one rewards precision, the other rewards conversation.
That confusion is expensive, because the buying advice is not transferable. A programmable robot is worth judging on its programming interface and the quality of its motors. A companion robot is worth judging on what it says and what it does with the audio. Buy the wrong one and the child gets a toy that does something impressive once.
This section is about the programmable side: what a child actually writes, at what age each programming style becomes usable, and which parts break first. The robot most people ask us about, Moxie, sits on the companion side and is covered separately — it is worth reading precisely because it shows what happens when the talking stops.
We have not run these robots in a classroom. What we have is published specifications, the actual programming environments where they are documented, and the failure patterns in owner reports after six months of use.
The only question that matters: what does the child actually write?
Every programmable robot is a programming environment with a body attached. The body gets photographed; the environment decides whether the thing gets used. So the first thing to establish, before price or brand, is what the child types, taps, or sequences to make it move.
There are three rungs on that ladder, and they are not interchangeable. Buying a rung too high produces a robot the child watches an adult operate. Buying a rung too low produces a robot that is abandoned the week the child works out the pattern.
Rung one: physical sequencing
The child places tiles, cards, or presses a sequence of buttons, then the robot executes. There is no screen and no syntax. What is being learned is the concept of an ordered set of instructions — that order matters, that a missing step produces a wrong result.
This is the right rung from roughly three to six and it is also where the cheap products cluster. The limitation is real: the program is only as long as the number of tiles provided, so the ceiling arrives quickly. A robot that tops out at eight instructions is a two-week toy for a bright five-year-old.
Rung two: visual blocks
The child drags blocks into a sequence on a tablet or laptop, with loops, conditions and variables. This is a genuine programming language with the syntax made forgiving — the same concepts a professional uses, without the punctuation.
This rung has the widest useful age range, roughly six to ten, and it is where most purchases should land. The detail worth checking is whether the blocks are open-ended or a fixed menu of pre-made commands. A menu of eight preset actions is a remote control with extra steps. A block language with arithmetic, loops and sensor input is a tool a child can grow inside.
Rung three: text
The child writes Python or JavaScript against an API, and the robot becomes a physical output device for code. Errors are now the child's fault in a way they were not before — a missing indent stops everything — which is precisely the lesson, and precisely why it does not work before about ten.
The critical question at this rung is documentation. A text-programmable robot without a published, current API reference is a dead end, because the child will hit a wall the parent cannot get past either. Check that the documentation is public and recently updated before you buy, not after.
Can the child climb without buying new hardware?
This is the decision that separates a good purchase from an expensive one. Many robots support one rung only, which means the toy is obsoleted by the child rather than by failure. Others support two or three, so the same body survives a growth spurt in ability.
A robot that starts at blocks and exposes a text API later is worth considerably more than a cheaper robot that only does blocks, because the second one will be outgrown in eighteen months and the first will not. When comparing prices, divide by the number of rungs — the arithmetic usually reverses the ranking.
The hardware fails in predictable places
Robots break in ways that are boring and consistent, and knowing the pattern is more useful than any spec sheet.
Servo gears strip first. Plastic gears inside the joints are designed to be the weak point, which is correct engineering and also means a dropped robot develops a limp. Check whether replacement servos are sold individually and whether the part number is published.
Wheels lose grip. Rubber treads pick up dust and lint until a robot that tracked a line perfectly starts drifting. Cleaning them fixes it; a robot with non-replaceable wheels cannot be fixed when the rubber perishes.
Charging ports die. A micro-USB port on a toy that gets plugged in daily is the most common electrical failure in the category, and a proprietary charging cable means a lost cable ends the product. Prefer USB-C, and prefer a cable that can be replaced with any other.
The app is the fragile part. Anything that requires a phone app inherits the app's lifespan. An app that has not been updated in two years is a warning, not a detail — operating system updates break old apps regularly, and a robot whose only interface is a broken app has no interface.
The demo problem
Almost every robot in this category can do one impressive thing within ten minutes of unboxing. That is a demonstration, not a capability, and the two are easy to confuse in a shop.
The question that separates them is what the robot can do on the second day, when the novelty of the first trick has gone. A robot whose activities are a list of supplied projects is a workbook — it ends when the list ends. A robot whose activities are whatever the child can express in the programming environment is a tool, and the list of possible projects is however long the child's imagination holds out.
This is why the quality of the programming environment matters more than the number of sensors. Sensors expand what is possible; the environment determines whether the child can reach it. A robot with four sensors and a fixed menu of eight commands is less capable than a robot with two sensors and a real block language.
Where the age line falls
Under five, physical sequencing is the honest ceiling — anything with a screen and blocks is an adult activity the child watches. From five to seven, blocks work if the projects are short enough to finish in one sitting, and the value comes from the child changing one thing and seeing what happens. Between eight and ten, loops and conditions become usable and this is the best window for a first real robot, because the child can hold a multi-step plan in mind. Above ten, insist on a text path: a robot that only does blocks at eleven is teaching a child something they already know.
If you are choosing between robots and the rest of a gift list, the gifts for 10 year old boys guide puts these next to the other things that survive past January, and the building toys piece covers the cheaper route into the same skills.
Questions we get asked most
What is the difference between a coding robot and a companion robot?
A coding robot is a machine the child writes instructions for, so it rewards precision — a wrong step produces a wrong result. A companion robot is a machine that talks back, so it rewards conversation and depends on a cloud service. They share a shape and a price bracket and teach opposite things. Judge a coding robot on its programming environment and motors; judge a companion robot on what it says and what it does with the audio.
At what age can a child start with a coding robot?
Physical sequencing — tiles, cards, button sequences — works from about three to six. Visual block programming with loops and conditions is usable from roughly six to ten. Text programming in Python or JavaScript does not land before about ten, because the errors become the child's responsibility in a way block languages hide. Buying a rung above the child produces a robot the child watches an adult operate.
Do coding robots teach real programming?
Block-based environments do teach real concepts — loops, conditions, variables, input and output — with the syntax made forgiving. The limitation is transfer: a child can become fluent in one block system and still struggle with text. That is why the useful question is whether the same robot supports a text path later, rather than how many blocks it offers.
What breaks first on a kids' robot?
In order: servo gears inside the joints strip when the robot is dropped, rubber wheel treads pick up lint until the line-following drifts, and micro-USB charging ports fail after months of daily plugging. The fourth failure is the app — a robot whose only interface is a phone app inherits that app's lifespan, so an app that has not been updated in two years is a warning rather than a detail.
Why do kids lose interest in coding robots after a week?
Usually because the robot is a workbook rather than a tool. A robot whose activities are a supplied list of projects ends when the list ends, and the impressive demo on day one is a demonstration rather than a capability. A robot whose activities are whatever the child can express in the programming environment keeps producing new problems, which is what actually holds attention.