Simon Willison's Blender viewer turns a .blend file into a link

Simon Willison has put a browser viewer for Blender files into his tools collection, so a .blend sitting on a web server is now something you open in a tab instead of downloading and installing Blender to look at. That sounds small. The file it was built for is what makes it interesting.

He asked ChatGPT Images 2.5 for a Fabergé egg themed after the TV show Pluribus, pasted the picture it produced into Codex running GPT-6 Astra at its high setting, and gave it this:

Use your blender local skill to create a blender model of this faverge egg

The run took 17 minutes and 51 seconds and produced several .blend files. The viewer, which he already had from an earlier experiment, turned one of them into a link. Image model for the idea, agent with local tooling for the geometry, URL for the review, and no point in the chain where a human opened a 3D program.

Blender's save format was never built to be read

.blend is Blender's own save format, and it was not designed to be read by anything else. Blender writes its in-memory data structures to disk close to verbatim, plus a block near the start recording the layout of those structures: field types, byte offsets, record sizes. A reader has to reconstruct those C structs from the description before it can interpret a single vertex. That is why there is no published spec to build a third-party parser against, why the tools that do read it are chasing a moving target, and why opening a file from a much older Blender sometimes triggers a conversion pass rather than a straight load.

glTF is the opposite by design: JSON describing the scene, binary buffers for geometry, a spec maintained by Khronos, and a loader in every browser 3D library worth using. three.js ships one because glTF was built to be loaded by something that is not Blender.

The point of the viewer is that none of that table is your problem. If the URL renders, the format question is over.

Two ways to get geometry out of a picture

Feeding an image into a 3D pipeline usually means reconstruction. Photogrammetry, or a learned model estimating depth and surface, produces a dense triangle soup with no named parts. It looks like the object and is miserable to edit, because there is no lid to select, only 400,000 triangles where a lid would be.

What the Codex run appears to be doing is the other thing: authoring a scene. An egg is a profile revolved around an axis, a cage of bars is a repeated pattern cut with a boolean, and every piece stays a separate named object with a modifier stack. Lower fidelity, far more useful, and small enough to send over a link. It is also why a local skill is in the prompt at all. Blender's Python API is the handle for making the program build geometry instead of a person, and a skill is packaged instructions that let an agent drive it. The post links the skill file but does not show what is inside, so how much of the result is Blender doing the work and how much is the model is not something I can tell you from here.

Eighteen minutes is the number that matters

Seventeen minutes and fifty-one seconds is not a model answering a question. It is a loop: write a script, run it, read the traceback, fix an offset, run it again. 3D is unusually unforgiving inside that loop because there is no partial credit. A scene either opens or it does not, and an egg with the cage bars floating two centimetres off the shell is a failure you can see immediately.

The useful property is that the check is free. Blender validates its own files, so an agent that can run the tool and inspect the output has ground truth. That is the difference between generating a 3D asset and generating plausible-looking code that claims to produce one.

What this changes if you build things

The generated artifact is normally the last thing anyone thinks about. You get a model that writes geometry, and then the files land somewhere only you can open, and the review step becomes a download and an install for whoever you send them to. Two things here are worth copying:

• A URL is a review surface. Design feedback on a mesh in a browser tab is old news, but a viewer you point at a file your agent just wrote, living in your own tools rather than uploaded to an asset service, removes the upload step from the loop entirely.
• Treat these runs as batch jobs. Nearly eighteen minutes of tool calls producing several files is not a chat turn. The output needs a place to go before the run starts, not after it finishes.

What this is not: a Blender feature. There is no version number, no release, no support matrix. It is one person's tool, built for one file, and its scope beyond that is unstated.

What the post does not settle

The post shows one model in one browser. It does not say whether the viewer parses .blend directly in the browser or whether a conversion happens before the page loads, whether it handles arbitrary .blend files or only ones prepared for it, or how materials and textures survive the trip. Those are different claims. A viewer that genuinely reads .blend client-side is a different piece of engineering from one that renders a glTF exported alongside it, and only the first makes the format stop mattering for everyone else.

If it turns out to be the second, the tool is still useful and the headline is wrong. The durable part would then be the pipeline, which is the more portable lesson anyway.

Blender's save format will keep being a binary blob that only Blender fully understands. Watch for the viewer being pointed at a .blend its author did not make. That is the test, and it costs a URL to run.