A bill that sits still
A metered bill turns every decision on the floor into a compute decision. A Grid is one line for the configured pool, fixed for the term, that does not move when a fleet is added or a vendor changes.
· 4 min read
IN SHORT
The subscription for a configured Grid is one line, hardware, platform license, and sustainment together, fixed for the term. It does not move when more robots join the pool, when a second vendor's fleet arrives, or when the floor's robots start making more requests. The operator budgets the pool as a cost of the building rather than forecasting usage, and fleet decisions stop being compute negotiations.
A meter changes behavior. When a facility pays for compute by the robot, by the request, or by the volume of data sent, the automation lead learns to ration it. Fewer perception calls on a quiet shift. A second vendor's fleet kept off the pool until the budget cycle allows. A model adaptation postponed because the captures would count against something. None of these are engineering decisions. They are decisions a bill made for the floor. A Grid is priced so the bill does not make them.
One line, set by the Grid
The subscription for a configured Grid is one line: hardware, platform license, and sustainment together, fixed for the term. The line is set by the configured Grid, which is sized to the floor the pool will serve. It is not set by the number of robots drawing from it, the number of requests they make, or the amount of data the floor produces. Robots joining the pool leave it where it is.
This follows from how the pool is configured in the first place. The proposal lists the fleets, the models they need, and their latency budgets, and the Grid is configured against all of that. Once configured, serving the floor is what the Grid is for, and there is nothing further to meter. The pricing page states the form plainly.
What the line holds through
A floor that is working well gets busier in ways that would move a metered bill. A second vendor's humanoids arrive and begin asking the pool for language and decisions. The automation team authors more site tasks in Agency Studio and the robots run them more often. Adaptation on the site's own captures makes the perception models better, so the robots trust the pool for more and fall back less. Peak season fills every aisle, and every mobile robot is asking for perception at once.
Under a meter, each of those is a cost event. Under the Grid subscription, none of them is. The line was set for the configured floor, and these are the floor being used as configured. The record on the pool shows the operator how usage changed, but the bill does not.
Fleet decisions stop being compute decisions
The practical effect shows up in how the floor is run. When the operations lead wants to bring a new vendor's pick arms onto a line, the questions are about the floor: the zones, the speeds, the stops, the latency budget the vendor sets, the route the integrator declares. The question of what it does to the compute bill does not arise, because the answer is nothing.
The same is true of replacing a vendor. The departing fleet stops drawing from the pool, the incoming fleet is connected under its own budget, and the line stays where it was. On a per-vendor or per-robot model, every change of fleet is also a renegotiation of compute. On a Grid, it is a change of fleet. The compute per robot or per building article sets out that difference in full.
What the line covers so nothing else appears
A fixed line is only reassuring if nothing is left outside it to move. The Grid subscription covers the hardware in the rack, the platform license for Substrate and Agency Studio, and sustainment for the term: signed updates, support through the customer portal, customer-initiated remote sessions, and the attestation and provenance machinery for every node. There is no separate support contract to renew and no software meter beside the hardware.
What is not in the line is also plain. The robots belong to their vendors. The facility's network and the systems the pool connects to are the site's. Those are costs the facility already carries, and the Grid does not add a moving part to them. The What a subscription for a Grid covers article walks through the boundaries.
The same line on either route
Under Facility Direct the building holds the line. Under Czar Chassis the robot vendor or integrator holds it and ships the Grid under its own name with its fleet, while Element 31 provides sustainment and attestation underneath. In both cases the structure is the same: one subscription for the configured Grid, fixed for the term, indifferent to how many robots draw from it.
An operator budgeting a floor for the long run wants costs that behave like the building's other fixed costs, so that the people running the floor can make decisions about the floor. A bill that sits still is how the pool becomes one of those costs. The How to buy page describes how each route holds it.
Questions this raises
- What would make the line change?
- The line is for the configured Grid for its term. If a site reconfigures the Grid, for example by joining more Czar nodes because the floor has grown past what the proposal anticipated, that is a change to the configuration described in the agreement. Robots joining the existing pool do not change it.
- Does a fixed line mean the site is paying for capacity it is not using while the floor is still filling?
- A Grid configured for the whole floor will have headroom while the first zones come online. That headroom is what lets the second fleet join without a new project, and it is what the pilot grows into. The alternative, sizing to the pilot and renegotiating at each step, puts a budget meeting in front of every expansion.
- Is there a usage report even though usage is not billed?
- Substrate keeps evaluation and the record on the pool, and Agency Studio records every task run. The operator can see how the pool is being used from the record on its own hardware. That visibility exists for the floor's benefit, not for a meter.
KEEP READING