GPT-7 May Break Through the Embodied Intelligence Problem—What Is the Value of Robot Companies' In-House Development?

By | Zhixun Think Tank, Author | Chen Youwen

If the "ChatGPT moment of embodied intelligence" is ultimately still opened by ChatGPT itself—then, in the face of continuously evolving external models, what should robotics companies still develop in-house?

Signals are appearing thick and fast.

Company self-testing, simulation validation, and real-machine evaluation—each of the three lines of evidence has its limitations, yet they point in a highly consistent direction: general-purpose large models are crossing the traditional boundaries of specialized policies and directly taking on more motion decision-making and execution-correction work.

The rapid forward shift in industry expectations is itself more telling than the technology. At the World Robot Conference two months ago, Wang Xingxing's stated timeline for the "ChatGPT moment of embodied intelligence" was still "two to three years at the fastest, five to ten years at the slowest" [6]; by October, he had already put forward a more aggressive judgment: next year, GPT-7 might "directly break through the embodied intelligence problem" [2]; and most recently he proposed that physical AI has shown early signs of a breakthrough, with the industry inflection point most likely falling within the next one to three years [5].

The optimistic boundary has narrowed from "two to three years at the fastest" to "one to two years at the fastest." Such a rapid revision of a forecast for such a critical industry inflection point looks more like a passive correction forced by the iteration of external models.

Behind this is an inherently unequal R&D race: to plug into external models, a company need only complete scenario adaptation to share in R&D results amortized across the entire industry, with capabilities upgrading in sync with the upstream; to build core models in-house, a company must shoulder alone all the fixed investment in data, compute, and team, and spread the cost through its own product shipments and deployment scale.

The commoditization of intelligence capabilities is already becoming a reality. For example, on October 13, Physical Intelligence opened applications for its API beta: after integrating, companies can upload their own scenario data, call on cloud compute to complete model fine-tuning, and directly drive their own robots through hosted inference [7].

The robot's intelligent "brain" is likewise accelerating its shift from a company-exclusive, heavy-asset in-house investment into a standardized technical service that can be purchased on demand and paid for by usage.

Build in-house or buy externally—this has been a century-old question for manufacturing: whether carmakers make engines themselves or buy them, whether phone makers develop chips in-house or license them, it is essentially the same question. What changes is never the question, but the conditions for answering it: how far the boundary of externally purchasable capability has been pushed, and how low the cost has fallen at the same delivery standard.

Ultimately, all disagreements converge on the same question: when capabilities are increasingly easy to buy from the market, what exactly must a company hold on to in order to avoid duplicating investment in what the market already offers, and to create long-term value beyond external procurement?

The answer is clear: in-house R&D will not die out, but it is turning from a premium identity label sought after by the capital markets back into a pragmatic business choice that requires a clear calculation of inputs and outputs.

How much can general-purpose models already do?

First, the conclusion: general-purpose large models can already independently handle part of the work of understanding, planning, and motion decision-making, and their capability boundary is still advancing rapidly; at the same time, current tests still expose obvious shortcomings in execution reliability, task duration, and invocation cost.

The first to corroborate this trend was simulation testing. RoboDojo set up 42 dual-arm tasks covering multiple dimensions such as generalization, fine manipulation, long-horizon tasks, and memory. Its September evaluation results showed that GPT-6 Astra achieved an average success rate of 22.48%, surpassing all 40 public specialized policies used as comparisons in the paper—the best of those specialized policies reached only 19.34%. Although it still lags in the three dimensions of fine manipulation, long-horizon tasks, and memory, it nonetheless took first place overall on the strength of its advantages in generalization and open tasks. The leaderboard was not refreshed until October 8—when the specialized model VPP2 posted an average success rate of 32.26%, overtaking it [8][9][10]. Looked at another way, general-purpose models and specialized policies have begun to take turns leading on the same exam paper, rapidly raising the common benchmark.

Beyond that, the hybrid collaboration route has also produced quantifiable gains. Galaxy General selected 10 tasks and a total of 50 test instances for validation: Astra's success rate under independent control was 26%; while the hybrid control scheme of Astra and π0.5 reached a success rate of 48%—most of the execution steps were generated by π0.5, with the remainder generated or corrected by Astra [3].

Of course, like other laboratory technologies, the real test for general-purpose large models only begins when moving from simulation to real machines, and the shortcomings are exposed more clearly, with the most prominent gap being execution tempo. On October 14, Artificial Analysis had five frontier models drive a real robotic arm through a coding agent, attempting eight tabletop tasks.

Image source: Artificial Analysis, Welcome to the era of embodied AI: Introducing AA-Robotics v0.1, October 14, 2026.

Astra still took first place overall, but led the runner-up by only 4.8 points, while its average invocation cost per attempt was more than 8 times that of the latter; the four models took about half an hour on average per task attempt—a human needs only 20 seconds to complete the same work; converted against the U.S. average hourly wage using model invocation fees, even the lowest-cost model still cost about ten times that of human labor. Even such a basic execution capability as "judging when a task is complete" is still being refined—the Sol model once built a qualifying block tower at around the 17th minute, yet continued to execute operations and ultimately failed the task [4].

Caption: In AA-Robotics v0.1, Astra ranks first with a composite score of 69.4 and an average invocation cost of $16.36 per attempt; Sol scores 64.6 at $1.93. Scores include partial-completion credit, and costs are measured by model invocation fees.

Image source: Artificial Analysis, Welcome to the era of embodied AI: Introducing AA-Robotics v0.1, October 14, 2026.

But note that the general-purpose models above were not purpose-built for robots, nor were they fine-tuned for the evaluation tasks in these tests.

Crucially, Galbot's hybrid control scheme has also validated that, at the current stage, the division of labor in which a specialized policy does the main execution while a general-purpose model participates in correction can work together to raise success rates on selected tasks.

General-purpose models breaking into embodied intelligence have gone from a concept to an experimental scheme that can run on real machines.

The industry's main thread going forward will undoubtedly center on two things: first, how fast the capability boundary can be pushed; second, how fast usage costs can come down.

And for every company pursuing in-house development, as general-purpose model solutions mature, the more links the supplier takes on, the more concrete the value proposition of in-house development becomes:

Which capability gap does this investment fill? How much task performance does it improve? How much does it raise the efficiency of adaptation, delivery, and iteration?

With external models available, where else should in-house investment go?

Beyond general-purpose large models such as ChatGPT and Claude, there is another category of embodied foundation models built specifically for robots—such as Physical Intelligence's π series and NVIDIA's Isaac GR00T—designed from the ground up in training around robot perception and interaction, motion control, and scenario tasks.

The two model types come from different origins, but their significance for robot makers is the same—both are turning what companies originally had to do themselves into something they can buy. That being so, with solving problems as the fundamental goal, the more important question before "should we build in-house?" is to clarify: how far has external capability come? How much would it cost to reach delivery standards ourselves? And which remaining R&D is still worth investing in?

Below, these two types of external supply are grouped together as "external models." To settle this account, we first need to break open the big word "in-house development."

A robot is not a monolithic block but an assembly of hundreds or thousands of specific capabilities—seeing, grasping, planning, error correction. Generally, if an off-the-shelf external model suffices, buy it directly and concentrate manpower on product integration; if it falls a bit short, decide who fills that gap—the supplier, a joint effort, or the company itself. The same robot can absolutely make different choices for different capabilities, combining into three divisions of labor.

How do the three divisions compare? They can be split along two of the most practical angles: first, who bears responsibility for development and subsequent maintenance; second, after completion, what truly remains in the company's hands and can be reused.

But regardless of the division, all must pass the same baseline: is it reliable enough, does the cycle time keep up, is it safe, and is the total cost worthwhile? These four are the shared delivery baseline. The metrics in the table are used to further clarify, above that baseline, what each division does extra—when comparing on that basis, tasks, loads, and acceptance criteria must be consistent, otherwise it is comparing apples to oranges. As for whether programs, data, and models can be used continuously, reused across projects, or even taken away when switching suppliers, that of course must be written clearly in licenses and cooperation terms first.

What does this division look like? Take MicroFactory's workflow: the user only needs to describe the task and teach the robot a few key points, and the general-purpose model automatically writes the code for visual recognition and robotic arm control, which then directs the robot to work. The model itself is off-the-shelf; what the company does is connect it to a specific task, get it running, and validate it [11].

So where does the company's own effort go? Into "using it fast and using it steadily"—making task programming, on-site integration, and changeovers and line switches all save time. Models can be bought, but how to connect them each time, how long the connection takes, and what needs maintenance during operation—these accumulated task programs, tool interfaces, and delivery methods are what suppliers cannot take away. Ultimately it must land on a few visible results: for the same task, can it be delivered faster, run more steadily, and be replicated to the next site with less effort?

When off-the-shelf models fall short and the company does not want to do everything itself, there is the second option: turn on-site data and experience into model improvements. This is how PI and laundry robot company Weave cooperated—PI provides the foundation model and training capability, and Weave provides the scenarios and data that understand laundry best. The effect can be measured in numbers: after feeding Weave's data into pretraining, the number of times humans had to intervene per batch of laundry was directly halved [12].

In this division, the company gains a new kind of work: continuously collecting data, analyzing where errors occur, articulating task requirements clearly, and evaluating together with the model provider whether improvements are good. Through one cycle, on-site experience enters training through cooperation, the model gets stronger, and new capabilities return to the company's own products—data here is not one-off material but a bargaining chip that can be exchanged for capability.

Whether this investment is worth it mainly depends on three points: how much manual intervention is reduced, how much faster similar problems are solved, and how much each iteration round costs. Only by putting performance improvement alongside the cost incurred can one see more clearly whether trading data for cooperation really pays off.

Of course, cooperation can also move earlier, to the product definition stage. Galbot and Unitree have just disclosed that the Galaxy Star Galbot ET1 was jointly developed by both parties, with collaboration covering product definition, hardware refinement, and embodied intelligence capability development[13]—models and hardware inherently need to work closely together, and R&D can absolutely be organized across enterprises. What companies still need to test is whether this kind of cooperation can reduce duplicate development and repeated adaptation, enabling products to meet delivery requirements faster.

The third type is the heaviest: developing the model yourself, training it yourself, and continuously updating it yourself. But doing it yourself does not mean starting from zero—you can start from a ready-made external base and only do adaptation training on top of it; or you can go all the way up, building your own core model and training system, and keep the model, data, and training capabilities continuously in your own hands. Which layer to invest in depends on what the task requires and what you already have.

Figure takes the most thorough path of building its own core model and training system. The reason it does so is that externally purchased data can hardly simultaneously satisfy the three requirements of being collected in sufficient quantity, covering sufficiently diverse scenarios, and being of sufficiently high quality. So it built its own data system called Index, and then used it to pretrain its own model Helix 2.5[14].

Was this money well spent? Figure made a very clear comparison: the model architecture, downstream training data, and evaluation conditions were all the same, with the only difference being whether or not the model had undergone Index pretraining. The result was a stark gap—across 30 previously unseen homes, the success rate on long-horizon tasks jumped from 9% to 56%[15]. This step amounts to clearly measuring exactly how much Index contributed.

Caption: Figure disclosed that, in a comparison with identical model architecture, downstream training, and evaluation conditions, Index pretraining raised the task success rate in 30 unseen homes from 9% to 56%. Artificial Analysis, Welcome to the era of embodied AI: Introducing AA-Robotics v0.1, October 14, 2026.

Image source: Figure, Helix 2.5: Zero-Shot 30-Home Generalization, September 17, 2026.

Having chosen this path, a company must carry the whole load of data, training, evaluation, and deployment on its own year after year, and must periodically compare itself with external solutions: results, full cost, and the scope that can be reused. The most critical is this "reuse account"—how many tasks and how many product lines the same set of internal capabilities can serve, how much adaptation it can save later, and ultimately how much revenue it brings.

There is another point that is easily overlooked: the three divisions of labor are not opposed to one another; even if you develop in-house, you can still let general models lend a hand. In a reproduction workflow publicly released by Poke & Wiggle, an AI agent can complete the entire process on its own—reading papers, reproducing algorithms, training baseline models, and applying for real-machine testing—with humans only responsible for checking the methods, preparing workstations, and providing on-site support[16]. This reminds us that external models, on the one hand, make more capabilities directly purchasable, and on the other hand, also make in-house development faster and cheaper. Therefore, the costs on both the in-house and purchased sides must be continuously re-estimated.

Finally, there are the things that, if thought through in advance, cause less trouble later: the permissions for cooperation and use must be written clearly. Which programs, data, model configurations, and evaluation materials can be used continuously and reused across projects, who will re-validate after version upgrades, and if a supplier must be changed or a migration is needed, how much effort re-acceptance will take—all these must be recorded in advance. Because sooner or later they will become real adaptation, maintenance, and switching costs.

At this point, what each division of labor must do and how long it must bear responsibility are already clear. The next step is to translate this work into money—which are one-time shared investments, which are expenditures incurred at every site, and then put the costs and returns of the entire cycle together for comparison.

In-house investment: first calculate full-cycle cost, then measure business returns

Before comparing costs, first align the premises: the same tasks are being performed, the same load is being borne, and the same number of years of service is being provided. More importantly, both routes must first achieve reliability, meet takt time, and pass safety requirements—before these are met, it makes no sense to ask which is cheaper or more expensive, because delivery is simply impossible.

The simplest way to calculate is to divide expenditure into two parts:

Regardless of whether you choose direct external procurement, commissioned cooperation, in-house development, or a mix of several, you book the accounts with this same pen[17][18].

Below, a set of hypothetical numbers is used to calculate "in-house development" and "direct external procurement" together (disclaimer: the following numbers are used only for concise illustration and do not represent any real quotation or any company's actual costs).

Assume the same batch of similar sites goes live at the same time, and compare their total expenditure over three years: the in-house solution has a shared investment of 20 million yuan, but each site costs only 80,000 yuan over three years; the external procurement solution requires a shared investment of only 2 million yuan, but each site costs 200,000 yuan over three years. (Here unit prices are first fixed and the time value of money is not counted; in reality, if sites go live in batches, accounting must be based on the actual go-live time of each site.)

The account is clear: choosing in-house development means paying 18 million yuan more upfront (20 million minus 2 million); but the benefit is that each site saves 120,000 yuan (200,000 minus 80,000). So the question becomes a very simple payback question—how many sites must be rolled out before the savings can fill back the extra 18 million yuan paid upfront?

The answer is 150 sites. By the 150th site, the two routes cost exactly the same; beyond that number, the more sites you roll out, the more cost-effective in-house development becomes—the extra money spent upfront has been filled in by the 120,000 yuan saved at one site after another, and everything after that is pure savings.

This is the most basic economy of scale achieved through "R&D reuse," and it is also the real foundation of in-house development: that shared investment of 20 million yuan is fixed, and spreading it across 10 sites versus 1,000 sites means each site carries a completely different burden; the more sites there are, the thinner the R&D cost allocated to each site, the more the savings accumulate, and ultimately the extra upfront investment is completely covered.

But this 150 is not set in stone; it moves with conditions. Keeping the other numbers unchanged, we change only one variable—the full cost per site of the external procurement solution—and see what happens:

So, when the external procurement cost drops from 200,000 to 100,000, which looks like only a halving, the payback threshold rises all the way from 150 to 900, a fivefold increase. The key lies entirely in the denominator of that formula—the amount each site can save shrinks from 120,000 to 20,000, to one-sixth of the original, so payback naturally becomes much harder—this also shows that the cheaper external models are, the more in-house development must rely on scale.

One easily confused point also needs special clarification here: what changes above is the full expenditure per site, not just the model invocation fee. The invocation fee is only one item. For example, of the 200,000, 120,000 is the invocation fee for the model, and the other 80,000 is other overhead such as adaptation, labor, and maintenance. Even if the invocation fee is halved, the savings are only 60,000, and the full cost per site goes from 200,000 to 140,000—corresponding to the earlier account, the payback point is 300. Looking only at invocation fee cuts easily overestimates the pressure on in-house development.

In direction, falling external procurement prices will compress the cost advantage of in-house development; conversely, if in-house maintenance costs keep rising, they will produce the same effect. Moreover, the closer to the payback point and the closer the per-site costs of the two routes are, the more sensitive this number becomes—a tiny error in the original estimate could shift the payback point substantially.

So enterprises must watch three things closely, and answer with actual data rather than initial estimates: first, whether the shared investment has exceeded budget; second, how much each site actually saves; third, how many more times this system can be effectively reused before the next round of technology replacement arrives.

However, 150 is only the cost line for "not losing money." To judge whether this R&D actually makes money, revenue must also be brought in. If in-house development brings better performance, can it sell at a higher price and bring more paid deployments and renewals? This must be tested by revenue. At the same time, less manual intervention, maintenance, and compensation are real expenditure savings.

Adding the two ends together—whether the new revenue plus the saved expenditure can cover the new investment—is the true business return of this R&D.

After this round of analysis, the judgment standard can actually be simplified to one sentence: can the extra money earned plus the money saved cover the extra money invested? If yes, this in-house development is worth it; if not, it should be reconsidered.

Of course, in reality there are still several detail accounts that must not be omitted: the cost of R&D delays, year-after-year maintenance, and future supplier-switching migration and exit costs all must be included, and revenues and expenditures must be compared according to when they actually occur. As for combinations of several solutions, they should also be put into the same account to see under what tasks and what scale they are more cost-effective.

It must be emphasized that the numbers in this section initially all come from budgets, quotations, and pilot estimates—they are "calculated"; once actual delivery begins, they must be replaced with one real record after another.

This requires us to use actual evidence to test the original estimates step by step.

Testing R&D returns in stages

The previous section calculated "expected" returns using assumptions and estimates; what this section must do is use real evidence to go back and test whether these estimates are reliable: how much the shared investment actually cost, how much each site actually spent, how many times the thing was actually reused, and how much revenue customers actually brought in.

The testing is not done only at the end, but progressively along four steps: in the R&D stage, verify the "capability increment"—whether in-house development actually brought better capabilities; in the pilot stage, calibrate the "site cost"—how much it actually costs to land one site; in the replication stage, verify the "reuse efficiency"—whether moving to a new site actually saves effort; in the operations stage, test "return realization"—whether revenue and profit actually land.

At each step up, the return calculation must be redone with newly obtained evidence, and then it is decided whether to continue investing the next sum—this is what conforms to the most basic business logic.

First, the key point in the R&D stage: the comparison must be chosen correctly. The external solution used for comparison cannot be an imagined "perfect and free" solution, but must be one that can actually be bought, has legal usage rights, and has already completed the necessary adaptation. What enterprises should compare are several solutions that can all truly carry the target task, and the adaptation fee and operating fee of each solution must be recorded clearly item by item—only then is the "in-house increment" obtained from the comparison valid.

At the replication stage, beware that every site is different. New projects are often more complex, and the work hours required for adaptation may increase rather than decrease. The correct approach is to group projects with similar tasks and loads and check them one by one: how much work that would otherwise have to be done from scratch did the existing models, data, programs, and tools actually remove for the new site? Reuse efficiency is hidden in this work that is not done.

This brings us back to the real-world test of the payback logic in item 03: for example, if you originally expected to roll out 300 sites in three years, but only 50 actually pay for production, then how to recover the upfront investment has to be recalculated. The reverse also holds—even if the number is small, as long as the return from a single project is high enough, it can still support a not-insignificant amount of R&D. So neither scale nor return can remain merely on paper; both must be tested against real data.

There is another thing: it is not enough to spell it out clearly in the contract; you have to actually try it for real—through a version upgrade, a supplier switch, or a dedicated migration test, to see whether the promised results can actually be retained, how long the downtime will be during the process, and how many people and how much money it will take to restore it to an acceptable state. What can be smoothly taken away is what truly belongs to the enterprise as an asset.

The acceptance result at each gate directly determines where to go next: if the solution's advantages can recur across different sites and the expected return is positive, then confidently proceed to the next stage; if the advantage only shines on a few tasks, then narrow the R&D scope and stop rolling it out across the board; if an external solution can already meet the same delivery standard and is still more cost-effective after switching costs are included, then decisively adjust the division of labor—buy what should be bought, and reserve strength for the places that truly build barriers.

Using this method to look back at Unitree, the effectiveness of its 2.022 billion yuan model R&D plan can also be tested along the same chain[1]:

Its model UnifoLM—version updates and public evaluations can be used to track technical progress; once it enters specific tasks, it should be compared with external solutions that can be purchased in terms of performance, adaptation, and operating cost[19]. And the "can be equipped with the Isaac GR00T model" officially disclosed for H2 Plus happens to provide an entry point for observing the combined "in-house + purchased" solution—the in-house body connected to the external model as the "brain"; how it actually performs will have to wait for subsequent data to tell[20][21].

Stringing the pieces of evidence together, the picture becomes complete: the progress of fundraising and construction records how the money is being spent; comparisons across tasks test whether there is any capability increment; delivery and payment records test whether operating returns are realized—how much new adaptation for similar projects is reduced, how manual intervention and maintenance change during operation, and whether customers are willing to keep paying. Linked together, these make it clear what the 2.022 billion yuan actually created.

In the end, there is no forever-correct in-house R&D route, only a continuously updated value yardstick—if an enterprise maintains unified task and acceptance standards and dynamically calibrates the performance, cost, and retainable value of each solution, the priority of R&D investment will naturally become clear.

References:

[1] Unitree Robotics Co., Ltd. Prospectus for Initial Public Offering and Listing on the STAR Market (Official Version)[R/OL]. (2026-08-14)[2026-10-22].

[2] Song Weiping. Wang Xingxing: Next Year GPT-7 May "Directly Break Through the Embodied Intelligence Problem"[N/OL]. Shanghai Securities News, (2026-10-12)[2026-10-22].

[3] Galaxy General Team. Systematically Exploring the Capabilities of GPT-6 Astra as Embodied Policies[EB/OL]. (2026-09-29)[2026-10-22].

[4] ARTIFICIAL ANALYSIS. AA-Robotics v0.1[EB/OL]. (2026-10-14)[2026-10-22].

[5] Qin Sheng. Wang Xingxing: Physical AI Has Shown Signs of Being Broken Through, Competition Will Be Extremely Fierce, and Joint Efforts Are Needed[N/OL]. The Paper, (2026-10-22)[2026-10-23].

[6] Hu Yifan. Wang Xingxing: When Will the "ChatGPT Moment" of Embodied Intelligence Arrive? Two to Three Years at the Fastest, Five to Ten Years at the Slowest[N/OL]. The Paper, (2026-08-20)[2026-10-22].

[7] PHYSICAL INTELLIGENCE. Announcing our API beta[EB/OL]. (2026-10-13)[2026-10-22].

[8] CHEN T, et al. RoboDojo: A Unified Sim-and-Real Benchmark for Comprehensive Evaluation of Generalist Robot Manipulation Policies[EB/OL]. (2026-07-05)[2026-10-22].

[9] ZHANG W, et al. An Unexpected Robot Policy: Early Evaluations of GPT-6 Astra on RoboDojo and Beyond[EB/OL]. (2026-09-21)[2026-10-22].

[10] ROBOTERAX. Video Prediction Policy 2: Predict Better, Act Better[EB/OL]. (2026-10-07)[2026-10-22].

[11] MICROFACTORY. Official Website[EB/OL]. [2026-10-22]. https://microfactory.com/; related disclosures also see: Chen Youwen. General Large Models Are Redoing Robot R&D and Delivery[EB/OL]. TMTPost, (2026-10-17)[2026-10-22].

[12] PHYSICAL INTELLIGENCE. The Physical Intelligence Layer[EB/OL]. (2026-02-24)[2026-10-22].

[13] STAR Market Daily. Galaxy General and Unitree Announce Joint Development of the World's First Native Agent Robot[N/OL]. (2026-10-23)[2026-10-23].

[14] FIGURE. Introducing Index[EB/OL]. (2026-08-25)[2026-10-22].

[15] FIGURE. Helix 2.5: Zero-Shot 30-Home Generalization[EB/OL]. (2026-09-17)[2026-10-22].

[16] POKE & WIGGLE. Chapter 2: Towards an agent-native CERN of AI robotics[EB/OL]. (2026-10-14)[2026-10-22].

[17] ACCA. Cost-volume-profit analysis[EB/OL]. [2026-10-22].

[18] KNEIFEL J, WEBB D. Life Cycle Costing Manual for the Federal Energy Management Program: NIST Handbook 135e2025[R/OL]. Gaithersburg: National Institute of Standards and Technology, 2025[2026-10-22].

[19] UNITREE ROBOTICS. UnifoLM-WLA-1.0 README[EB/OL]. (2026-09-28)[2026-10-22].

[20] UNITREE ROBOTICS. Unitree H2 Plus Official Product Page[EB/OL]. [2026-10-22].

[21] NVIDIA. Isaac GR00T: General Robot 00 Technology[EB/OL]. [2026-10-22].