Skip to content
ELEMENT 31

Latency budget

A latency budget is the time a specific robot can wait for an answer from the inference pool before it must act on its own. Substrate holds each robot to its own budget.

· 2 min read

IN SHORT

A latency budget is the amount of time a specific robot can wait for an answer from the inference pool before it must act on its own. Substrate holds each robot on a Czar Grid to its own budget, and a robot whose budget runs out receives no answer rather than a late one; it falls back to the on-board model it carries for reflexes.

A latency budget is the amount of time a specific robot can wait for an answer from the inference pool before it must act on its own. Substrate holds each robot to its own budget, and a robot whose budget runs out falls back to its on-board model.

Why it matters

A robot in motion cannot wait indefinitely for a decision. The question is not whether the pool is fast in general but whether this robot gets its answer before the moment it needs it. Different machines have different moments: a pick arm pausing over a tote has a different tolerance than a humanoid walking a corridor.

A budget makes that tolerance explicit. The robot vendor and the integrator know what their machine can accept, and the pool is held to it. If the pool cannot meet the budget, the robot does not get a late answer; it gets no answer, and it falls back.

This is also why the pool belongs in the building. A distant cloud adds a round trip the budget cannot absorb, and a lost connection breaks it entirely.

How it works at Element 31

Each robot on a Czar Grid has its own latency budget. Substrate schedules inference across the pool with those budgets in view, so that a floor of mixed machines from more than one vendor can share the pool without the slowest consumer dragging the fastest.

When a budget cannot be met, the robot falls back to the model it carries for reflexes. Safety was never in the pool: stops, speed limits, and motion limits stay on the machine. A pool that fails leaves a robot that stops, not one that guesses.

The budget does not change with posture or route. An air-gapped Grid, a connected Grid, a Facility Direct Grid, and a Czar Chassis Grid all hold robots to their budgets the same way, because the answer travels only over the facility network in every case.

The budget is a property of the robot and the task, agreed at integration, not a figure Element 31 publishes. The Czar Grid and Technology pages describe how the pool is sized to a floor so that budgets hold under load.

Questions this raises

Who sets a robot's latency budget?
The robot vendor and the integrator know what their machine can accept for a given decision, and the budget is agreed when the robot is brought onto the pool. It is a property of the robot and the task, not a figure Element 31 publishes.
Do different robots on the same Grid have different budgets?
Yes. A pick arm pausing over a tote tolerates a different wait than a humanoid walking a corridor. Substrate holds each to its own budget so that machines from more than one vendor can share the pool without one starving another.
What happens when the budget runs out?
The robot does not get a late answer. It falls back to its on-board model for that decision and asks the pool again for the next. Stops, speed limits, and motion limits were on the robot all along.

KEEP READING

Related.