PAN 2 vs ABot-Earth 0.7: Two World Models, One Axis Apart

Both are called world models. Both came out in the last two months of 2026. Both will show you a place you have never been. And they are not substitutes for each other in any sense a buyer would care about, because PAN 2 predicts what happens next in a scene over the following twenty seconds, while ABot-Earth 0.7 generates a kilometre-scale city you can walk through for as long as you like. One is a model of consequences. The other is a model of places. If you are choosing between them for a project, the honest first step is to notice that the question "which is better" has no answer, and the useful question — which one does your pipeline actually need, and can you get it — does.

The second question is where the two diverge sharply, and it is not a matter of taste. PAN 2 ships as 86.17 gigabytes of Apache-2.0 weights with serving support merged into vLLM-Omni; you can download it this afternoon and run it on your own GPUs. ABot-Earth 0.7 is a production system inside Amap's consumer app, with no public API, no weights and a whitelist for its generation feature. One of these is an artefact you can hold. The other is a demonstration you can watch.

What each one emits, precisely

PAN 2 takes an observation — an optional first frame plus a text description — and a set of actions described in text, and returns an MP4. Internally it is a two-stage machine: a language model writes a structured, time-grounded world-state caption, a frozen text encoder maps it into conditioning features, and a 29B multi-modal diffusion transformer renders up to twenty seconds of 704×1248 video at 24 frames per second. The output is short, expensive and specific: it answers "what does this action do to this scene", and the answer is bounded at twenty seconds because each clip is simulated from at most one starting frame.

ABot-Earth 0.7 takes a georeferenced satellite image, or a text prompt, and returns a 3D Gaussian Splatting scene with hierarchical level-of-detail structures, exportable to Unreal Engine and Unity. Amap — Alibaba's mapping arm — unveiled it at its Street Stars gala in Hangzhou on 10 September 2026, presenting it as the first native 3D urban world model and claiming roughly ten minutes to generate a kilometre-scale environment on a single consumer GPU. The output is a place, not a moment: you explore it, you do not wait for it to resolve.

Put side by side, the shape of the mismatch is obvious.

• Output — PAN 2 returns a 20-second MP4 at 704×1248 and 24 fps; ABot-Earth 0.7 returns a 3DGS scene with LOD structures, exportable to Unreal and Unity.

• Input — PAN 2 takes a first frame plus a structured action caption; ABot-Earth 0.7 takes a satellite image or a text prompt.

• Time horizon — PAN 2 simulates forward seconds, and drifts across clips beyond that; ABot-Earth 0.7 is static in time, a snapshot of a place that does not evolve.

• Device — PAN 2's documented default serving configuration is eight H200s in BF16, with a four-B300 recipe for thirteen seconds in 119 seconds; ABot-Earth 0.7 is claimed at one consumer-grade GPU for a kilometre in ten minutes.

• Access — PAN 2 is Apache-2.0 on Hugging Face, ungated, with code on GitHub; ABot-Earth 0.7 has no weights, no public API and an invite-only generation feature.

• Independent evaluation — neither has any. Both sets of numbers come from the labs that built the models.

Time and space are not the same axis

The distinction underneath all of that is worth stating because it changes what each model is for. ABot-Earth extends a scene through space: from one satellite tile it synthesises the buildings, the streets and the interiors you would see if you flew there, and it keeps them consistent as you move from city overview to street level. Its claim is coverage and fidelity at scale.

PAN 2 extends a scene through time: from one frame and a described action it predicts the frames that follow, and the thing it is trying to get right is the causal chain — the splash changes when the object changes, because mass and surface area changed, and the model has learned that relationship rather than memorised a splash. IFM's framing is that a language model predicts the next word and PAN 2 predicts the next world, and the demo that travelled on 11 November 2026 makes it concrete: drop a strawberry into a bowl, then make it a rubber duck, then change the liquid, and the three simulations differ in ways that follow from physics.

An application that needs one rarely needs the other. A robotics team evaluating candidate grasps needs PAN 2's axis. A mapping product, a digital-twin deployment or a game studio building an environment needs ABot-Earth's. The overlap is a narrow band where someone wants to place a generated city into a simulation and then animate what happens inside it — and there, the two would compose rather than compete, if the second half were obtainable.

The comparison that actually bites: can you run it

On capability the two are incomparable and nobody has tried to compare them. On procurement they are day and night.

PAN 2's access story is unusually complete for a research release. Weights went up on 7 October 2026 with a model card, configs and a prompt-rewriter skill; the GitHub repository with inference and training scripts followed on 5 November; vLLM-Omni merged Day-0 text-to-video and image-to-video support on 10 November and a recipe page came the same evening, documenting the four-B300 configuration and the eight-H200 default. IFM posted its announcement on X at 17:00 UTC on 10 November — fifty-six minutes after the framework merge — reading "Introducing PAN 2: an open foundation world model for physical intelligence." No blog post, no paper link, no hosted endpoint, no price. But the thing itself is downloadable, and the licence permits commercial use.

ABot-Earth 0.7's access story is the opposite. The experience site is live, but generation is invite-only — the interface describes creation as in beta and offers a whitelist application. There is no published pricing, no rate card and no developer documentation describing how an external system would call it. The 0.5 release in June put a technical report on arXiv and a repository on GitHub, and that repository was a home for the report rather than an implementation; nothing announced with 0.7 suggests the weights have opened. The site is also Simplified Chinese throughout, with no locale switcher, so evaluating it in English means working from Amap's press materials.

For most teams that ends the comparison before capability is discussed. A model you cannot call is not a candidate; it is a benchmark for what the category will look like when it becomes addressable.

What Amap has that IFM does not, and why it does not transfer

The reason ABot-Earth 0.7 is worth taking seriously despite the access problem is that it is not a lab demo. It drives Flying Street View 2.0, the consumer feature that replaced fixed-route flythroughs with freely explorable 3D space, and Amap says more than 880 million people have used the Street Stars surface it sits in. Trials are live for selected venues in cities including Beijing and Hangzhou, with use cases the company names concretely: checking the sightline from a specific theatre seat, navigating a shopping-mall interior, judging terrain before a trip.

Behind that is a data position no model lab can copy quickly — Amap cites nearly a billion monthly active users, Beidou positioning peak daily calls approaching a trillion, and decades of accumulated spatiotemporal data covering road networks, points of interest and live traffic. The 3DGS architecture is published work. The corpus underneath it is not.

None of which helps an outside developer, and this is the part launch coverage tends to skate. Amap's headline figures — ten minutes per square kilometre, up to 1,000x faster than traditional reconstruction at about 1/100th the cost, 196-plus countries and regions, a 3DGS output ready for Unreal and Unity — are all vendor-reported, none independently reproduced, and delivered alongside a whitelist rather than an endpoint. The consumer rollout is itself a form of proof that the system runs at scale. It is not proof that you can run it.

Where each one earns its place in a build

Assume for a moment you can get both, since that is the situation the category is heading toward. The split is clean.

PAN 2 is a filter for candidate actions. Its design assumes an agent already in the loop: the conceptual reasoner is any instruction-following language model, and IFM ranked four of them by full-plan completion — Claude Opus 5.5, GPT-6 Astra at medium effort, Kimi K3, Qwen3.8-Flash — which tells you the intended shape is a reasoner proposing plans and a simulator rendering their consequences so the reasoner can pick one. The cost of that loop is the thing to plan around, not the video quality: fifty sampler steps with guidance on every step is a hundred forward passes through a 29B transformer per clip, and a five-candidate, ten-step plan is fifty clips.

That reasoner slot is the one piece of the stack that needs no GPU cluster, and all four of IFM's ranked models sit in the OrcaRouter catalogue. Driving the prompt-rewriter through one API key lets you swap planners per experiment instead of per contract, with automatic failover absorbing provider degradation and provider list pricing passed through at 0% markup, so a vendor price change is live on the endpoint the day it happens rather than after a procurement cycle. OrcaRouter does not host PAN 2 and cannot route it — the diffusion half stays on your hardware — but the half that decides what to simulate is ordinary metered text work, and it is where the run-to-run variance actually lives.

ABot-Earth is an environment factory. Its natural output is a place to put things in: a training ground for embodied agents, a digital twin, synthetic driving data, a stage for a simulation. If it ever ships an API, the workflow it enables is complementary to PAN 2's rather than redundant — generate the world once, then simulate actions inside it — and the export formats Amap already advertises are the join point.

What would change this page

For ABot-Earth 0.7, one thing above all: a published API with a price. That single step turns a whitelist into a candidate and makes the cost comparison against PAN 2's GPU bill meaningful. Behind it sit three smaller unknowns — whether a 0.7 technical report appears at all, since 0.5 had one within days; whether the weights open, which would make it a genuinely different proposition for the simulation teams Amap says it is courting; and whether anyone outside Amap reproduces the ten-minutes-per-square-kilometre claim on hardware they own.

For PAN 2, the missing piece is a failure study. Its model card admits that about two in three simulated plans contain at least one step that is not carried out, and that how faithfully it simulates plans which should fail is not yet measured. A simulator that cannot show you a bad outcome is half a filter. Independent evaluation of the capability numbers would help too; every figure in IFM's report comes from IFM's harness, with a thirteen-reviewer panel for the human study.

Which to pick

If you need a place — a city, a building interior, terrain, anything you would otherwise reconstruct with survey data — PAN 2 cannot help you and ABot-Earth 0.7 is the more impressive system, but you cannot have it yet, so the practical answer is to stay on your current reconstruction pipeline and watch for an API. If you need to know what an action does before you take it, ABot-Earth cannot help you at all — a static scene has no consequences in it — and PAN 2 is one of the few open-weight models that tries, with the weights, the code, the serving recipe and the failure rate all published.

The comparison people search for, as though these were rival products on a shelf, does not exist. What exists is a category — world models — splitting along an axis most coverage has not bothered to name. One side models where things are. The other models what happens next. In late 2026, only one of them comes with a download link.