One brief, three Claude models: three beach houses you can walk through

On 12 November Caleb Fahlgren posted a detailed two-storey house that Fable 5.2 built from one prompt, and the prompt asks the model to "send me screenshots as you build it and use subagents ot critique." There was no scene file to open, so in the 3D and BIM roundup we ran the method ourselves with Claude Opus 5.5 and a beach house. Then we ran it twice more, with Claude Fable 5.2 and Claude Sonnet 5.5, from the same design brief, each from an empty directory and told not to open the others' work.

So there are three houses. Each one is a .glb of 5 to 6 MB with its lighting baked in, and each loads in the same viewer on this page. You can walk up all three staircases below. What I wanted to know was simple: given the same brief and the same loop, how different are the results, what did each one cost, and which would I keep?

Short answers. Sonnet reached a critic's yes fastest, in three review rounds and about 42 minutes, and built the house every blind judge put last. Opus never got a yes in four rounds and about 48 minutes, and built the best-dressed site. Fable took five rounds and about 93 minutes spread over two days and three machines, got two yeses in a row, and won the blind ranking narrowly over Opus. The rest of this page is how those numbers were made and why I trust some of them more than others.

The brief, and where it was not quite the same

This is the brief as the Fable and Sonnet runs received it, word for word (Sonnet's copy adds "no normals needed (unlit)" at the end):

an original two-storey beach house near a beach: whitewashed timber walls, a wraparound deck or veranda, big windows and sliding doors facing the sea, an upstairs balcony, an outdoor shower or deck chairs, a path/boardwalk down through dune grass to the sand, the shoreline and water, warm late-afternoon light baked in; a model you can walk through in the browser (interior and deck). Rules: every mesh and material generated procedurally in Python (bpy) — no downloaded models, textures or HDRIs; bake the lighting (Cycles bake) into textures/vertex colours so the viewer needs no lights; merge by material; target ≤ ~150k triangles and a .glb ≤ ~6 MB, no Draco/meshopt; positions/UVs float32, indices uint16 where possible.

Opus ran first and got its brief in pieces: a launch prompt with the same pipeline rules, then Satyajit's design direction as a message, which reads "Think timber/whitewashed walls, a wraparound deck or veranda, big windows and sliding doors facing the sea, an upstairs balcony, outdoor shower or deck chairs, a path or boardwalk down through dune grass to the sand, the shoreline and water". The later prompts tightened that into the paragraph above. Two differences matter. Opus's walls were "timber/whitewashed", a looser word. And its loop had no stop at yes: its launch prompt said to critique "as a fresh, harsh reviewer" and repeat "until it's genuinely good", where the other two were told to stop when "a critic says yes or you judge more passes won't help". Opus also had to write the viewer the other two used.

The design half came from Satyajit; the rules half came from us, and they shape everything. "No downloaded models, textures or HDRIs" means every plank, cushion and palm frond is a Python function. "Bake the lighting" means the browser never computes a shadow.

Why bake, and what the loop is

A browser can draw a hundred thousand triangles smoothly if it does very little work per pixel. It cannot do soft shadows, light bouncing off an oak floor onto a white wall, or sun falling through a balustrade onto deck boards, at least not without a renderer much larger than this site wants to ship. So the expensive part happens once, offline. Blender's Cycles path tracer computes how much light reaches every point of every surface and writes it into a texture, the atlas. Each surface gets its own patch of the atlas, and the viewer looks up that patch and draws it unlit. The light you see from inside the house is a photograph of light, taken in Blender and pasted onto the walls.

That trade explains most of what follows. A bake costs minutes on a GPU, so every round of the loop costs minutes. Atlas resolution is the file budget: a 4,096 px square JPEG is a megabyte or two, and three of them are most of a 6 MB file. And any surface the bake gets wrong (a texel buried inside another mesh, a seam between two patches) is wrong from every angle, permanently, until the next bake.

The loop around it was the one from Caleb's prompt, made explicit:

1. A Python script builds the whole scene from nothing.
2. Cycles bakes the light into atlases.
3. A writer packs geometry and atlases into a .glb.
4. Headless Chromium loads it through the site's own loader, house-gl.ts, and screenshots a fixed list of cameras.
5. A new subagent, one that has seen nothing else, gets the brief and the screenshots and answers yes or no, with at most five ranked problems, each with a numeric fix.
6. Fix the worst thing, and go again until a critic says yes or more passes stop helping.

The critic never sees the code. That is the point of it and also its weakness, as the next sections show.

Three machines, so the clocks do not compare

All three runs used Blender 4.5 or 4.2 headless over SSH, but not on the same hardware, because the GPUs were needed for other work part way through.

• Opus 5.5 baked every pass on an RTX PRO 2000 Blackwell (16 GB) with OptiX.
• Sonnet 5.5 baked passes 1 to 3 on the same Blackwell GPU. After a pause it rebuilt its final pass on an RTX 3090 (24 GB) under a lock file, in 124 s for the whole run.
• Fable 5.2 started on the Blackwell GPU (while another job held it at 98 percent), moved to the 3090 after the pause, then back to the Blackwell box with its GPU reserved for a training run, so its last four rounds baked on 24 CPU threads. Its final bake took 420 s.

Per-pass bake times are therefore not comparable across the three, and Fable's CPU rounds forced it to bake lighting at half the atlas resolution. Wall times are not like for like either. Opus's clock includes writing the 900-line viewer everyone else then used; Fable's includes extending that viewer and writing its own .glb writer; Sonnet tested against the viewer as it found it.

The three houses

Opus 5.5: the best-dressed site, and no yes

Opus wrote one build.py of 1,203 lines plus a 66-line assembler, and let Cycles bake colour and light together into three atlases. It ran seven passes in 45 minutes from its first test render to the file (48 minutes from launch), at about 200 s a pass. Four of those passes went to a critic, and all four said no; the last said "No, but it is close." Its log is in the roundup's subsection, and I won't repeat it, except to say the critic loop found one bug no amount of looking at the script would have: every window trim and shutter had its faces wound inward, so the viewer culled them from outside.

One thing the critics never flagged: in its first pass, by its own self-critique ("all-white house reads blank"), Opus repainted the siding sea-glass blue-grey. Its looser "timber/whitewashed" brief allowed that; the other two kept their walls white.

expand

Fable 5.2: light baked alone, colour painted after

Fable did something structurally different, and it shows up in the file size. It never asked Cycles for colour. Every surface is a flat rectangle with its own patch of the atlas; Cycles bakes only how much light lands on each patch, and the boards, shingles, tiles and rugs are numpy functions of world position, multiplied in afterwards. That split let it denoise the light hard with OpenImageDenoise without blurring a single plank line, and rebuild the textures in about 20 seconds without rebaking. It wrote its own .glb writer too, and a 969-line framework under a 1,220-line house.

Its log has five critics: no, no, no, yes, yes. Before any critic saw a frame it had already caught that Cycles does not denoise bakes, that its top rails baked black because their only vertices sat inside the posts, and that the first house's sun angle left the sea front in the veranda's shadow, so it moved the sun and taught the loader to read an optional sun direction from the file.

expand

Sonnet 5.5: geometry without Blender, and the fastest yes

Sonnet built its geometry in pure Python before Blender ever saw it: a 215-line geo.py of boxes, prisms and polygons with automatic winding, a 358-line house.py of about 4,160 flat faces, and a 706-line build.py with its own shelf UV packer (one rectangle per face, shared rectangles for identical small parts). Cycles then baked two passes per face, colour at 8 samples and diffuse light at 400, and the script multiplied them, blurred the light per island, picked an exposure from the 99th percentile and tone-mapped to sRGB. The result is two atlases instead of three: 4,096 px for the house and 2,048 px for the terrain.

It ran a geometry-only pass at 19:44, 15 minutes after launch, then three baked passes on the Blackwell GPU at 159 to 170 s each. Critic one said no, critic two said no ("close"), and after the pause critic three said yes. The file came out at 6.42 MB, over budget, so it recompressed the atlas JPEGs with PIL to 5,032,332 bytes rather than rebaking.

expand

expand

Side by side

I parsed the three .glb files for the triangles, bytes and atlases. Passes, verdicts and times come from each run's own log.

Two rows need a warning. The wall times are all on one clock, from each run's launch message to its finished file, with the overnight pause taken out; they still include different work (Opus wrote the viewer, Fable a framework and a .glb writer, and Fable moved machines twice). Each log keeps its own count too: Opus's 45 minutes start at its first test render, Fable's 97 at its first read of the viewer code and run to 20:05 on the first day. And the verdicts were not given against the same bar. Fable's critic prompt defined yes as "good enough to publish" and told the critic to judge "a good low-poly real-time scene, not an offline photoreal render". Opus's log did not keep its critic prompt, but its own instructions asked for a "harsh" reviewer and set no yes to stop at, which may be part of why it never heard one. Sonnet's notes do not record its critic prompt. A softer prompt buys an earlier yes.

The atlas row is where the methods show. Opus baked colour and light together into 3.7 MB of JPEG. Fable's light-only bake compresses better, because light varies slowly, and its colour detail is in the same atlas at half the bytes. Sonnet spent the fewest bytes by packing everything into one house atlas and then turning the JPEG quality down until the file fit.

What the critics got right and wrong

Every run's critics found real problems, and every run's critics were also wrong in the same way: they reported things missing that were simply behind the camera.

• Opus. The one bug it could not have found alone, the inward-wound trim, came from critic one. Wrong: a "shadow with no caster" (the umbrella's long low-sun shadow, correct at 16 degrees); headboards, pillows, a toilet and a mirror reported missing when every camera faced away from them; and, in the last round, "no tub".
• Fable. Fable triaged the 20 findings from rounds 1 to 4 against its code: 15 real, 4 half right (the right symptom with the wrong cause, or already present: the glass tint, risers already white, towels behind the camera, "uniform UVs" on a texture that was already in world space), and 1 mixed item whose second half was a plain mistake (no sun in the aerial view; it was behind the camera). Fixing "the bathroom looks unfinished" turned up a bug nobody had named: the sink texture covered the whole vanity top.
• Sonnet. Critic one found a real bug, black seat pads where two chairs shared one atlas rectangle and the shadowed chair overwrote the lit one, plus a z-fighting triangle in the bath water and a grey tone map. Its mistakes: "no toilet" (off camera) and "no ambient occlusion" (the bake already includes bounced light). Critic two wanted baseboards that were there. Critic three said yes while still listing a skirting, a mirror and a tub as missing.

The pattern I take from it: a critic that only sees pictures is good at symptoms and bad at causes, and its "missing" findings are a camera problem about half the time. Worth acting on, but only after someone checks the scene.

Eleven views, three judges, no names

The critics answer "is this done?", not "which is best?". For that I ran a separate blind comparison, and I want to be exact about how, because the first version of it had a flaw.

Fable's run had already done a paired check: two fresh subagents compared ten views of its house and Opus's as "House A" and "House B" and both picked Fable's, seven views to three. But those were each builder's own cameras. A builder that frames its kitchen well wins the kitchen view whether or not the kitchen is better.

So I rendered new views myself, the same list for all three houses, through the same loader in headless Chromium at 1600 × 900:

• The two aerials use identical camera positions for all three.
• The other nine are at eye height, 1.6 m above whatever floor is under the camera, with the walk lens. The seven views inside and on the decks tilt 8 degrees down; the beach and boardwalk views stand at the same map position for all three and aim at the house, so their tilt varies a little with each house's height (the judges were told 8 degrees for all of them, which was not quite true). Interior views stand at the equivalent spot in each house's own plan (the back of the living area looking at the sea, the seaward corner of each bedroom looking back across it, and so on), because the three floor plans differ.
• No geometry closer than about 0.8 m to the lens.

That list was not fixed in advance, and I should say how it moved. I set the cameras up while looking at contact sheets that said which house was which. After the first sheet I changed the bedroom rule for all three houses (from "back of the room, facing the sea", which stood Opus's camera on a bed, to "seaward corner, looking back across") and the bathroom aim; moved Sonnet's second-bedroom camera again because it still stood on furniture; and added the 0.8 m clearance rule after seeing a door jamb fill a third of two bathroom frames, then moved those two cameras. The frames were frozen before any judge saw them. And "equivalent spot" is my judgement where plans differ.

The frames went to three fresh subagents, labelled A, B and C in a different order for each, with only the brief paragraph and a one-line description per view. I pinned one judge to each model, Opus, Sonnet and Fable, so no single model's taste decides it, and fixed the scoring before reading any answer: Borda points on each judge's overall ranking (2 for first, 1 for second), with first places across the 33 view judgements as the secondary count.

The overall rankings:

Borda: Fable 5, Opus 4, Sonnet 0. First places over 33 view judgements: Fable 17, Opus 16, Sonnet 0. Sonnet came third in 27 of the 33 and second in 6.

Between Fable and Opus it is close to a coin toss on any single view, but the split is not random. Opus won all six aerial judgements, and all three judges' calls on the living room and the second bedroom. Fable won all three on the deck, the balcony, the main bedroom and the bathroom, and every judge ranked its lighting first. The judges' reasons line up with that. From the air, Opus's site tells the story: a dune fence, a stepped boardwalk to a fire pit and loungers, an outdoor shower, a chimney and shutters. At eye level, Fable's baked light does the work: rail shadows raking across the deck boards, sun patches on the floors, a sea front that is not blown out. Two judges called Fable's palms off-brief for a dune beach, and two called Opus's house washed out or white on white at eye level.

Sonnet's house lost on furnishing and light, not on correctness. All three judges credited it with the crispest, most legible architecture of the three and no texture smear, and one noted it has the biggest glazing. They also called its furniture primitive, its rooms sparse and its bathroom close to an empty box, and one said it stands in uniform grass with barely any beach.

Now the caveats I can't remove. The judges are Claude models judging Claude models. The Fable-pinned judge picked Fable, which could be self-preference; the Opus-pinned judge also picked Fable, and the Sonnet-pinned judge put Sonnet last, so there is no sign of a model simply favouring its own work, but one judge per model is not a measurement of bias. Three judges is a small panel. And everything here is judged from still frames; nobody walked the houses for the ranking.

Which house for what

If I had to ship one as the site's beach house, I would ship Fable's. It is the one that looks best where a visitor actually stands, on the deck at eye level with the light coming in low, and that is what a walkable model is for. Its gaps are real and listed in its own log: an empty landward side, unbevelled cushions, half a bedroom with nothing in it.

If I wanted a model to show from the air (a site plan, a thumbnail, a client overview), I would take Opus's. It read the brief's site list most literally and its exterior has the most character. It also did the job in the fewest triangles, 72,249, and in about half Fable's time, while writing the viewer. It is the only one of the three that never got a yes, which says more about its critics' bar than about the house.

Sonnet's I would use as a starting point, not a result. It is the cleanest geometry, the most legible from a distance and the smallest file, and it got there in 42 minutes. But it is the clearest evidence on this page that a critic's yes is a weak signal. It got the earliest yes and finished last with every judge.

The practical lesson is about cost. Each round of this loop is a bake of two to seven minutes plus a critic, so rounds are what you pay for. Three rounds bought a house that is correct and plain; five bought one that holds up at eye level, at about twice the wall time on worse hardware. The loop does not tell you when to stop. A critic's yes means nothing is visibly broken; it does not mean the house is good. If I ran it again I would keep the critic for bugs and add a paired, blind comparison against the previous pass before accepting any change, the rule Meng To uses in the roundup's apartment run, because "is this better than last time?" is a question a picture-only judge answers much more reliably than "is this finished?".

For anyone doing capture work, none of these houses has a reference, so every judgement here is about plausibility. With a scan or a photo, the critic could compare against the real thing, which is what kotohibi's shrine sheets do, and the "missing because behind the camera" class of mistake would mostly go away.

Where these numbers come from

I ran the matched-view renders and the three-judge comparison for this page, and parsed the three .glb files for triangles, bytes and atlas sizes. Passes, critic verdicts, critic quotes, bake times and the real-bug versus critic-mistake triage are from each run's own log (Opus's log.txt, Fable's log.md, Sonnet's notes), written by the model doing the work; I checked the times against the session's launch and pause messages. Fable's ten-view paired judgement is from its run. None of the three build scripts is published.