How DEPLOY tracks pricing claims: Projected price versus available price

"How much does a humanoid robot cost" is a question that collapses three different artifacts into one number. A maker's projection of where pricing will land at scale is one artifact. A consumer-direct pre-order price with a deposit and a delivery timeline is a second artifact. An enterprise-contract price negotiated under non-disclosure and bundled with integration services is a third. Each is editorially meaningful. None of them is interchangeable with the others, and the framework's value is naming which one a given price claim actually anchors against.

The methodology rests on the canonical constructs defined at /methodology/what-verified-means: the verified-vs-claimed boundary, source discipline, and cap-flag-as-trust-signal. Pricing claims apply the same constructs to a pricing-specific layer. A price that clears counterparty verification (a customer's purchase order, a regulator-filed transaction, a publicly-listed catalog price) is verified pricing. A price stated in maker communication without independent confirmation is claimed pricing. A price for which no verifiable evidence exists at the threshold DEPLOY operates is cap-flagged.

Projected pricing versus available pricing

Projected pricing is what a maker says a product will cost at some future state: at scale, at full production, at the consumer-rollout milestone, at the post-pilot pricing-down point. The projection is editorially significant; makers tell operators where pricing is expected to land, and the projection itself shapes operator expectations about category economics. The projection is not the same artifact as an available price. Available pricing is what an operator can actually pay today for delivery on a stated timeline, backed by a publicly listed catalog price, a transactional quote, or a pre-order structure with deposit and delivery terms.

DEPLOY treats projected pricing as claimed-pricing-with- maker-context. The price is associated with the maker's published projection; the projection's source is cited; the conditionality of the projection (at scale, at full production) is preserved. DEPLOY does not treat the projection as the available price; a reader querying "what does Tesla Optimus cost" should encounter the projection as projection, not as the price at which the robot can be purchased. The verified-vs-claimed boundary operates at the pricing layer the same way it operates at the deployment-claim layer.

Pre-order versus production unit pricing

Pre-order pricing is its own category. A pre-order is a reservation backed by a deposit; the unit price is stated, a delivery timeline is published, and an operator can place a binding order against the maker's published structure. Pre-order pricing is verified-by-disclosure: the price is on the maker's own commercial surface, with a published transaction structure operators can act against. It is not the same artifact as a production-unit price that an operator has paid and received delivery against; pre-order structures sometimes ship at modified prices when the delivery window opens, and pre-order timelines slip in ways that change what an operator effectively paid.

The framework names pre-order pricing as pre-order pricing rather than as production pricing, even when the maker uses both terms interchangeably. The verification surface for the pre-order is the maker's own commerce structure; the verification surface for the production-unit price is the operator's transaction record at delivery, which until delivery does not exist as a verifiable artifact.

"At scale" pricing claims versus near-term pricing

At-scale pricing claims are projections contingent on reaching high-volume production. The contingency is part of the claim; without it, the price is not the at-scale price. DEPLOY surfaces both the projected price and the contingency when citing at-scale claims. A claim that strips the contingency and treats the at-scale price as the near-term price misframes the artifact; the framework preserves the contingency because the contingency is what distinguishes the projection from an executable transaction.

The canonical reference for the at-scale-versus-near-term distinction in DEPLOY's humanoid coverage is Tesla. Elon Musk has repeatedly framed Optimus consumer pricing at $20,000 to $30,000 at scale, most recently reiterated at the October 2024 We Robot event as a long-term consumer price contingent on reaching high-volume production. The $20-30K range is the projected at-scale price. The near-term price is not the at-scale price; Tesla has not opened consumer orders for Optimus, no dealer or enterprise sales channel is live, and no public reservation queue exists at the at-scale figure. DEPLOY surfaces the projection with its conditionality preserved, not as an executable transaction price.

1X's NEO inverts the structure with an executable pre-order pricing structure: $20,000 Early Access or $499 per month subscription, $200 deposit, first US shipments slated for 2026. The pricing is pre-order, the deposit structure is published, and the subscription alternative is part of the maker's commerce surface. DEPLOY treats NEO pricing as pre-order verified rather than at-scale projected; the verification anchor is the maker's published commercial structure, with the executable transaction terms operators can act against.

Cap-flag application across enterprise humanoid pricing

The enterprise humanoid category is where cap-flag pricing discipline matters most. Apptronik Apollo, Agility Digit, and Figure 02 all operate against Fortune-500 enterprise contracts; none of the three publishes the per-unit price their customers paid. The contracts are real (Apptronik's Apollo at Mercedes-Benz, GXO, and Jabil; Agility's Digit at GXO Flowery Branch; Figure 02 at BMW Spartanburg); the per-unit prices are not. Industry-analyst estimates place these robots in the $50,000 to $250,000 range depending on configuration, integration scope, and contract terms; the estimates are analyst projections rather than counterparty-confirmed transaction prices.

DEPLOY cap-flags the per-unit enterprise pricing across the three makers rather than estimating it. The cap-flag is the published pricing-evidence record: contracts confirmed, deployments verified, per-unit pricing not publicly disclosed at the verification threshold DEPLOY operates. Applying the framework recursively, the cap-flag on enterprise pricing is the same discipline DEPLOY asks operators to apply to any maker's per-unit pricing claim: the contract surface and the deployment surface are editorially distinct from the per-unit transaction surface, and the absence of public per-unit transaction evidence is the verifiable artifact, not a gap to fill with a plausible-sounding estimate.

Unitree occupies the structural inverse. The G1 base price is $16,000 and the R1 base price is $5,900, both publicly listed and available to research and developer customers without enterprise-contract bundling. Unitree's pricing transparency is verified by maker's-own-catalog surface plus independent trade press confirmation; the price is the operator-payable price. For operators evaluating the floor of what humanoid hardware actually costs without enterprise integration surcharge, Unitree's published pricing is the closest available verified reference; the enterprise-bundled pricing on Digit, Apollo, and Figure 02 is structurally different because the per-unit price includes customer-relationship infrastructure that Unitree explicitly strips.

Where to go next

Operators evaluating pricing for a specific maker should start at the registry's entity surface (registry.deploy.report), which catalogs pricing posture per maker (verified, projected, pre-order, cap-flagged) at the entity layer. DEPLOY's consumer surfaces will provide entity-level pricing overviews at dedicated price routes once published; the methodology constructs defined at the pillar govern what surfaces on those consumer pages as verified, projected, pre-order, or cap-flagged.