When capital is ebbing and GPT-6 is advancing rapidly, who is paving the way for embodied intelligence?
On July 10, 2008, the first day the App Store went online, there were only 500 apps in the initial batch, which could be fully browsed in just a few pages. When Steve Jobs later reviewed this period, he described it as one of the largest-scale launches in his professional career.
This seemingly modest dataset opened up a brand new paradigm: ordinary people did not need to be affiliated with Apple's team, nor did they require official authorization, to develop applications for a general-purpose computing device that could be downloaded and used by users worldwide.
On that very day, independent studio Imangi submitted a small game that barely drew any attention. A decade later, this same team developed *Temple Run*, which has accumulated over 1 billion total downloads.
Eighteen years later, in the autumn of 2026, a similar "first day" is unfolding at the Shenzhen Bay Eco Park.
The 17 teams in the finals came from diverse backgrounds including universities, product development, and design, with some participants even having no prior experience in developing humanoid robots or full-featured apps. Over 36 hours, they transformed the trivial yet real pain points in daily life — such as unemptied cat litter when people travel, 3D printed workpieces waiting for material collection and restart, and parcels that need to be collected on behalf of residents — into executable tasks for embodied robots.
16 applications were finally successfully migrated to real devices on site, with a deployment success rate of 94%. The 47 apps produced across the three stops of the competition verified one fact: when the toolchain is sufficiently complete, non-professional developers can also build robot applications that run in the physical world.
These prototypes may still be immature, but they directly target the long-ignored application blind spots of embodied intelligence. While the industry's focus has been concentrated on individual indicators such as robot motion control accuracy, model capability, and body bionics level, a more fundamental proposition has rarely been questioned: who creates robot applications? Can ordinary users enter this field at low cost? After application development is completed, how can they be reused, disseminated, and form a sustainable business cycle?
The capital boom will eventually subside. When the financing narrative fades, what will allow embodied intelligence to cross the industry cycle? The breakthrough may not lie in more powerful models or more sophisticated robot bodies, but in the entry point for application creators — this hackathon is a pre-verification of this path.
If robots are just closed hardware with pre-installed fixed functions, and development permissions are firmly held by a small number of engineers and professional teams, the supply of applications is destined to be unable to match the massive and scattered real scenario demands.
The answer given by Astribot Intelligence is not to polish a single point of robot capability, but to build AOS (Astribot OS, Embodied Operating System), this intermediate underlying layer, which connects large models and embodied bodies downward, and faces developers and end users upward, enabling both users and AI to easily call robot capabilities.
In exchanges with Hard Krypton, Lai Jie, founder of Astribot Intelligence, repeatedly took Apple as a reference.
Apple solved two major problems: enabling more people to participate in development, and making it easier for more people to use products. It opened a window connecting creators and users: the graphical user interface simplified end-user operation, the operating system and development tools reduced creation costs, and the App Store carried application distribution, reuse, and commercial pricing. These four layers form a stable, self-circulating connected ecosystem.
This is exactly the blueprint Astribot has conceived for the embodied intelligence ecosystem. Relying on the full-stack architecture integrating cable-driven bodies, self-developed models and AOS, AOS is not a supporting software for a specific robot, but the entry point of the embodied application ecosystem. Users do not need to master professional principles, and can generate robot apps with just one sentence, converting demands in real scenarios into executable embodied tasks.
The hackathon provides a recordable starting point. The paradigm shift that once emerged in the Internet era is now repeating itself in the physical world.
01
General Models Cannot Bridge the Gap in the Physical World
Over the past two years, almost all resources and attention in the embodied intelligence track have been focused on two things: polishing robot bodies with stronger performance, and iterating embodied foundation models with better generalization capabilities. Dazzling technical demo showcases in the industry have kept emerging, but robot applications that can run stably and be reused frequently in real scenarios are still scarce.
The launch of GPT-6 Astra has further amplified route divergences. Two mainstream opposing views have gradually taken shape in the market: one side holds the optimistic narrative of "full cloud access", arguing that general large models are powerful enough to directly connect to robot bodies, and can handle all physical tasks relying solely on their generalization capabilities; the other side goes to the opposite extreme, claiming that cloud-based large models are helpless against the physical world, and all tasks must be solved in a closed loop by dedicated embodied models.
The former overestimates the transferability of cloud intelligence, while the latter underestimates the potential of the two types of models to cooperate. Seemingly opposite, both essentially fall into the misunderstanding of simple linear extrapolation of technical capabilities.
However, in Lai Jie's view, founder of Astribot Intelligence, the real answer does not lie at either end, but in building a collaborative paradigm that meets the requirement of "having both advantages": it should have the abstract understanding ability of general models, while allowing embodied models to take charge of physical space perception, force control, and trajectory execution, with a middle underlying layer completing two-way interaction between the two.
To understand why this paradigm works, we must first clarify the respective capability boundaries of the two types of models.
In 2024, Lai Jie conducted a simple internal test: placing three pens to form an arrow on the desktop, and instructing the robot to put an object at the position pointed to by the arrow. The general large model instantly understood this abstract instruction, but the embodied model tested by Astribot Intelligence at that time, relying only on existing training data, still found it difficult to understand symbolic references such as "arrow".
This test intuitively exposed the respective shortcomings of different models. The general model is essentially a "brain" that is good at high-level intention decomposition, but its capability is limited to the cloud, and it does not naturally master the underlying physical execution logic such as motors, transmission, and force control. The embodied model, when operating in the real world, is familiar with motion and contact in physical space, but lacks the ability to interpret abstract symbols and fuzzy intentions, which requires the general model to complete semantic understanding first.
This test made Lai Jie start thinking: can we make the two types of models complement and cooperate with each other from the very beginning of design, integrating the abstract understanding capability of general models and the perception and operation capabilities of embodied models for the real world, and apply both to robots.
A seemingly simple task involves multiple links behind it, including task planning, interface adaptation, motion control, and exception handling. People who understand software may not understand the logic of embodied motion control, and robot engineers are easily disconnected from real industrial demands; even professional teams cannot exhaust the massive long-tail scenarios in home and production environments in advance.
"The stronger the reasoning capability of large models becomes, the more an intermediate underlying layer is needed to undertake physical execution; the leap in model intelligence level cannot automatically bridge the gap between digital logic and the real physical world," said Lai Jie.
Lai Jie gave a daily life example: a mother teaches him to cook through a video call, and can clearly explain the whole process of adding oil, putting in vegetables, seasoning, and controlling the heat, which large models can also understand and repeat. But in the conversational context, "stretch your arm a little further" is an acceptable vague description, while details such as the holding angle of the spatula, the strength applied, and on-site fine-tuning cannot be accurately expressed in words, and can only be completed through real-time perception closed loop on site.
Astribot T1 is cooking in the kitchen
The underlying constraints of the physical world determine that cloud-based large models cannot handle everything. Lai Jie believes that general intelligence and embodied intelligence are not simply competitive or substitutive, but partners with clear division of labor: their values complement each other, each performs its own duties, and jointly complete the full link from intention understanding to physical implementation.
This also points to the current real gap: the industry needs a set of stable and reliable translation layer to convert the abstract intention output by large models into motion primitives that robots can stably reproduce. This is exactly the core problem that Astribot Intelligence's AOS aims to solve.
As an intermediate underlying layer that connects the preceding and the following, AOS needs to serve two types of objects at the same time: on the one hand, it provides ordinary users with an intuitive and easy-to-use interaction method, and on the other hand, it opens up parsable and callable underlying interfaces for AI.
"In the past, when we designed interfaces, we defaulted that the other party was a programmer. But now, the interface cannot only focus on whether programmers can understand it, but also consider whether GPT can understand it," said Lai Jie.
If AOS still follows the traditional idea, encapsulating the underlying control logic into complex code that only engineers can understand, even if GPT has strong reasoning capability, it will be difficult to cross the cognitive gap for precise scheduling. It is like a person with high intelligence but no sense of touch, who has ideas but cannot complete fine actions such as "pouring oil" or "unscrewing a bottle cap".
Therefore, AOS has implemented two layers of capability abstraction: downward, it connects the physical control link of the embodied model and the body, and encapsulates execution capabilities into callable skill packages; upward, it outputs standardized protocols, so that even creators without programming foundation can define tasks with natural language and generate robot apps with one sentence.
When this solution is implemented in the real physical environment, An Zhaohui, head of AOS R&D at Astribot Intelligence, summarizes it as "the journey ahead is long but the destination is within reach": there are still a large number of engineering problems to be solved to convert large model instructions into stable and reliable physical interaction, which will not be automatically solved as model capabilities improve; however, the capabilities of the upper-layer foundation models have crossed a key threshold, and with the continuous improvement of the AOS interface system, the window for embodied application implementation has opened.
When AI can smoothly call tools in the physical world, and the creation threshold is opened to ordinary users without being restricted by programming capabilities, embodied intelligence is expected to break out of the demo loop and generate a large number of applications rooted in real scenarios.
02
Trinity: Crossing the Boundary of Practical Implementation
At the scene of the Astribot Intelligence hackathon finals, the tense air is mixed with the sound of keyboard tapping and the occasional low voices of participants discussing. Here, the perfect logic derived from code deduction must always be verified by the constraints of the physical world.
In the GPT-6 era, the threshold for pure software applications has long been broken: a few prompt words can build a usable prototype. Robot apps are completely different: they are not oriented to rendered pixels on the screen, but to hardware execution in physical space. Control right game, real-time feedback, delay disturbance, force control closed loop and other constraints in real scenarios cannot be smoothed out by a single layer of API abstraction.
Under the traditional development mode, hardware, algorithm, and application teams advance separately: the hardware team is responsible for drivers, the algorithm team is responsible for control logic, and the application layer builds business processes. When entering the joint debugging stage, problems such as mismatched interfaces and timing conflicts are exposed intensively. The cycle from project initiation to real device verification for a function often takes several months, or even half a year.
This fragmented and time-consuming development link is exactly the pain point targeted by AOS — encapsulate complexity into AOS, and leave simplicity to creators. By pre-encapsulating drivers, models and interface scheduling, developers can skip underlying joint debugging and directly enter the application layer.
The "Remote Avatar" team that won the championship consists of three students who are still in the laboratory stage. They targeted the pain point that programmers who work overtime have no time to take care of their families and cannot help with household matters, and developed a mobile phone remote control robot app based on the AI Agent idea, making a simple "Robotic Harness".
They do not need to do any underlying development, and a strict underlying mechanism starts to operate: when the user issues the "water the flowers" instruction on the mobile phone, AOS has allocated the coordination and working sequence of Meta packages such as chassis (movement, navigation) and flower watering (operation); when the robotic arm stretches to the water cup, Meta packages such as vase recognition and grasping path planning are operating behind the scenes.
During actual grasping, embodied models such as Lumo are called to act as the "reflex arc" to process contact perception and force control closed loop, calculate the grasping force in milliseconds to adapt to the complex real environment; finally, the cable-driven body completes physical execution and returns real feedback. Even if the user continuously issues parallel tasks such as watering flowers, shoveling cat litter, and pouring water, AOS can independently complete underlying interface scheduling: delineate permission boundaries, verify control authorization, transfer task nodes, and capture operation exceptions, so that the whole process proceeds in an orderly manner.
Real device test environment of the "Remote Avatar" team
However, the transition from simulation to real device still taught the team that had little experience with physical robots a lesson. When they tried to make the robot perform the complex instruction of "walking forward while picking up the water cup", the hardware crashed on the spot. "Our app integrates a large number of atomic capabilities and calls the control right of the underlying joint chain. Once deployed on the real device, several underlying functional packages fight for the control right of the chassis and the robotic arm, causing serious arbitration conflicts," the team recalled after the competition.
This also reflects the value of integrated hardware and software polishing. The native AOS forms a full-stack closed loop with the Lumo model and the robot body, which can directly read native hardware data such as chassis inertia and joint limit, complete capability specification and permission arbitration at the underlying layer, and avoid resource contention between different actions from the root.
In the end, the three students with no prior humanoid robot development experience developed a highly difficult APP in 36 hours — the app is deployed on both mobile phones and robots, and the application calls the chassis (movement), visual recognition (perception), robotic arm (operation), embodied model and general large model. In the traditional robot development process, this requires seven or eight people to collaborate for two to three months.
The on-site mentor pointed out in the post-competition review, "Many developers thought that if the demo runs quickly in simulation, it can be delivered smoothly on real devices, ignoring the complexity of the physical world and the difficulty of robot app development. Only when the body, model and OS are designed collaboratively following the same set of interface specifications, can the intention output by large models be steadily converted into actual actions in the physical world."
The capabilities brought by this native full-stack design are not only reflected in the stable scheduling of a single model, but also leave space for the access of third-party embodied models. During the same competition, some teams used AOS's unified interface to verify the access of different VLA models.
The hardware body constitutes the real physical foundation of the whole system. The "Master of Calligraphy" team made the robot write brush calligraphy on rice paper, testing the stability and precise force control of the body, which intuitively reflects the differentiated advantages of Astribot Intelligence's cable-driven body.
Astribot T1 writing brush calligraphy on rice paper
At the same time, the deeper value of self-developed bodies is to natively open physical characteristics such as joint limit, inertia, and torque response to AOS, so that the scheduling logic comes with physical-level constraints, which also demonstrates the value of the collaboration among model, system and body.
At the hackathon site, many teams did not focus on complex mechanical motion control, but took lightweight scenarios as entry points to verify the potential of embodied intelligence entering the consumer market.
The runner-up project "Photography Master" is a representative example. The GowithFlow team, composed of two students from the Chinese University of Hong Kong