SKY-001: plan the part tree, draw the build, and lead CAD by 0.6 points

On 19 October Sam Pasupalak posted "Introducing SKY-001, the first Engineering World Model." The post claims that on CAD and BIM tasks it beats GPT-6 Astra "and every frontier model we tested", at "51-125x faster" and "150-210x cheaper", with "Higher IOU than all frontier models." A second post, from @chetaslua, put the CAD row in one line: 1,000 parts, about 100 build steps each, Astra at 79.1% IoU, 199 s and $0.75 a part, SKY-001 at 79.7% IoU, 3.9 s and $0.005.

The company is Skyfall AI, founded by Maluuba co-founders Sam Pasupalak and Kaheer Suleman with Sumit Pasupalak; Microsoft acquired Maluuba and, in Skyfall's words, "turned it into its research lab in Canada." The thread says SKY-001 is 18 months of work.

I wanted to know two things. How does a model that is not a language model produce a CAD part? And do the numbers in the posts survive contact with the pages they came from?

SKY-001 is closed. There is no paper, no technical report, no model card and no weights. Access is a waitlist. What exists is the eight-post launch thread, a blog post ("Introducing SKY-001: The First World Model for Engineering", 19 October) and a launch page at skyfall.ai/sky-001. Both pages are single-page apps, so I read the JavaScript bundles behind them, where the chart data and the blog text live as plain strings. Every number below is reported by Skyfall unless I say otherwise. Measured here means I read it out of those files; reasoned means my own arithmetic on reported numbers. Nothing was run, because there is nothing to run.

The short version

• The mechanism is two stages of diffusion, not one long program: a tree of parts, then each part's build drawn as 3D states and the 2D sketches between them.
• The CAD lead is 0.6 IoU points (79.7 against 79.1). The speed and cost gaps against GPT-6 Astra are real ratios of the published numbers: 199 / 3.9 is 51x and 0.75 / 0.005 is 150x (reasoned).
• The blog and the launch page list different rivals for the same CAD benchmark (measured). The blog's chart has Gemini 4 at 76.9%. The launch page has no Gemini 4; it has Claude Opus 5.5 at 69.4% and Gemini 3.8 Flash at 54.7%.
• In BIM the lead over the next-best model is 1.3 points, not 3.0. The 3.0 is against Astra. Gemini 3.8 Flash scores 42.3% against SKY-001's 43.6%.
• I could not find the 125x or the 210x from the first post in the text or chart data of either page (measured). I did not transcribe the launch video.
• Today's output is a visual plan, not an editable CAD file. The blog's own roadmap says sketch rollouts "would become executable operations with an editable feature history." That is future tense.

Why a tree

Start with the problem as Skyfall frames it. An engine is hundreds of parts across several levels, many hidden inside others, each of which has to fit its neighbours. A language model asked to write one CAD program for the whole thing has to emit every part, and every operation that builds every part, in one long chain of tokens. Each decision depends on everything before it. An error at step 300 is still there at step 3,000.

Skyfall's answer is the one engineers already use: work level by level. Decide the assemblies, then the sub-assemblies, then the parts, then how to build each part. The blog states the payoff directly: "the number of sequential steps grows with the depth of the design rather than its size." Once a parent is fixed, its children do not depend on each other, so they can be built in parallel.

That claim is checkable with arithmetic, because the launch page publishes the size of four of its showcase trees. The Jaguar E-Type Roadster has 103 leaves, 139 nodes and a depth of 5. The jet engine has 70 leaves, 96 nodes, depth 5. The FANUC ArcMate 100iB welding robot has 35 leaves, 55 nodes, depth 4. The Minitractor 4x4 has 92 leaves, 130 nodes, depth 5. The CAD benchmark says a part takes about 100 drawing steps.

Count model calls on the critical path (reasoned). A flat chain for the Jaguar makes 36 split decisions and then builds 103 parts at 100 steps each: 10,336 calls in sequence. The tree makes 5 rounds of splitting, one per level, and then builds all 103 parts side by side: 105 calls in sequence. That is about 98x shorter. The jet engine comes out about 67x shorter, the ArcMate about 34x.

The ratio scales with the number of leaves, so a 51x speedup is plausible from structure alone. But the total work does not change: the tree still makes 10,336 calls, most of them at once. Hierarchy explains fast wall-clock time. It does not explain 150x cheaper. That has to come from each call being small, the second idea in the pipeline.

Stage one: the Hierarchical Composer

The blog's flowchart gives the composer three steps.

1. Generate the whole. From an image, text or a brief, a DiT produces "a rough idea of the design", a coarse 3D shape. It can make several candidates at once so a user can pick one.
2. Split. The shape is divided into components (CAD) or units (BIM), and each piece is split again, "repeat per part, in parallel". In CAD the splitter is a DiT. In BIM the flowchart says "rule": the split is not learned.
3. Refine each leaf. Once splitting stops, a DiT turns each rough piece into a precise part.

expand

The third step exists because of what the first produces. The rough shape is good enough to decide what the parts are, but its surfaces are coarse and everything hidden inside is missing. Split it, and a gear stack behind a timing cover comes out as an open shell. The refiner fills in the hidden geometry; the blog shows five parts of a "VMS-85 engine" before and after.

BIM runs the same steps on what an architect can write down: the storey's envelope with each wall's thickness, and a brief with the programme, the net area and each room's size and rough position, drawn as one box per room. The worked example is one storey about 29 metres across, split into three apartments around a shared corridor, stairs and lifts.

Stage two: the Construction World Model

The composer decides what a design is made of. The construction model decides how each leaf is built, one step at a time. It has two layers, and the CAD one is the more interesting.

In CAD, plan the 3D states first, then the sketches between them. A CAD part is a sequence of intermediate solids: a profile becomes an extrusion, a second sketch adds material, a cut makes a hole. Each intermediate solid is a subgoal. SKY-001 predicts that sequence of 3D states, and then, for each pair of consecutive states, draws the 2D sketch that turns one into the next. The blog's worked part is extruded from its base outline, given a second extrusion, then has three features cut into it: five construction steps.

That order is worth noticing (reasoned). In robotics language, predicting the next state is a forward model and inferring the action that connects two states is an inverse model. SKY-001 does both, in that order: imagine the states, then recover the operations. The sketches are the actions. That is the strongest case for calling it a "world model", and it is a narrower one than the launch page's "First Model that can Dream". It predicts how an object comes to exist. Nothing in the blog says it predicts how the object behaves under load, heat or motion.

In both CAD and BIM, draw each state twice. Every canvas, a CAD sketch or a BIM floor-plan state, is drawn by diffusion in two passes. A world model first rolls out the whole sequence coarsely in a compressed latent space. A refiner then redraws every state at full resolution.

The compression is a "Matryoshka-style autoencoder". Each state becomes a sequence of codes. During training, codes are dropped from the end of the sequence while the decoder is still asked for the same reconstruction, so the first codes are forced to carry the global layout and later ones only finer detail. The coarse rollout uses only the leading codes. Its reconstructions are rough, but it keeps the layout. The refiner restores "sharp lines, exact corners and small features."

expand

This is the second half of the cost story (reasoned). The blog puts it in one sentence: "the overall plan needs no fine detail, so it runs on compact latents, and a refiner adds the detail back afterwards." A long rollout is cheap when each step is a handful of codes. Expensive detail is paid once per state, at the end, and every state can be refined in parallel. Compare that with a language model writing a Blender or CadQuery script, where every coordinate of every operation is a run of tokens decoded one at a time.

expand

BIM uses the same 2D machinery without the 3D layer, because a floor plan is already 2D. The model learns a drawing order from plan histories: exterior walls, then the walls between apartments and the corridors, then each apartment room by room with doors, windows and fixtures. It decides for itself when a floor is finished. The blog says a whole floor rolls out "in about a second."

What it was trained on

The training data section is the most concrete part of the blog, and the part I would most like to see in a paper.

CAD. Skyfall started from "publicly available online datasets of real product assemblies" and does not name them. Those files have inconsistent assembly trees, overlapping faces, duplicated geometry and unnamed parts. Skyfall rebuilt each hierarchy "to follow standard engineering design practice" and made every node a training example for the composer. Some sources carry the 2D sketches and full construction history. Where they don't, "engineering tools and LLM-based workflows reverse-engineer construction trajectories from the finished parts and verify them before they are used for training." In all, the composer learns from more than 200,000 parts and the construction model from more than 600,000 construction examples.

The blog's density comparison is against PartVerse, a common part-decomposition dataset. Counted in parts per object, PartVerse has a median of 6 and a 99th percentile of 33. Skyfall's data has a median of 288 and a 99th percentile of 4,180. Its three side-by-side examples: a fat bike with 988 parts against a BMX with 8, a Ducati 900SS with 751 against a Harley with 34, and a quadruped robot with 542 against a mech robot with 85. Those are Skyfall's "fine-grained mesh components" against PartVerse's "coarse semantic parts", so the two count different units, which the blog says outright.

BIM. About 35,000 real and synthetic floor plans, some two million drawing states, each paired with a brief "written from the plan itself." Where a source did not record drawing order, Skyfall reconstructed one.

Two things are worth holding onto (reasoned). Part of the CAD construction ground truth was written by LLM-based workflows, then verified; the blog does not say what share. And the BIM drawing order that the model imitates is partly reconstructed, so "how an architect draws" is in places "how Skyfall decided an architect draws."

The benchmarks, checked against the pages

Skyfall reports two construction benchmarks, 1,000 cases each, scored by IoU, the overlap between the final shape and a reference. Higher is better. Each also reports time and dollar cost per case.

CAD

The CAD benchmark has 1,000 components sampled from complex objects: the Jaguar E-Type, the ArcMate robot arm, the Minitractor, a Bell 222 helicopter and a jet engine. Building one takes about 100 drawing steps, and the final 3D object is scored by IoU. The blog says it compares against "five frontier models."

The SKY-001 and Astra rows match the posts exactly. The ratios are honest: 199 / 3.9 is 51.0, and 0.75 / 0.005 is 150 (reasoned). The blog's prose rounds the first to "about a 50x speedup." The accuracy claim is "matching its performance", and that wording is the right one. A 0.6-point gap on a mean IoU, with no spread and no per-object breakdown, is a tie until shown otherwise.

The comparator list is where the two pages part (measured). The blog chart is SKY-001, Astra, Gemini 4, Qwen 3.8 Max, Kimi K3 and Grok 4.7. The launch page's data rows replace Gemini 4 with two different models, Claude Opus 5.5 and Gemini 3.8 Flash. Gemini 4 at 76.9% is the closest rival after Astra on either page, and it appears only on the blog. I can't tell from the pages which list is the one that was run, or whether both are, on different subsets.

Grok 4.7 "completed none", so its IoU is blank, but both pages still chart its time and cost: 1,250 s and $0.59 per case for no output. That is a fair way to show a failure. It also means the time column is not "time to a correct part".

BIM

The BIM benchmark has 1,000 floor plans: about 350 whole floors from IFC building models and 650 apartments. Each takes from about 20 to more than 200 drawing steps, around 70 on average, and the final plan is scored by IoU.

The pages agree on the IoUs. The launch page also lists Opus 5.5 at 34.4%, which the blog chart leaves out, and stores Astra's time as 144.4 s in its data rows while its labels and the blog say 144.6 s (measured).

The headline ratio comes in three versions. The launch page says 118x faster and 188x cheaper. The blog chart says 119x and 186x. The blog's prose says "about 120 times faster and about 185 times cheaper." All three are roundings of the same rows: 144.6 / 1.22 is 118.5, 0.446 / 0.0024 is 185.8, and 0.4465 / 0.00237 is 188.4 (reasoned). None of them is 125 or 210, the top of the ranges in the first post. Against slower models the ratios get bigger, so a range could be built that way, but the post says "beats GPT-6 Astra" and I found nothing on either page that produces those two numbers.

The BIM accuracy story needs one more sentence than the blog gives it. SKY-001 leads Astra by 3.0 points, and the blog says so. It leads Gemini 3.8 Flash by 1.3. And 43.6% is a low absolute IoU. Every model in the table, SKY-001 included, misses more than half of the reference plan by that measure.

Two frames, not two benchmarks

The launch page's comparison videos show one case each, and their clocks are not the benchmark means.

expand

expand

The composer, judged by LLMs

The composer has no IoU. Skyfall had two LLM judges, GPT-6.1 Sol and Claude Opus 5.5, score SKY-001 and GPT-6 Astra blind from the same renders, on a 1 to 10 scale.

Astra "returned a model for 82% of assets." The blog does not say how many assets there were, whether Astra's failures count in its means, or what the rubric said. Each frontier model wrote "a Blender script for the whole assembly in one request": one-shot code generation against a multi-stage pipeline. That is Skyfall's point, but it is not a test of an LLM with a planning harness around it.

expand

What is not disclosed

For a launch that says "we want to share every single detail", the gaps are large. None of these appear on the blog, the launch page or the thread.

• Model size. No parameter count for any of the DiTs, the autoencoder or the refiners. No config, no safetensors to read.
• Hardware and the cost basis. $0.005 per CAD case and $0.0024 per BIM case are stated without a GPU, a price per hour or a batch size. The frontier models' costs are presumably API list prices; SKY-001's is an internal number with no method.
• How the LLM baselines were run. For the construction benchmarks: no prompt, input format, output format, number of attempts, tool access or how a generated program became a shape to score.
• What SKY-001's scored output is. The CAD benchmark scores "the final 3D object." The blog does not say whether that object comes from the predicted 3D states, from replaying the predicted sketches through a CAD kernel, or from somewhere else. Its own caption on the worked part warns that "the saved sketch and 3D geometry can disagree."
• The benchmark data. Which 1,000 components, whether any of their source assemblies overlap the training corpus, and any spread or confidence interval.
• Licence and terms. There is nothing to licence yet; I've marked it proprietary.

The executable-output question deserves its own line. Under @chetaslua's post someone asked "can the build plan open in regular CAD tools?" and the @skyfallai account answered "yes! we believe a world model for engineered objects should output something you can actually build, not just something you can look at." The blog's "What Comes Next" section says something more careful: "sketch rollouts would become executable operations with an editable feature history," and BIM floor plans "would become walls, doors, windows and rooms in a building model that architects can keep editing." Read together, the plan today is a sequence of pictures of states and sketches. The editable file is the next step. The LLM baselines, for all their failures, emit programs that run.

Where this sits

3DCodeVerse is the opposite bet: millions of executable 3D programs and a plan, build, measure, fix harness around a coding model. SpatialLM writes a room back out as Python, one line per wall. usd-brep is the kind of B-rep kernel an "editable feature history" would eventually have to land in. OpenTakeoff is a reminder that construction drawings matter once a person can check them line by line.

SKY-001's idea is that the plan should be visual and hierarchical, and the program should come last. The tree makes the critical path depend on depth rather than part count; compact latents with a separate refiner keep each step light. Those are where a 51x and a 150x can come from, and the pipeline is described more specifically than most closed launches manage.

What the launch does not yet support is the word "beats." On CAD it ties GPT-6 Astra on accuracy, and the closest rival on the blog's own chart, Gemini 4, is missing from the launch page. On BIM it leads the next model by 1.3 points at 43.6%. On cost the method is unstated. The output a user would actually need, a part they can open and edit, is on the roadmap. I would read the technical report the moment it exists. Until then, SKY-001 is a strong architecture sketch with a fast demo, and a benchmark that needs its harness published before the ratios mean what the posts say they mean.