fable51-worlds: An Agent Swarm Rebuilt Union Square in 3D for $33

An open-source repo that reconstructs a real San Francisco city block in 3D — researched, modeled, and quality-checked almost entirely by autonomous AI agents — hit the top of Hacker News on September 2, 2026, and pulled in over 45 comments arguing about whether the underlying pipeline is actually production-ready. fable51-worlds, built by PhiloLabs, uses swarms of Claude Fable 5.1 subagents to turn OpenStreetMap data and public reference photography into an explorable Three.js reconstruction of Union Square — no game engine, no licensed 3D tiles, plain code you can npm run dev. The project's most quotable detail isn't the visuals; it's the cost. The author says the whole thing was a one-shot run: about 2 hours, roughly 8 million tokens, and $33 total.

This piece walks through what's actually in the repo, the four-stage pipeline that built it, the real $33 cost math, and the sharpest technical pushback from Hacker News — because the 2x-not-10x discipline this blog applies to every viral agent demo applies here too: state what's confirmed, then get into where commenters with hands-on 3D pipeline experience think the approach still falls short.

TL;DR

What's actually in the repo

The README frames the whole project in one line: "Worlds via code. Explorable, browser-native reconstructions of real places — researched, modelled, and quality-checked end to end by autonomous Claude Fable 5.1 agent swarms, then shipped as plain Three.js apps you can run with npm run dev." Every building, storefront sign, tree, and traffic light is generated from open data — OpenStreetMap geometry and public reference imagery — by code committed to the repo, not sourced from a licensed tileset or game-engine asset store.

The first (and so far only) world is Union Square, San Francisco, covering the square itself and the surrounding blocks along Powell, Geary, Post, and Stockton on real terrain and the real street grid:

One Hacker News commenter asked specifically about the pedestrian and traffic logic, and links to the actual pathfinding source files were shared in the thread — confirming the 1,398-node navigation graph is real and inspectable, not a marketing number. It's nav-graph-based routing, not vehicles and people moving "on rails."

The four-stage pipeline

This is the part worth understanding if you're evaluating any agent harness for a similar 3D or spatial-reconstruction task — fable51-worlds isn't one long prompt producing a scene in one pass, it's a structured pipeline with distinct agent roles at each stage.

1. Reconnaissance

Parallel research agents pull OpenStreetMap geometry, USGS elevation data, transit and street specs, and a storefront census. Every fact gets tagged with its source and a confidence level — a lightweight provenance system that matters later, both for the QA step and for the ODbL/public-domain licensing trail.

2. Offline asset generation

Blender-as-a-library (bpy) scripts run offline to emit optimized GLB asset kits: façade modules, street furniture, vehicles, vegetation, retail fixtures, and pedestrian body parts. This is the same class of code-driven, no-game-engine asset generation covered in explainx.ai's img2threejs coverage — geometry produced by parametric scripts rather than hand-sculpted in a 3D editor.

3. Runtime assembly

A pure Three.js app assembles terrain, streets, façades, props, crowds, and traffic from JSON specs at runtime. No game engine, no proprietary tile service — just a browser app reading structured data.

4. Camera-match QA

This is the stage that distinguishes fable51-worlds from a typical "one-shot and hope" agent demo. Playwright drives the actual running app, screenshots fixed viewpoints, and diffs them against free-licensed photographs taken from the same spot. Independent reviewer agents — playing the roles of architect, geographer, technical artist, and interaction designer — file structured reports that drive the next fix cycle. The project ran 34 camera-matched viewpoints, producing 147 comparison sheets and 9 independent reviewer-agent reports before calling Union Square done.

What it actually cost: $33, 8M tokens, 2 hours

The project's own author posted the cost breakdown directly in the Hacker News thread, and it's the single most citable data point in the whole story. This was a one-shot result — not massively iterated — built from one very long, carefully structured prompt with explicit guidance on subagent usage and a self-QA loop baked in.

That figure sits well inside the range this blog's own AI agent monthly cost modeling would predict for a heavy, cache-assisted parallel subagent run — high token volume kept affordable by parallelism and caching rather than by the task being small. It's a useful real-world anchor next to two other recent agent-built-3D-world demos this blog has covered: the Opus 5 Homeworld-style space RTS, which ran $632.65 on a much longer /loop-until-perfect session, and the Opus 5 procedural desert explorer, built with zero downloaded meshes or textures. fable51-worlds is cheaper than either — partly scope, partly because a structured four-stage pipeline with a defined stop condition (34 fixed viewpoints, not "loop until a critic is wowed") burns fewer speculative iterations than an open-ended quality bar.

The author also mentioned in-thread that a survey paper on "world modeling via code" is in progress, with collaborators referencing Qwen Omni and OpenAI as well as Oxford and Stanford, and that most San Francisco tourist landmarks have already been generated internally and will land in the repo soon. They also said they're experimenting with GLM-5.3-Flash as a cheaper alternative model for the same pipeline — worth watching if it lands, since it would be a second cost data point on the same repo's own pipeline rather than a different project entirely.

What people are asking: is this actually production-quality?

The most substantive part of the Hacker News thread wasn't awe — it was a genuine technical disagreement between two commenters with real 3D-pipeline experience, and it's worth walking through both sides rather than picking a winner.

The skeptical case. A commenter building an RTS game (playwarpact.com) gave detailed pushback: Opus 5 is "just as good for this, and cheaper" for many cases, and the models generate unoptimized, high-poly-count geometry even for simple shapes. Their view of the better production pipeline: have the LLM generate low-poly silhouettes, then bake detail onto them with a diffusion-model mesh tool like Meshy — describing the fully autonomous, optimized version of this pipeline as needing "more RL" before models can do it end to end on their own.

The counter-argument. A second commenter (avaer) with hands-on world-model experience pushed back with specifics: Opus hits a real fidelity ceiling on things like foliage L-systems, physical mob animation, or realistic appliance placement — it "flails" past a certain threshold — while Fable "takes forever but knows how to zoom in and out on the abstractions." They also noted that by default, LLMs take the quick-prototype path (primitives slapped into a Three.js scene) unless explicitly prompted toward an efficient art pipeline with mesh connection and instancing. Crucially, they largely agreed with the skeptic on one point: diffusion-model mesh generation (Meshy and similar) is still roughly 10x better than LLMs at physically plausible geometry. Their proposed middle path is a hybrid "socketing" technique — the LLM generates a high-level blockout structure with defined sockets, and diffusion-generated high-poly objects slot into those sockets — as the more production-realistic approach today, rather than expecting a fully LLM-driven mesh pipeline.

A third framing worth adding. A separate commenter argued the topology/texturing critique is fair for raw AI mesh-generation approaches specifically, but that code-generated worlds — an LLM writing Three.js or Blender scripts using primitives, CSG, and parametric construction, which is exactly what fable51-worlds does — mostly sidestep the "messy topology" problem, because the geometry comes from clean parametric construction rather than something that needs cleanup afterward. Texturing remains a real gap in that framing, though procedural materials cover more ground than people expect going in.

The "what's the point" thread. Multiple commenters raised a separate, more skeptical question: impressive, but useful for what beyond a demo? The substantive reply argued that CAD-from-data and photorealistic-at-city-scale reconstruction is normally thousands of person-hours of manual modeling, placement, and QC — and that recent prompt-to-CAD progress is opening up hobbyist access to workflows that used to require, for example, Fusion 360 expertise and a full weekend. One commenter drew a historical parallel to VRML, a 1990s markup language for 3D environments that never caught on — an interesting, if unresolved, comparison for whether code-generated worlds become a real medium or stay a demo genre.

None of this is a knock on the repo's real technical achievement — a $33, 2-hour, one-shot reconstruction with 147 comparison sheets of QA evidence is a genuinely strong result. It's a useful, honest snapshot of exactly where the frontier sits: LLM-orchestrated pipelines are strong at structure, provenance, and iteration discipline; diffusion models still win on raw mesh fidelity; and the practical answer for anyone building this today is probably some version of the hybrid socketing approach both HN commenters converged on, not a pure end-to-end LLM pipeline.

Small team, big leverage

One data point worth naming directly: fable51-worlds has two credited contributors — christine1729 and a Claude account credited as co-contributor via commits — with 106 GitHub stars and 3 forks at time of writing. A full four-stage research/model/QA pipeline, camera-matched against 34 real-world viewpoints, shipped from what is effectively a one-person team plus heavy agent-swarm usage. That's consistent with the broader agent skills pattern this blog tracks — small teams increasingly shipping work that used to require a much larger crew, provided the harness around the model does real orchestration work rather than a single flat prompt.

Licensing, done carefully

fable51-worlds gets the legal hygiene right in a way worth flagging as a model for similar projects: code and generated assets are MIT licensed, but geometry derived from OpenStreetMap keeps OpenStreetMap's own ODbL license, and USGS 3DEP elevation data is US public domain — the project doesn't try to relicense inputs it doesn't own. Reference photographs used to camera-match the QA step are not redistributed; provenance is tracked per sector in refs/*/SOURCES.md instead. And the README is explicit that brand names and logos depicted in the reconstruction — Apple and Nintendo, since both have real stores at the reconstructed addresses — identify real businesses at real locations and belong to their owners, not to the project's MIT grant. That's a level of licensing care that a lot of "AI generated this from public data" projects skip.

Try it yourself

git clone https://github.com/PhiloLabs/fable51-worlds
cd fable51-worlds/union-square-sf
npm install
npm run dev

No game engine install, no API key, no proprietary tileset access required to explore the world locally — the entire runtime is the Three.js app in the repo.

What builders should take from this

1. A structured pipeline beats an open-ended "loop until perfect" prompt on cost. fable51-worlds' four fixed stages (recon, offline asset gen, runtime assembly, camera-match QA against 34 viewpoints) produced a $33 result; open-ended /loop-until-a-critic-is-satisfied sessions on comparable 3D builds have run into the hundreds of dollars.
2. Camera-matched QA against real photography is a genuinely strong verification pattern. Screenshotting fixed viewpoints and diffing against ground truth, then having role-specialized reviewer agents file structured reports, is a reusable technique for any agent pipeline producing visual or spatial output, not just 3D worlds.
3. LLM-orchestrated code beats raw AI mesh generation on topology, not fidelity. Parametric, code-generated geometry sidesteps messy-topology cleanup — but diffusion tools like Meshy still lead on physically plausible detail. The realistic production path today is hybrid, not either/or.
4. Publish token and cost receipts, not just the demo. As with other recent agent-built-3D coverage on this blog, the number that made this story credible and debatable — rather than just a cool clip — was the specific $33/8M-token/2-hour breakdown posted directly by the author.
5. License provenance matters as much as the build itself. Tracking OSM/ODbL, USGS public domain, and un-redistributed reference photos separately from the MIT code grant is the kind of detail that keeps an otherwise-impressive open-source AI project from becoming a legal liability later.

Related on explainx.ai

• Claude Fable 5.1 and Mythos 5.1 — benchmarks, pricing, safeguards
• What is an agent harness? The scaffolding layer that makes AI agents reliable
• Opus 5 built a Homeworld-style space RTS from one prompt — $632.65 later
• Opus 5 built a procedural desert you can actually walk to
• What running an AI agent actually costs per month
• 2x, not 10x: what coding with LLMs actually delivers in 2026
• What are agent skills? A complete guide
• img2threejs — procedural photo to Three.js
• LingBot-Map — streaming 3D reconstruction
• Did Opus 5 one-shot Call of Duty in the browser?

Primary sources: PhiloLabs/fable51-worlds on GitHub — README, pipeline documentation, and license files as published; Hacker News discussion thread, September 2–3, 2026 (139+ points, 45+ comments at last check).

Repository stats (stars, forks, contributor count), cost figures, and pipeline details reflect the state of github.com/PhiloLabs/fable51-worlds and its Hacker News discussion as of September 3, 2026. Star counts and in-progress items (the world-modeling survey paper, additional San Francisco landmarks, GLM-5.3-Flash experiments) are likely to change — check the repo directly for the current state before citing specific numbers.