Can your robot's brain live in the cloud?

This month handed robotics builders two announcements that look unrelated: AWS is deploying Cerebras wafer-scale systems for inference on Bedrock, and Moonshot shipped Kimi K3, the first open 3T-class model. Neither press release says the word “robot.” Both are about the same robotics question — the one I get asked every time I show ReachyArchi at a Summit:

Can the robot’s brain live in the cloud?

The answer has always been “it depends on which brain.” What changed this month is where the line sits.

A robot is a stack of loops, not one brain

The useful way to think about robot compute is as a hierarchy of loops, each with a non-negotiable latency budget:

Loop	Frequency	Budget	Where it must run
Control (balance, motors, collision)	100–1000 Hz	~1–10 ms	On-board, always
Perception (vision, SLAM, grasping)	10–60 Hz	~15–100 ms	On-board / edge
Reasoning (task planning, dialogue, replanning)	0.1–2 Hz	0.5–5 s	The contested zone
Fleet & learning (retraining, memory, analytics)	offline	minutes+	Cloud, obviously

The first two rows are settled physics: a 50–150 ms network round-trip — before any inference happens — disqualifies the cloud for anything that keeps the robot upright or stops it from hitting someone. No inference chip changes that, and no responsible architecture puts a safety loop behind a WAN link. This is why the industry converged on the pattern Figure made explicit with Helix: a fast on-board system running reflexes at high frequency, and a slow deliberative system that thinks in seconds.

The fourth row was never in question — I wrote about that side of the stack in Physical AI for Manufacturing: simulation, fleet data, and training pipelines are where the cloud already carries robotics.

The interesting row is the third. And both of this month’s announcements aim squarely at it.

What Cerebras changes: the slow brain stops being embarrassing

The reasoning loop tolerates seconds — but how many seconds decides whether cloud reasoning is usable at all. A reasoning model that streams a long thinking trace at GPU decode speeds takes 8–15 seconds to answer “the box fell, what now?”. I’ve lived this with ReachyArchi: in a voice interaction, anything past a couple of seconds and the human disengages. A robot that freezes for twelve seconds isn’t deliberate; it’s broken.

Decode speed is exactly the axis the Trainium + CS-3 solution attacks. At thousands of tokens per second, a full reasoning trace plus a structured plan collapses from double-digit seconds to about one — at which point the network RTT that used to be the excuse becomes a rounding error inside a comfortable budget. The economics of the split flip:

• Replanning at conversation speed. The robot’s deliberative layer can consult a frontier-class model mid-task without turning the interaction into a loading screen.
• The agent loop compresses. A cloud planner that thinks, calls a tool (fleet state, map service, inventory API), reads the result, and thinks again pays the decode tax on every turn — the same reason Cerebras’s existing customers skew toward agentic coding applies verbatim to agentic robots.
• It arrives inside Bedrock. The robot fleet’s cloud brain is an API call in the same account as its data pipeline, with IAM, isolation, and observability you already operate — not a specialty endpoint bolted on the side.

What Kimi K3 changes: the brain you can bring home

K3 is not a robotics model. It’s something more useful to this argument: proof that a frontier-class generalist brain — native vision, 1M-token context, long-horizon agentic training — now ships with downloadable weights.

Three reasons that matters for robotics specifically:

Vision-native planning. The deliberative layer of a robot consumes camera frames and produces plans. A cloud brain that natively reasons over images can take the scene as-is, not a lossy text description of it.

Sovereignty. Factories, hospitals, and defense sites — the places deploying robots first — are exactly the places whose camera streams cannot leave the premises. An open 3T-class model means the “cloud brain” can be a private cloud brain: same architecture, weights running in your VPC or your datacenter. At 2.8T parameters and a recommended 64-accelerator supernode, it is emphatically not an edge deployment — but it doesn’t need to be. It needs to be yours.

Context as world model. A million tokens of context is enough to hold a facility map, task history, safety procedures, and the last hour of observations in the prompt. For a deliberative planner, that’s a working memory no on-board model can afford.

One caveat I’d underline twice before wiring K3 to actuators: Moonshot’s own model card warns of “excessive proactiveness” — the model makes decisions on your behalf when intent is ambiguous. In a coding agent, that’s initiative. In an embodied system, unrequested initiative is a safety defect. The mitigation is the same discipline I described in teaching a robot to pick up a cube: the LLM proposes structured actions; a deterministic layer validates and executes them. The model card telling you to constrain the model via AGENTS.md is the manufacturer admitting the guardrails are your job.

The architecture that wins

Put the pieces together and the answer to the title question is: the reflexes never leave the robot; the brain increasingly should.

On-board (owns safety)          Cloud (owns intelligence)
─────────────────────           ─────────────────────────
Control loop     1kHz           Deliberative planner (Bedrock,
Perception/VLA  ~30Hz    <────► soon Cerebras-accelerated —
Action validator                or self-hosted open weights)
Connectivity fallback           Fleet memory & learning

The on-board side must be able to degrade gracefully to safe behavior when the link drops — stop, hold, resume local routine — which is precisely why it owns validation and safety, never the cloud. The cloud side gets the two things this month delivered: an order-of-magnitude faster reasoning loop, and the option to own the weights outright.

For two years, “put the robot’s brain in the cloud” failed on latency or failed on data governance. Cerebras-class decode answers the first objection; open 3T-class weights answer the second. The contested zone is being settled — in the cloud’s favor.

I’ll be testing this thesis the practical way: ReachyArchi’s next iteration gets a deliberative layer behind Bedrock, and when the Cerebras-backed endpoints go live I’ll publish real robot-loop latency numbers. If you’re building in this space, tell me what your loops look like.