OpenAI’s newly leased Richmond warehouse has more than 14,000 amps of electrical capacity, a specification that matters less as real estate trivia than as evidence of a robotics strategy built around sustained data production.
Physical AI’s bottleneck is becoming ownership of the system that produces demonstrations, not merely ownership of a robot body or a frontier model. The relevant asset is a closed operational loop: collect physical behavior under controlled conditions, turn it into usable training data, train policies quickly, deploy them with low latency, observe failure, and repeat. The company that owns that loop can improve its robots on its own timetable. The company that depends on a customer site, a hardware partner, or a scarce annotation vendor inherits someone else’s cadence.
OpenAI now has 27 open robotics roles, more than double the 11 listed four months earlier, and the roles span actuator design, gear design, motor engineering, manufacturing, firmware, PCB design, inference, and robot-learning data pipelines. Taken separately, those postings could look like an ordinary expansion of a research group. Taken together, they describe the minimum viable organization for making robots into instruments of data collection.
A robotics technical product manager posting describes OpenAI as a growing hardware company building supply-chain capabilities for precision machining, mechanical parts, electronics assembly, and contract manufacturing. That language is consequential because it places the company beyond the position of model supplier. A lab that can specify the hardware, validate prototypes, and work toward manufacturing readiness can shape the sensors, controls, reliability profile, and operator ergonomics of the machines that generate its next training set.
That is the core mechanism. Hardware is not just the endpoint on which a policy runs. In an embodied-learning system, hardware determines what can be observed, how safely a task can be repeated, where demonstrations fail, and how much useful variation can be captured per hour. A data factory for robots is therefore part lab, part fleet operation, part manufacturing program, and part training cluster.
OpenAI’s San Francisco teleoperation lab has used GELLO controllers on Franka arms since February 2025 and has expanded from roughly 100 contract workers at launch to more than 400. Teleoperation is expensive precisely because it substitutes deliberate human action for the accidental abundance that made internet-scale language training possible. But it gives a developer something generic web video does not: action trajectories tied to a particular robot, task setup, sensor suite, and control regime.
GELLO was designed to lower the barrier to collecting large, high-quality human demonstrations through a general teleoperation framework, as its project documentation explains. That is an important distinction from a generic interface demo. The objective is not simply to make a robot move under human guidance; it is to standardize collection sufficiently that each session becomes training material rather than an isolated performance.
The operational value compounds. A controlled collection environment lets a team vary objects, lighting, grasps, camera angles, failure cases, and operator approaches while retaining metadata about what changed. That turns an error from a one-off disappointment into a target for the next round of demonstrations. A system built this way can create a feedback loop in which every policy shortcoming identifies the next data-collection job.
OpenAI is also hiring a machine-learning engineer for robot-learning data pipelines at a listed base salary range topping out near $380,000–$500,000. This may be the most revealing role in the current buildout. Teleoperation labor without a strong pipeline produces a pile of footage; a pipeline turns that footage into versioned, filtered, searchable, reproducible training material that can support model iteration.
The cost center is broader than operators. Demonstrations need capture infrastructure, data quality controls, storage, processing, task design, safety oversight, replay tools, and enough engineering discipline to preserve the relationship between physical conditions and model outcomes. In practice, the durable advantage may come from knowing which examples are worth collecting next, rather than from owning the largest archive of past examples.
A separate OpenAI inference-engineer role lists compensation up to $380,000 and focuses on real-time policy deployment, while Rust and C++ robotics roles list $255,000–$325,000. Those postings point to the other half of the loop: the training data is only strategic if the resulting policy can act fast enough and reliably enough to return to the physical world for another cycle of evaluation.
Training and inference are often discussed as separate technical domains. In robotics, they are commercially inseparable. Slow or brittle runtime behavior means more intervention, more narrowly scoped tasks, and less trustworthy feedback from deployment. A model that improves in an offline benchmark but cannot execute within the timing limits of a real machine does not reduce the cost of learning; it pushes the cost downstream into supervision and integration.
The Richmond site’s power capacity is described as comparable to a small data center and intended to run GPU clusters that convert teleoperation footage into trained robot policies. This is why the facility is a harder signal than a recruiting count. Salaried researchers can be reassigned; a power-dense site and a collection operation imply a commitment to repeated physical-model cycles.
Reporting on the Richmond industrial lease independently supports the premise that OpenAI is expanding its physical Bay Area footprint as it pushes further into robotics. The strategic question is not whether the facility alone proves a finished robot program. It does not. The question is whether the company is allocating capital to the machinery required to make proprietary embodied data at scale. The available evidence says yes.
OpenAI paused robotics research in October 2020 because of a shortage of real-world interaction data, then restarted an internal robotics team in 2024 after backing Figure AI and 1X through the OpenAI Startup Fund. The earlier pause matters because it frames the new work as an answer to a known constraint rather than a generic return to hardware enthusiasm.
OpenAI is now trying to control the elements that were previously external: the physical apparatus, the operators, the data pipeline, the compute environment, and the runtime stack. That integration is not necessarily a declaration that it will sell a branded humanoid. It is, however, a declaration that access to external robot partners may no longer be sufficient for the company’s learning objectives.
This is the governed-deployment posture Moveworks took before its ServiceNow acquisition, translated into a physical domain: control the operating environment tightly enough that the system’s improvement cycle becomes dependable. In robotics, the analogy is more literal. The operating environment includes motors, cameras, operators, objects, electrical capacity, and the physical safety limits of each experiment.
OpenAI’s actuator, motor, gear, and manufacturing postings run from component design through prototype validation and mass-production readiness. The ability to redesign an actuator or revise a mechanical assembly can improve more than a bill of materials. It can make a robot easier to teleoperate, safer to recover after a failed interaction, more repeatable across a fleet, or better instrumented for gathering action data.
That is why hardware should not be treated as a commodity layer in every physical-AI investment thesis. A commodity component may be adequate for shipping an early system, but it can be a strategic liability if it constrains the data loop. The relevant question is whether the robot is optimized merely to perform a demonstration or to generate thousands of useful demonstrations under controlled, repeatable conditions.
Skild’s new claim attacks the same constraint from the opposite direction. Instead of building a larger data-production machine, it argues that a robot can extract more value from a radically smaller amount of evidence. If that holds in real deployments, learning efficiency becomes a substitute for at least part of the collection operation.
Skild AI introduced a learning approach that it says lets robots acquire new tasks after observing one demonstration video rather than requiring large teleoperation or simulation datasets. The appeal is immediate: if a single example can reliably convey a new task, the marginal cost of expanding a robot’s repertoire could fall sharply.
Skild’s S1 description says its system translates an in-context video demonstration into robot actions and reports a 66% success rate in context, rising to 86% with a further method described by the company. These numbers should be read as evidence of a technical direction, not as proof that the economics of robot onboarding have already changed across uncontrolled customer environments.
The distinction is essential. A single-video system still needs to generalize across object variation, scene changes, robot embodiments, execution timing, and the messy edge cases that real work creates. It must also make failures legible enough that an operator or customer can determine whether to provide another example, modify the task, or abandon the attempt. Data efficiency is powerful only when it survives those transitions.
Skild says its approach directly targets the data and training bottlenecks that have historically slowed robot skill acquisition. That positioning is credible as a statement of the problem, but the commercial test is stricter: can the system reduce the quantity of demonstrations required without merely moving cost into engineering support, constrained task design, or selective evaluation conditions?
Skild disclosed a $100 million annualized revenue run rate about two weeks before the single-video announcement. Revenue does not validate a broad one-video claim, but it does make the claim more consequential because customers may soon judge the alleged data advantage through procurement budgets and deployment timelines rather than laboratory narratives alone.
[L2] Per the AI Market Watch index, Skild AI is tracked with roughly $1.83B–$2B+ in total funding across all rounds, within an index covering about 5,000 companies rather than a market census. That capital base gives Skild room to pursue the efficiency path, but it also raises the bar for proving that software can compress the collection burden enough to create a durable economic advantage.
The OpenAI and Skild approaches are not opposites in the simplistic sense. A company can build a sophisticated data factory and pursue better sample efficiency at the same time. Indeed, the best data factory may be one that collects only the examples an efficient learner needs next. The competitive divide is likely to emerge between organizations that treat data collection as a measurable production function and those that describe it as a future operational detail.
OpenAI has not disclosed a robot form factor or manufacturing plan, and Caitlin Kalinowski, who led the hardware and robotics organization, resigned in March without a named successor. This is the clearest near-term counter-signal: the evidence supports a serious infrastructure commitment, but not yet a settled product strategy or an intact public leadership structure for delivering one.
A second failure mode is more structural. A large collection operation can become an expensive treadmill if the resulting policies do not generalize beyond the lab’s chosen tasks and environments. More demonstrations are not automatically better demonstrations. They can reinforce narrow behaviors, conceal evaluation gaps, and make a system appear capable only where the data-production process has already optimized the world around it.
OpenAI’s first robotics effort was shut down because the company lacked sufficient real-world data, according to co-founder Wojciech Zaremba. The relevant lesson is not that data collection guarantees success. It is that a frontier model organization has already encountered the absence of an internet-scale embodied corpus and is now spending against that constraint with a more integrated architecture.
For investors, this changes the diligence checklist. The model architecture still matters. The robot’s mechanical design still matters. Manufacturing cost, reliability, safety, and customer workflow still matter. But none of these can be assessed independently of the data operation. A credible physical-AI company should be able to explain who produces demonstrations, how tasks are selected, how failures are routed back into collection, what fraction of the process is instrumented, and how quickly a new observation changes the deployed policy.
OpenAI’s postings include manufacturing engineering and supply-chain work alongside teleoperation, data-pipeline, and real-time inference roles. That combination is the practical signature to watch. It suggests that the company sees robot learning as an industrial system, not a sequence of isolated model releases.
The pressure this creates for robot makers is cumulative. A competitor with proprietary demonstrations can improve task coverage with each deployment. A competitor with sharply better learning efficiency can achieve similar progress with fewer examples. A company with neither must buy access to data, wait for customers to tolerate experimentation, or accept a slower iteration cycle. Those disadvantages can compound before they show up cleanly in a benchmark.
The immediate conclusion is not that every robotics startup must vertically integrate. It is that every credible strategy needs an answer to the same question: where will the next thousand high-value demonstrations come from, and how efficiently will the system learn from them? OpenAI is answering by building the machinery. Skild is answering by trying to need less of its output. The investment moat will be determined by which answer works outside the demo.
