Simon Willison’s Browser .blend Viewer
This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.
Simon Willison’s .blend URL Viewer is a small tool note about opening Blender files from a URL in the browser, written around an AI-generated Fabergé egg experiment. What happens after the agent makes something that is not just source code? The useful artifact was not only the generated 3D model, but the review surface Willison put beside it.
.blend URL Viewer is a browser-based way to inspect a Blender .blend file from a URL without making every reviewer open Blender first. Blender, the Blender Foundation’s open-source 3D creation suite is powerful, but it is not a lightweight handoff format. Willison’s post is interesting because it turns a playful image-to-model chain into a clearer pattern for coding agents: generate the thing, then make the thing easier to inspect.
Follow the artifact chain
Willison starts with a cultural object, not a benchmark. He says he asked ChatGPT Images 2.5, OpenAI’s image tool as described in the post, to generate a Fabergé egg themed after the TV show Pluribus. Then he pasted that image into Codex running GPT-6 Astra as named in the post, and asked it to use a local Blender skill to create a model.
That detail matters. The agent did not just answer with advice about 3D modeling. It used a local capability, worked for 17 minutes and 51 seconds according to the post, and produced several .blend files.
Don't treat this as only a novelty demo. The more useful reading is that coding agents are starting to produce artifacts that need their own inspection path: CAD files, migration plans, diagrams, test fixtures, generated datasets, security reports, and UI mockups. A pull request is not always enough.
Notice the skill-shaped boundary
The quiet star of the post is the local Blender skill. Willison links to the skill file he used, and that is the part Claude Code users should recognize. Claude Code also rewards small, named capabilities that explain what the agent may do, what files it should create, and how a human will inspect the result.
A skill boundary is not magic. It is a compact instruction surface that tells the agent how to operate a tool without rediscovering the workflow every time. In this case, the useful boundary is local Blender automation: create geometry, save .blend output, render or export something reviewable, and avoid pretending the first model is final art.
Don't write a skill as if it were a wish. Use concrete verbs and outputs. Bad: make a beautiful model. Better: create a .blend file, add named objects, save renders to artifacts/renders, and write a short notes file listing what was approximated.
This is also where small repository memory helps. A concise CLAUDE.md can say where generated assets live and what counts as done, while the skill carries the reusable Blender procedure. Keep the durable rule in memory; keep the tool recipe in the skill.
Put the viewer at the handoff point
Willison already had what he calls a vibe-coded Blender viewing experiment, then added it to his tools collection so readers could inspect the Pluribus model in a browser. That move is easy to miss. The viewer changes the handoff from please download my asset and open a specialist app to click this and look.
For developers, that is the pattern worth stealing. When an agent produces something outside normal code review, pair it with the smallest credible viewer. A generated database migration gets a dry-run diff. A generated API client gets a tiny smoke app. A generated 3D file gets a browser viewer.
Don't confuse preview with validation. A browser .blend viewer can make review easier, but it does not prove topology quality, material correctness, licensing safety, or production readiness. It gives humans a faster first look, not a stamp of approval.
This connects neatly to AI coding governance: the best guardrail is often not a meeting or a policy, but a better artifact boundary. If you want a companion angle on why tiny wording and syntax choices matter to agents, see Why Human Syntax Breaks LLMs.
Copy this local Blender skill boundary
Here is a small Claude-style skill outline you can adapt for a safe experiment. It is not a full production setup. It is a boundary that keeps the agent focused on reviewable outputs.
---
name: local-blender-modeler
description: Create simple Blender models from a reference image or written brief, save reviewable files, and document approximations.
---
Use this skill only when the task asks for a local Blender asset.
Workflow:
- Read the brief and identify the main shapes, colors, and constraints.
- Create or modify files only under artifacts/blender/.
- Save the working Blender file as artifacts/blender/model.blend.
- Export at least one lightweight preview, such as PNG renders or a browser-viewable asset when available.
- Write artifacts/blender/notes.md with:
- source prompt or reference summary
- commands or scripts used
- what is approximate
- what a human should inspect next
Do not:
- Download external assets unless the task explicitly allows it.
- overwrite existing source files outside artifacts/blender/.
- claim artistic or geometric fidelity without a human review pass.
If you use hooks, keep the boundary boring. A pre-tool hook can reject writes outside artifacts/blender/ for this skill. An MCP permission note can mark any asset store or design-system server read-only until the experiment proves it needs write access.
The tradeoff is speed versus friction. Too much ceremony kills the creative loop. Too little boundary leaves you with a mysterious file and no way to decide whether it is good.
Common questions
Is a local Blender skill safe to give an agent?
It can be safe enough for a sandboxed experiment, but only if the boundary is narrow. Limit writes to an artifacts folder, avoid network downloads by default, and require a notes file; those three constraints make the agent’s work easier to inspect after the run.
Does this replace a 3D artist?
No, and it should not be framed that way. The useful output is a rough model, a reproducible script path, and a preview surface; a human still judges taste, fidelity, topology, materials, and whether the generated object is worth refining.
Where does MCP fit in this kind of workflow?
MCP fits when the agent needs controlled access to external context or tools, not just local files. The Model Context Protocol can connect agents to systems like repositories, design stores, or asset catalogs, but a Blender experiment should start with read-only or local-only access unless there is a clear need.
Further reading
Try one small loop
Pick one non-code artifact your agent already produces, then add the smallest viewer or preview next to it. If the next reviewer can understand the output without replaying the chat, you learned the right lesson from Willison’s egg.