Put a satellite image into ABot-Earth 0.7 and, according to Amap, you get a kilometre-scale 3D city in about ten minutes on one consumer-grade GPU. Put an origin, a destination and a vehicle into Apollo World and, according to Baidu, you get a closed-loop robotaxi trip in which every cyclist and pedestrian is making its own decisions. Both companies call the result a world model. Both are talking about cities and roads. They are not answering the same question, and the difference is the most useful thing to understand before choosing either — or, more likely, before concluding that you cannot choose either.
The clean way to state it is this: Amap is rebuilding a city that exists, and Baidu is simulating a drive that has not happened yet. One is a reconstruction problem with a ground truth you can photograph. The other is a behavioural problem with no ground truth at all, only a distribution of outcomes you hope is realistic. Confusing the two leads teams to buy the wrong tool, or to expect a static scene generator to grade a planner.
Two world models, two definitions of "world"
ABot-Earth 0.7 was announced by Amap, Alibaba's mapping and navigation arm, on 10 September 2026, succeeding ABot-Earth 0.5 from June. It is a 3D-native urban world model: trained on spatiotemporal data, it generates 3D Gaussian Splatting scenes end to end from a georeferenced satellite image or a text prompt, and it claims continuity from planet scale down to street level and landmark close-ups across more than 196 countries and regions. Amap says the output is editable and compatible with Unreal Engine and Unity, which is the detail that makes it interesting to simulation teams: the generated city can be dropped into an existing engine rather than staying inside Amap's viewer.
Apollo World was disclosed by Baidu's Intelligent Driving Group on 3 November 2026 at Baidu AI Day · Apollo in Shenzhen. It generates camera and LiDAR observations together, models traffic participants as decision-making agents, and runs complete trips — pickup, drive, drop-off — between arbitrary points in a virtual city. Baidu says it is already used to validate Apollo Go, its robotaxi service, and claims a throughput of 100,000 simulated kilometres per day.
The difference in output format tells you almost everything. ABot-Earth emits geometry: a scene you can walk or fly through. Apollo World emits experience: a sequence of sensor observations and vehicle states, with behaviour attached. Geometry without agents is a beautiful place with nothing happening in it. Agents without geometry is a traffic model floating in space. Each is incomplete for the other's job.
The scoreboard
• What it outputs — Apollo World emits synchronised camera frames and LiDAR point clouds over time vs ABot-Earth 0.7 emits a static 3DGS scene you can navigate.
• Unit of work — Apollo World a complete trip from origin to destination vs ABot-Earth 0.7 one square kilometre of city.
• Traffic and behaviour — Apollo World models vehicles, cyclists and pedestrians as agents with their own policies vs ABot-Earth 0.7 generates no moving participants at all; behaviour would have to come from whatever engine you import the scene into.
• Input — Apollo World a trip request inside a generated city vs ABot-Earth 0.7 a satellite image or a text prompt.
• Headline performance — Apollo World 100,000 simulated km/day, vendor-reported vs ABot-Earth 0.7 about 10 minutes per km² on one consumer GPU, vendor-reported.
• Availability — Apollo World internal to Baidu, no API or pricing announced vs ABot-Earth 0.7 an invite-only experience site in Simplified Chinese, no weights, model card, API or pricing.
The input defines the failure mode
Because ABot-Earth starts from a satellite image, its errors are geographic. The model has to invent what it cannot see: façades, street-level signage, the underside of an awning, the material of a wall facing away from the camera. Amap claims photo-level detail at close range, and the demos support a strong visual impression, but generation is not capture. A building that does not exist can appear exactly where a real one should be, and nothing in the output marks that as a guess. For a navigation product that is a quality problem. For a safety case it is disqualifying, because a simulator that confidently invents a road layout is worse than one that admits it does not know.
Apollo World's errors are behavioural instead. Its geometry can be plausible and its traffic still wrong: an agent that yields when a real driver would proceed, a pedestrian who never jaywalks, a cyclist whose policy is too polite. Baidu's own 2+3 rubric acknowledges this. Causality and interactivity are the baseline tests, and physical accuracy, persistence and real-time performance are the advanced ones. What the rubric does not include is a calibration test against real traffic behaviour, which is the hardest property to get right and the easiest to miss when the demo is curated.
In other words, ABot-Earth can be wrong about where things are; Apollo World can be wrong about what people do. A team building a driving simulator needs both properties and will not get them from either vendor's current release.
What closed-loop simulation actually buys
The phrase "closed loop" is doing a lot of work in Baidu's pitch, and it is worth separating from the marketing. In a scenario library, the world stops when the script stops. In a closed loop, the world continues, and the ego vehicle's actions change what happens next. That property is what makes a simulator useful for testing a planner rather than only for generating training data.
ABot-Earth is not trying to do that. Its contribution is upstream: producing large, editable, engine-ready environments quickly and cheaply enough that a simulation team does not have to wait for survey data. Amap's efficiency claim — roughly 1,000 times faster than traditional photogrammetric reconstruction at about one-hundredth of the cost — is about the cost of having a place to simulate in, not the cost of simulating behaviour in it.
The honest way to combine them is a pipeline: generate the environment with something like ABot-Earth, then populate and drive it with a behaviour model. Neither vendor sells that pipeline as a product today, and neither has published the interfaces that would make the combination straightforward. Amap's Unreal and Unity compatibility is the closest thing to an integration story on the geometry side; Baidu has said nothing about exporting Apollo World scenarios.
Cost per kilometre, stated carefully
Baidu's 100,000 kilometres per day is a throughput claim, not a cost figure. It says nothing about how many GPU-hours produce those kilometres, what proportion are useful, or how much human review each generated trip needs before it counts as evidence. The comparison Baidu offers — one day of simulation equals about three years of testing by a car with a safety driver — is arithmetic on mileage, not on validated coverage.
Amap's numbers are similarly directional. Ten minutes per square kilometre on one consumer GPU is a striking figure, but Amap has not disclosed the GPU, the resolution, the number of inference passes, or what fraction of generated scenes pass a human quality check. The 1,000x and 1/100th-cost claims are comparisons against a baseline Amap chose.
Both sets of figures are worth using as order-of-magnitude indications of what the vendors think they have achieved. Neither is a procurement number.
Who should care, and who should wait
If you are building a robotaxi or ADAS stack and your bottleneck is scenario coverage, Apollo World is the more relevant system — but you cannot have it. It is internal to Baidu, and there is no API, price list or partner programme. The realistic move is to study the 2+3 rubric and apply it to whatever simulator you do have, because it is a better specification than most vendors publish.
If your bottleneck is environment authoring — you need cities to test in, quickly, without a survey flight — ABot-Earth 0.7 is the more relevant system, and it is also not generally available. The experience site is invite-only and Simplified Chinese, with no model card and no weights.
Neither model is in the OrcaRouter catalogue, and we do not host either one; there is no endpoint to route and no list price to pass through. What is routable through one key is the software layer that surrounds a simulator: vision-language models for captioning generated scenes and auto-labelling sensor data, reasoning models for scenario authoring and failure triage, and embedding models for deduplicating a scenario corpus. OrcaRouter exposes 200-plus hosted models at 0% markup on provider list price with automatic failover, which matters when an evaluation harness is comparing three captioners on the same clip and one of them rate-limits.
The verdict
Apollo World vs ABot-Earth 0.7 is not a close call, because it is not the same contest. One is a behaviour engine that needs a world; the other is a world builder that needs a behaviour engine. If a team could license both, the sensible architecture would put ABot-Earth's generated cities underneath Apollo World's agents — and the fact that no such combination exists commercially is a better description of the state of the art than either launch deck.
What the pair does show is that "world model" has become too broad a label to be useful in a procurement conversation. Ask what goes in, what comes out, and whether anyone outside the vendor has measured it. On the current evidence, the answer for both is: something impressive, and no.
