Claude Fable 5.2 decodes typo-ridden prompt and generates full 3D animation in Three.js

A garbled prompt to test a new model

Simon Willison, creator of Datasette and one of the most widely read bloggers on LLMs, wanted to understand where Yonkers, a city neighboring New York, is located. After checking Google Maps, he turned the curiosity into a test: he asked Claude Fable 5.2 (Medium variant) to draw the city "coming to life" in 3D, using real OpenStreetMap data. The account was published on November 10, 2026, on Willison's blog.

The result is called Yonkers Rises: an animated 3D diorama in which Yonkers' real outline turns into a giant mech that rises from the ground and walks through Manhattan, Brooklyn, Queens, and the Bronx. The scene runs a "standing up" sequence followed by a looping stomping walk, with buildings being flattened at each step. A stomp counter, a mech height indicator, and a status line (which changes depending on whether it's stepping on dry land or entering water) complete the interface.

The prompt the model had to decode

Willison didn't write a careful prompt, revised sentence by sentence. He wrote the kind of text anyone types on their phone, in a hurry, with autocorrect turned on:

Make a three js animation where yonkers stands up as a big mech (cool stand up motion) and átomos around manhattan and queens and Brooklyn, use openstreetmap mapping data

Simon Willison, creator of Datasette and author of the blog simonwillison.net

The word "átomos" stands out due to a detail that Willison himself didn't explore, but that's worth highlighting for Portuguese-speaking readers: it is a real word in the Portuguese language. Everything suggests that his phone's keyboard had the Portuguese dictionary active and "corrected" the English word "stomps" into the closest term it recognized in another language, swapping a verb for a noun from a different language.

According to Willison, Claude Fable 5.2 Medium correctly inferred that "átomos" should have been "stomps" and generated the animation with the mech stomping around the boroughs, exactly as the intended sentence (without the typo) requested.

Why decoding a typo matters more than it seems

Development tools tend to assume clean text: the compiler complains about a missing parenthesis, the linter points to the exact line. Conversational interfaces and code agents receive a different kind of input: voice dictation, phone typing, non-native speakers, hostile autocorrect. Deciding that "átomos" made no sense there and that "stomps" fit the context (mech, standing up, walking through the boroughs) is semantic inference, not spell-checking.

This has direct implications for those who design copilots and agents:

• An input sanitization layer becomes less necessary when the model itself resolves ambiguity through the context of the task.
• The inverse risk exists: a wrong "correction" by the model can change the intended meaning without warning the user, and Willison's post doesn't discuss this scenario.
• In visual code generation pipelines (3D, UI, data), the cost of a wrong interpretation is higher than in a text chat, because the error only shows up after the scene has already been rendered.

From the real outline to WebGL: what probably happened underneath

Willison didn't publish the generated code, so what follows is technical inference about the kind of pipeline needed for this result, not a description of what Fable 5.2 actually produced. To turn an OpenStreetMap municipal outline into an animated mech in Three.js, a typical skeleton would need to fetch the city's boundary polygon, project the geographic coordinates (latitude and longitude) onto a local plane, and extrude that shape into a three-dimensional geometry:

// Illustrative skeleton of an OSM -> Three.js pipeline
// (not the code generated by Willison, which wasn't published)
import * as THREE from 'three';

async function loadBoundary(cityName) {
  const geojson = await fetch(`/osm/boundary?city=${cityName}`).then(r => r.json());
  return geojson.features[0].geometry.coordinates;
}

function boundaryToShape(coords, project) {
  const shape = new THREE.Shape();
  coords.forEach(([lng, lat], i) => {
    const [x, y] = project(lng, lat);
    i === 0 ? shape.moveTo(x, y) : shape.lineTo(x, y);
  });
  return shape;
}

const coords = await loadBoundary('Yonkers');
const shape = boundaryToShape(coords, equirectangularProject);
const mechBody = new THREE.ExtrudeGeometry(shape, { depth: 400, bevelEnabled: false });

The status line that switches between land and water suggests some point-in-polygon test against OpenStreetMap's own water layers in the GeoJSON. The buildings "flattened" at each stomp indicate simplified collision between the mech's foot and the building meshes, probably swapping the building's vertical scale to zero when the impact happens. None of this is confirmed by Willison; it's the most plausible path for anyone who has already worked with geographic data in WebGL.

What changes (and what doesn't) for developers

This demonstration is not a benchmark. It's a one-off usage account, with no published code, no generation-time metric, and no comparison with other models. It counts as a signal, not as proof.

Where this kind of generative capability already helps:

• Rapid prototyping of geographic data visualizations, without manually building the OSM-to-geometry pipeline.
• Educational or outreach material, where geometric precision matters less than the idea being conveyed.
• Internal demos and proofs of concept to validate whether a creative direction is worth the production investment.

Where it still doesn't replace the work of those who build real 3D applications:

• Production WebGL performance requires fine control over draw call count, level of detail, and mesh optimization, something a loose prompt doesn't guarantee.
• Geographic precision for serious use (urban simulation, scientific visualization) requires validating the data source, not just a visually convincing result.
• Without the code available, there's no way to audit, version, or maintain what was generated.

Willison as an informal thermometer for models

Willison's pattern is to test models in real, somewhat random situations from his own life, not in formal benchmark suites. The same list of recent blog posts includes "Locating the source of a mysterious beep with Claude," from November 9, 2026, and "Qwen 3.8 27B on my laptop can interpret model weights, too," from November 3, 2026. It's a way of evaluating models that's worth following, but one that calls for the same caution as always: treat it as a hint of capability, not as a reproducible guarantee for your use case.