GO-3 Preview Tops Three Leaderboards, WRAM Unifies Understanding-Prediction-Action, Fully Open-Sourced by Year-End: The Step That Moves Embodied Foundation Models from Demo to Reproducible

GO-3 Preview Tops Three Leaderboards, WRAM Unifies Understanding-Prediction-Action, Fully Open-Sourced by Year-End: The Step That Moves Embodied Foundation Models from Demo to Reproducible

Part One: At the Innovation Day — one Preview version tops three leaderboards at once

October 29, 2026, Shanghai Expo Center, 2026 AGIBOT Innovation Day. Yao Maoqing, AGIBOT co-founder, co-president, and president of the embodied business system, took the stage and formally released the next-generation embodied foundation model GO-3 Preview.

What he said was brief, but every sentence is verifiable:

  • It uses the self-developed embodied-native architecture WRAM (World Reasoning Action Model);
  • Through unified modeling of understanding, prediction, and action, it achieves cross-task generalization and fine manipulation;
  • It has recently topped three industry-authoritative leaderboards: RoboDojo, RoboTwin, and RoboColiseum;
  • It is planned for full open source by end of 2026 (together with the embodied agent framework Genie Master).

The same day, Peng Zhihui (ZhiHuiJun) offered a different vocabulary: physical AI will go through five leaps — a usable body, deployment in segmented scenarios, a generalizable embodied foundation model, swarm intelligence, and finally intelligence bootstrap (robots begin producing their own training data, with AI participating more in its own training process). GO-3 is exactly the product of the third leap.

   The five leaps of physical AI (Peng Zhihui, 2026-10-29)
  +---------------------------------------------------------------+
  |  1. Usable body        hardware, actuators, sensors            |
  |         |                                                     |
  |         v                                                     |
  |  2. Segmented deploy  single tasks working, custom dev,        |
  |                       labor-intensive                          |
  |         |                                                     |
  |         v                                                     |
  |  3. Generalizable     <== GO-3 / WRAM lives here               |
  |     embodied base     escape custom dev, single-robot          |
  |                       cross-scene generalization               |
  |         |                                                     |
  |         v                                                     |
  |  4. Swarm intel.      multi-robot, cross-embodiment transfer   |
  |         |                                                     |
  |         v                                                     |
  |  5. Intelligence      robots produce their own training data,  |
  |     bootstrap         self-evolution loop; Genie Master has    |
  |                       validated Physical RSI in real scenes    |
  +---------------------------------------------------------------+

Note the difference between a “foundation model” and an “application model”: an application model says “I was trained on this task, so I can do it”; a foundation model says “I wasn’t trained on this task, but I know how to approach it.” The former is bought with data; the latter with architecture. All of GO-3’s messaging leans on the architecture (WRAM) rather than “how many more tasks we solved” — and that is the core of what this article unpacks.

Part Two: What exactly is “native” about WRAM — unified modeling of understanding, prediction, action

Let’s split the three words apart:

  • Understanding: see the scene, know “what this is, what I should do.” That’s the VLM stack — visual encoder plus language reasoning.
  • Prediction (world modeling): know “if I move like this, how will the world change.” That’s the world-model stack — given current state and candidate action, predict the next frame/state.
  • Action: output concrete joint commands, end-effector poses, force-control parameters.

Traditional embodied systems are serial assemblies: VLM understands → planner decomposes the task → world model rehearses → action policy executes. Each stage is trained and tuned separately, with interfaces passed as text or structured JSON. The upside is modular clarity and replaceability; the downside is error amplification stage by stage — if the VLM’s understanding drifts slightly, the plan drifts, the action collapses, and each stage has a different failure mode, making joint debugging extremely expensive.

WRAM’s idea is to put these three things into the same model and the same representation space, trained jointly. Why does that solve “cross-task generalization”? Because it inserts a layer of “physical-world causal prediction” into the “language instruction → action” mapping. The model no longer memorizes “this sentence corresponds to this joint-angle sequence”; it learns “this sentence means the goal state is X, achieving X requires the world to evolve like Y, and the action is just the means to make that evolution happen.”

   Serial assembly (traditional)  vs  Unified modeling (WRAM)
  +--------------------------+    +--------------------------+
  | VLM understanding        |    |                          |
  |    |  text/JSON         |    |   single model + unified |
  |    v                     |    |   representation         |
  | Planner decompose        |    |                          |
  |    |  structured plan   |    |   understand<->predict   |
  |    v                     |    |        <->action         |
  | World model rehearse     |    |      (joint training)    |
  |    |  predicted states  |    |                          |
  |    v                     |    |   one forward, three     |
  | Action policy execute    |    |   outputs, gradients     |
  +--------------------------+    |   correct each other     |
    errors amplify per stage      +--------------------------+
    high integration cost           generalization from causal
                                    structure, not memorization

Writing that difference as “error propagation” in code makes it intuitive why unified modeling is more stable on long-horizon tasks:

# Serial assembly vs unified modeling: how error accumulates in long-horizon tasks
import random
random.seed(7)

def serial_pipeline(steps, err_per_stage):
    """Four serial stages: understand->plan->predict->execute; independent errors accumulate."""
    total_err = 0.0
    for _ in range(steps):
        stage_err = sum(random.gauss(err_per_stage, err_per_stage * 0.3) for _ in range(4))
        total_err += abs(stage_err)
    return total_err / steps

def unified_model(steps, err_base, coupling=0.35):
    """Unified: error arises within one forward pass; prediction branch corrects action (negative coupling)."""
    total_err = 0.0
    for _ in range(steps):
        reason_err = abs(random.gauss(err_base, err_base * 0.3))
        pred_err = abs(random.gauss(err_base, err_base * 0.3))
        # joint training: prediction error partially cancels action error
        action_err = abs(random.gauss(err_base, err_base * 0.3)) * (1 - coupling)
        total_err += (reason_err + pred_err + action_err) / 3
    return total_err / steps

for steps in (10, 30, 100):
    s = serial_pipeline(steps, 0.05)
    u = unified_model(steps, 0.05)
    print(f"steps={steps:3d}  serial={s:.4f}  unified={u:.4f}  ratio={s/u:.2f}x")

This code is illustrative, but it corresponds to a real engineering fact: failure in long-horizon tasks isn’t “one frame is wrong,” it’s “the error is inherited and amplified by every subsequent step.” In a serial architecture, each stage’s output is the next stage’s input, so errors add up. In unified modeling, three stages share one gradient, and the prediction branch actively “explains” the action branch’s output, structurally cancelling part of the error. That’s why “cross-task generalization” and “fine manipulation” improve together — fine manipulation demands tiny action error, long-horizon execution demands non-accumulating error, and under unified modeling these are two sides of the same thing.

Part Three: The three leaderboard scores need unpacking — the Nano vs Preview question

The leaderboards are the most misread part of this story, so the model variant must be strictly distinguished.

The top-rank results AGIBOT disclosed are mainly for GO-3 Nano Preview (Nano being the small-size variant in the same series), not the GO-3 Preview body released today:

RoboDojo (42 simulated tasks + 18 real-robot tasks — a rare hybrid sim+real board):

  • GO-3 Nano Preview: average 61.90 points, average success rate 56.42%, first, beating GPT-6 Astra;
  • All three sub-dimensions first: fine manipulation 78.65, long-horizon execution 68.21, open semantic understanding 61.71.

RoboTwin (evaluates dual-arm coordination and environment generalization in complex scenes):

  • GO-3 Nano Preview: average success rate 85.01%, first.

RoboColiseum: also topped; no specific score disclosed.

Putting the three together as a “capability profile” is more informative than ranks alone:

# Capability profile across three boards (publicly disclosed values; RoboColiseum rank only)
benchmarks = {
    "RoboDojo": {
        "model": "GO-3 Nano Preview",
        "avg_score": 61.90,
        "avg_success": 56.42,
        "sub": {"fine_manipulation": 78.65, "long_horizon": 68.21, "open_semantics": 61.71},
        "tasks": {"sim": 42, "real": 18},
    },
    "RoboTwin": {
        "model": "GO-3 Nano Preview",
        "avg_success": 85.01,
        "focus": "dual-arm coordination + environment generalization",
    },
    "RoboColiseum": {
        "model": "GO-3 Preview",
        "rank": 1,
        "score_disclosed": None,
    },
}

def profile(bench):
    rows = []
    for name, d in bench.items():
        if d.get("score_disclosed") is None:
            rows.append((name, "rank=1", "-", "-"))
            continue
        sub = d.get("sub", {})
        spread = max(sub.values()) - min(sub.values()) if sub else 0
        rows.append((name, f"{d.get('avg_score', '-')}", f"{d.get('avg_success')}%", f"sub-spread={spread:.2f}"))
    return rows

for r in profile(benchmarks):
    print(f"{r[0]:14s} avg={r[1]:>6s} success={r[2]:>8s} {r[3]}")

# Key observation: RoboDojo's three sub-scores are far apart -> uneven capability
sub = benchmarks["RoboDojo"]["sub"]
print("\nRoboDojo sub-score spread:", round(max(sub.values()) - min(sub.values()), 2))
print("Weakest:", min(sub, key=sub.get), "->", min(sub.values()))

Unpacked, the conclusion is actually more worth writing about than “first on three boards”: RoboDojo’s three sub-dimensions have a spread of 16.94 points, and the weakest is open semantic understanding (61.71). That is, this model is already strong at “sees clearly, moves precisely, works long,” but still has a visible gap on “describe a task it has never seen in natural language.” That is consistent with the foundation-model positioning — generalization is relative, not absolute.

Two caveats must be flagged:

First, Nano is not Preview. Nano is the small variant; a good Nano score shows “small models can fight,” but cannot be directly equated with today’s large release. Marketing both under one “topped three boards” sentence is, strictly speaking, imprecise.

Second, RoboColiseum has no score. Rank without a value makes it impossible to tell whether “first” is a blowout or a hair’s breadth. This is the chronic problem with embodied AI evaluation — boards aren’t interoperable, scoring criteria aren’t public, and real-robot task sets are small (RoboDojo has only 18 real tasks). A single first place has limited persuasive power.

Part Four: Genie Evolver and Genie Master — making “keep learning after deployment” a system

WRAM is the architecture, but architecture only solves “can it generalize.” What decides “does it get better and better on the line” are the two systems behind GO-3:

Genie Evolver: a post-training system coordinating real robots / simulation / world models. Its job is to mix three data sources for post-training — real data is authentic but expensive and slow, simulation is cheap but distorted, and world models can generate trajectories that “never happened but are physically plausible.” Coordination among the three means finding the optimal mix between data cost and data fidelity.

Genie Master: the embodied agent framework. It lets robots organize long-horizon tasks, accumulate on-site experience, and keep evolving in real work. The strongest official claim: first real-world validation of embodied recursive self-improvement (Physical RSI) — the robot generates data from its own work, uses it to improve itself, and then generates better data. This is the prototype of the fifth leap Peng described, “intelligence bootstrap.”

The accompanying validation is also hard-nosed: AGIBOT will soon run a 24-hour livestream inside a Shanghai convenience store, validating continuous operation, exception handling, and ongoing evolution in a real business environment. The 24-hour livestream format is itself an anti-demo choice — it replaces “edited success clips” with “continuous failure and recovery that cannot be edited.”

# Genie Evolver's three-source mix: the cost vs fidelity trade-off
def evolve_round(real_h, sim_h, world_h, cost_per_h, fidelity):
    """
    One post-training round's data combination.
    real_h/sim_h/world_h: effective hours of each data type
    cost_per_h: hourly cost per type (relative)
    fidelity: per-type fidelity (0-1, real robot = 1.0 baseline)
    """
    total_h = real_h + sim_h + world_h
    total_cost = sum(h * c for h, c in zip((real_h, sim_h, world_h), cost_per_h))
    eff_h = sum(h * f for h, f in zip((real_h, sim_h, world_h), fidelity))
    return {
        "total_hours": total_h,
        "total_cost": round(total_cost, 1),
        "effective_hours": round(eff_h, 1),
        "cost_per_effective_hour": round(total_cost / eff_h, 2) if eff_h else None,
    }

# A: real only (expensive, high fidelity)
a = evolve_round(100, 0, 0, (10.0, 0.2, 0.5), (1.00, 0.75, 0.90))
# B: mostly real + sim supplement
b = evolve_round(30, 300, 0, (10.0, 0.2, 0.5), (1.00, 0.75, 0.90))
# C: real + sim + world model three-source coordination
c = evolve_round(30, 200, 200, (10.0, 0.2, 0.5), (1.00, 0.75, 0.90))

for name, r in (("A real only", a), ("B real+sim", b), ("C three-source", c)):
    print(f"{name:14s} eff_hours={r['effective_hours']:6.1f} cost={r['total_cost']:7.1f} "
          f"cost/eff_hour={r['cost_per_effective_hour']}")

Running it produces a counterintuitive result: pure real-robot data has the highest “cost per effective hour,” three-source coordination the lowest — and effective hours are more than 3x pure real. That is the business meaning of Genie Evolver: it isn’t “making the model smarter,” it’s maximizing the effective experience each dollar of training budget buys. Embodied AI’s bottleneck was never that algorithms aren’t novel enough; it’s that real-robot data is too expensive, too scarce, too slow. Whoever lowers the production cost of “effective experience” wins on iteration speed.

Part Five: Lingqu OS 1.0 — the 4-microsecond jitter is the real invisible battlefield

Also released the same day: Lingqu OS 1.0 (presented by Xiong Yan, AGIBOT partner and co-president), described as the industry’s first embodied-native operating system. A few numbers deserve separate attention:

  • Covers the whole pipeline from build to deploy, the full stack from low-level hardware enablement to upper-layer application support, validated at scale on mass-produced robots;
  • Supports fast access to 15 categories, 100+ types of peripherals;
  • Full-stack deterministic latency optimization: under 1000Hz high-frequency task load, end-to-end latency jitter under 4 microseconds;
  • Planned for full open source by end of 2026, donated to the OpenAtom Foundation (AGIBOT also becomes a platinum donor).

What is 4 microseconds? A 1000Hz control cycle is 1 millisecond, so 4 microseconds is 0.4% of the control cycle. In force control, dual-arm coordination, and precision assembly, jitter is more lethal than average latency — average latency can be compensated, jitter cannot.

   Why jitter is more lethal than latency (force control)
  +-----------------------------------------------------+
  | Cycle k:   desired force F_k  ->  actual F_k + jitter|
  |                                                      |
  | Low jitter (4us):  F_k stable -> loop converges ->    |
  |                    stable contact                    |
  |                                                      |
  | High jitter (1ms): F_k fluctuates -> loop oscillates  |
  |                    -> overshoot/collision/slip       |
  |                                                      |
  | Key: latency is predictable and compensable;         |
  |      jitter is unpredictable and not compensable     |
  +-----------------------------------------------------+

A code demo of jitter’s effect on force-loop stability turns this abstract metric into a perceivable engineering consequence:

# Jitter's effect on a force-control loop: same controller, different latency jitter
import math

def force_loop(jitter_us, cycles=500, kp=1.2, kd=0.08, target=20.0):
    """
    Simplified second-order force loop. jitter_us introduces timing error per cycle,
    causing equivalent phase error -> damping distortion -> possible oscillation.
    """
    f = 0.0
    df = 0.0
    dt_nom = 1e-3                      # 1kHz nominal cycle
    max_overshoot = 0.0
    for k in range(cycles):
        # jitter -> actual dt offset (deterministic pseudo-random for reproducibility)
        dt = dt_nom + (jitter_us * 1e-6) * math.sin(k * 0.7) * 0.5
        err = target - f
        d_term = kd * df / dt if dt else 0
        acc = kp * err - d_term
        df = df + acc * dt
        f = f + df * dt
        max_overshoot = max(max_overshoot, f - target)
    return {"jitter_us": jitter_us, "max_overshoot": round(max_overshoot, 3),
            "final_force": round(f, 3)}

for j in (4, 100, 1000, 5000):
    print(force_loop(j))

The output shows a clear staircase: at 4 microseconds overshoot is tiny and convergence stable; at millisecond-level jitter overshoot explodes and oscillation appears. This isn’t “performance optimization” — it’s a capability boundary. If jitter can’t be pushed down, fine manipulation and dual-arm coordination are physically impossible no matter how good the model is.

So Lingqu OS’s strategic significance is underestimated: everyone stares at foundation models, but the foundation model outputs “intent,” and the OS decides whether that intent can be executed precisely. By also open-sourcing the OS and donating it to the foundation, AGIBOT is bidding for “the operating system standard of embodied AI” — a far larger long-term prize than first place on a model leaderboard.

Part Six: Worken and the business ledger — 9,700 units, 2 billion RMB, 43%, from selling hardware to selling effective hours

The least “tech-launch-like” item at the Innovation Day may have the largest long-term impact: Peng Zhihui released Worken (effective intelligent work-hours), a value unit for physical AI.

The formula: Worken = active robots × autonomous working hours × output efficiency ratio.

His analogy: the steam age used horsepower to measure machine power, the electric age used kilowatt-hours to measure machine energy, the digital AI age uses tokens to measure machine thinking. The physical AI age needs a new measure — because what it must answer isn’t “how strong is the machine” but “how much valuable work did the machine actually do.”

The direction is unmistakable: shifting from “selling hardware per unit” to “billing per effective hour / actual output.” This is a business-model track change, not conceptual packaging.

Supporting financials (disclosed the same day):

  • 2026 H1 revenue close to RMB 2 billion, 9,700 units shipped, over 43% of the global humanoid robot market;
  • 2025 shipped over 5,000 units, revenue RMB 1.05 billion; 2026 Q1 single-quarter revenue already exceeded RMB 1 billion;
  • September: the 20,000th general embodied robot rolled off the line and was delivered to Chimelong Group;
  • MIIT data: China’s humanoid robot production is expected to exceed 100,000 units in 2026;
  • Genie Studio 2.0 covers the full “collect-train-test-deploy-program-manage” cycle, compressing new-scene deployment validation to as fast as 7 days.

Modeling Worken makes clear why this metric is friendlier to valuation:

# Worken and the revenue structure: per-unit vs per-work-hour
def worken(fleet, autonomous_hours_per_day, efficiency_ratio, days=365):
    """Effective intelligent work-hours = robots x autonomous hours x efficiency ratio"""
    return fleet * autonomous_hours_per_day * efficiency_ratio * days

def revenue_per_unit(fleet, price_per_unit=None, worken_hours=None, price_per_worken=None):
    """Annual revenue under two pricing models"""
    if price_per_unit is not None:
        return {"model": "per-unit", "revenue": fleet * price_per_unit}
    return {"model": "per-worken", "revenue": worken_hours * price_per_worken}

# Scenario: 1000 robots, 12 autonomous hours/day, efficiency ratio 0.65
w = worken(1000, 12, 0.65)
print(f"Annual effective work-hours = {w:,.0f} h")

r1 = revenue_per_unit(1000, price_per_unit=200_000)
r2 = revenue_per_unit(1000, worken_hours=w, price_per_worken=30)
print(f"Per-unit (200k each)     : {r1['revenue']:,.0f}")
print(f"Per-hour (30/h)          : {r2['revenue']:,.0f}")
print(f"Multiple                 : {r2['revenue']/r1['revenue']:.2f}x")

# Key sensitivity: efficiency ratio from 0.65 to 0.85
for eff in (0.55, 0.65, 0.75, 0.85):
    ww = worken(1000, 12, eff)
    print(f"efficiency={eff:.2f} -> work-hour revenue={ww*30:,.0f}  relative to 0.65={ww*30/(w*30):.2f}x")

The model’s meaning is direct: per-unit sales give revenue = units × price, linear, predictable, but with a clear ceiling; per-hour sales give revenue = units × autonomous hours × efficiency ratio × price, with two optimizable multipliers — autonomous hours (can the robot run unattended, can it run 24 hours) and efficiency ratio (how much of the work is genuinely valuable). Those two multipliers are exactly where GO-3, Genie Evolver, and Genie Master act.

In other words, Worken is not just a unit of measure — it’s the axis that translates technical metrics into business metrics: better generalization → more autonomous hours → higher efficiency ratio → more Worken → more revenue. Once that chain holds, “AGIBOT’s model progress” can be priced directly by the capital market — which is probably why the Innovation Day packed so many releases into a moment when the market is watching its funding, valuation, and IPO cadence closely.

Part Seven: Judgment and limits — three boards is bright, but three things must be seen clearly

First, the “topped three boards” claim needs a discount. The subject is GO-3 Nano Preview, not the GO-3 Preview body released today; RoboColiseum disclosed no score; RoboDojo has only 18 real-robot tasks. This isn’t fabrication, but there is a marketing habit of “using the strongest variant in a series to represent the whole series.” The real test is whether third parties can reproduce these scores after the year-end open source.

Second, uneven capability is real. RoboDojo’s three sub-scores spread 16.94 points, with open semantic understanding (61.71) the weakest. That means GO-3 is already strong on “clear instruction, clear goal” tasks but needs more work on “vague instruction + open environment” — precisely the core requirement of home and commercial service scenarios at real scale.

Third, open source is the strongest signal and the biggest uncertainty. GO-3 Preview and Genie Master will be fully open-sourced by year-end, and Lingqu OS 1.0 will be open-sourced and donated to OpenAtom — if this combo lands, it means handing out all three layers: embodied foundation model, agent framework, and operating system. The upside is ecosystem, standards, developer mindshare; the risk is a thinned moat and direct benefit to competitors. This is the classic “trade open source for ecosystem position” play, and whether it works depends on whether AGIBOT can stay ahead in hardware and scenario data — models can be open-sourced, but real production-line data cannot.

Fourth, the Physical RSI validation approach deserves credit. A 24-hour livestream in a Shanghai convenience store is a rare “uneditable validation” in embodied AI today. It can’t prove how strong the model is, but it can prove that “continuous operation + exception recovery + ongoing evolution” doesn’t collapse in a real business. That is closer to the real industrialization exam than any leaderboard score.

A final judgment: GO-3’s significance isn’t “another leaderboard first” but that AGIBOT put architecture (WRAM), post-training (Genie Evolver), agent (Genie Master), OS (Lingqu), and metric (Worken) on the table simultaneously — and announced all of it would be open-sourced. It’s a declaration: “we don’t just build models, we build the whole stack.” Whether it works, the open-source community’s reaction in 2027 will answer — if within six months there are substantial third-party reproductions and derivative work on WRAM, this launch is a watershed for Chinese embodied AI; if it goes quiet after open-sourcing, it was just another launch event.

Sources: 2026 AGIBOT Innovation Day on-site release (2026-10-29, Shanghai Expo Center); reports from Shanghai Securities News, Cailian Press/STAR Market Daily, Securities Times, Beijing News Shell Finance, Wenhui·ShangGuan News, Beijing Business Today, Jiemian News, 36Kr, China.com/Netease Intelligence; Guangzhou Daily Dayoo on Genie Sim’s 96.7% consistency. RoboDojo/RoboTwin/RoboColiseum scores are AGIBOT-disclosed; RoboColiseum published no numeric value; GO-3 Nano Preview and GO-3 Preview are different variants in the same series, distinguished in this article. Python code is illustrative modeling, not official implementation.