Fable 5.2: Connecting Video, Games, Drawing, and 3D with Code

A text model starts making videos, building games, painting, and assembling 3D scenes. It has not become a video model or a piece of 3D modeling software. What it does is more direct: understand a goal, write code, call tools, and carry the work through to an output.

That is what interests me most about the recent Fable 5.2 examples. The point is not that entire creative industries are about to disappear. What is being challenged is the default route into them: open modeling software before making something in 3D; stitch together a production pipeline before making a video; start with an engine and assets before building a game.

From a child's drawing to a playable game

What happens after a child draws a set of characters and imagines a game around them?

In Aiden's Revenge, Lex describes asking Fable 5.2 to continue an existing game project before he went to bed. The next morning, there was a version with 12 levels. After the children played it, they requested more moves and characters, which he then added.

What makes the story compelling is not a claim that AI finished a commercial game overnight. It is that a child's idea became something playable quickly. An adult no longer necessarily has to learn modeling, animation, and level editing before helping that idea take shape. Get it working first, then play and revise it together: that sequence is becoming practical.

Image: Aiden's drawing of Uncle Lex alongside the game sprite. Source: Lex Toumbourou / NotesByLex. This comes from the original article, not my own recreation.

The broader impact is not a single feature. A text model is beginning to take over the connective work in a creative process: turn an instruction into a program, a program into a scene, and a scene into a playable build or a finished video. Games are one entry point; drawing, animation, rendering, and sound follow behind them.

Before going further, it is worth being precise about what “one-shot” means in these examples.

From kart racing to a child's game

Turbo Tails is a 3D kart racer. Peter Yang says he used three initial prompts to get a playable version, then spent a morning iterating on drifting, items, and multiplayer. That is not a final product from a single prompt. It is a working game loop followed by continued refinement.

Aiden's Revenge had a more specific starting point: a child's drawings and the action game he wanted to play. Lex's article records development on an existing project, the overnight task, and the additional characters and moves requested after playtesting. Its “12 levels” should not be rewritten as “a complete game built from scratch with one prompt.” The public version with 18 characters also incorporates later requests.

Image: The 18-character selection screen. Source: Lex Toumbourou / NotesByLex. The expanded roster includes later iterations, not just the initial output from one human instruction.

Two other examples make different trade-offs. SAPPER gives Minesweeper a cinematic visual treatment. Its creator says it started from an empty project and took one prompt and roughly half an hour; that timing and usage are self-reported, not independently verified. Fenlight is not a large game but a moonlit swamp scene. Its creator describes it as a one-prompt project that took about an hour. One reworks the presentation of a familiar mechanic; the other delivers a small, coherent atmosphere. Not every demonstration needs to aim for a blockbuster.

3D is not just about games

These demonstrations challenge a familiar assumption about making 3D content: that convincing shapes, materials, and lighting must come after extensive manual modeling and parameter tuning, before the scene ever reaches an engine.

Stonehenge is an interactive scene combining the monument with the sun's path at the summer solstice. Its creator says it uses a single HTML file and Three.js, and shares cost and token accounting. It is a reminder that “one instruction” can still involve substantial runtime and computation. Mirror Earth is described by its creator as an explorable, destructible mirror of Earth with weather corresponding to the real world. In a follow-up post, however, the creator also notes that vehicles clip through geometry. The impressive parts do not make the limitations disappear.

Code-driven creation is not always a single-generation process, either. Jake Eaton's painting experiments use Python and simulated brushes rather than an image generation model. The process he describes includes weeks of feedback and iteration on the brush engine. Instead of directly turning words into pixels, the text model builds a painting tool and then uses that tool to produce the work.

Image: A painting shared in Jake Eaton's original post. Eaton describes it as roughly 700,000 simulated brushstrokes. This is the original author's demonstration, not a photograph or an independently reproduced result.

The same distinction applies to video. In Riley Brown's Blender room film, Claude writes code to build the scene, create shots and animation, use cloud GPUs for rendering, and connect audio tools. The text model is not directly generating video frames at its output. It is organizing a production system that can make a video.

What does “one-shot” actually mean?

“One-shot” should not be read as “the model made one request and finished everything in a few seconds.” At least four distinctions matter.

First, one initial human instruction does not mean the agent makes only one model request internally. Execution can include repeated planning, coding, running, and correction. Those internal requests do not necessarily mean a person kept rewriting the prompt.

Second, external tools do not automatically invalidate starting a task with one instruction. Blender, Three.js, cloud GPUs, and audio services can all be part of the workflow. Human input, internal model execution, and external service calls should be described separately.

Third, generating an initial version in one go does not mean the later public version was never iterated on. Turbo Tails received gameplay refinements; Aiden's Revenge incorporated playtesting feedback and requests for more characters. Using the final version to prove that one prompt produced every part of it gets the timeline wrong.

Fourth, continuing an existing project is not the same as starting from an empty one. The overnight Aiden's Revenge task began with an older version. That does not diminish its value, but it does determine how to describe it accurately.

The roughly 600 requests in the Aiden's Revenge article should not be rewritten as “the author manually revised the prompt 600 times.” That is the final usage tally across two days, not a count attributable entirely to the bedtime instruction. Internal requests, later human requirements, and tool execution need to be considered separately.

A text model coordinating a production pipeline

Brown says he gave Claude one prompt during a livestream. The model wrote code in Blender to build a room, a desk, a MacBook, lights, and Clawd. The laptop's screen even displayed a Claude-style webpage that the model had made.

Then came 13 shots, key presses, character jumps, and lighting changes from dusk through night to sunrise. According to Brown, Claude rented 10 GPUs on RunPod, completed the 4K render in 52 minutes at a cost of $5.75, and then handled color grading and titles, with ElevenLabs providing music and sound effects.

The striking part is not just the ability to write Blender scripts. It is the way scene construction, shot planning, animation, cloud rendering, and post-production become a connected workflow. The 10 GPUs are Brown's account of this particular run. What matters is the model's choice of a solution: use cloud compute to finish a high-resolution, multi-shot rendering task.

Taken together, these examples suggest that text models are moving toward a central role in creative software workflows. They do not necessarily need to replace Blender, game engines, drawing programs, or video editors. They can control and combine those tools through code, or even construct a task-specific tool along the way. The user describes the goal; the model connects software operations that previously required hands-on expertise.

That is the meaningful sense in which this crosses disciplines. It is not that the model beats specialists at every craft. It is that a general text interface starts compressing the operational barriers, format conversions, and orchestration between specialist tools.

My Saltline recreation

That brings me back to Saltline. Felix Rieseberg says he tested Fable 5.2 with a single prompt and no human feedback, with the game's models, sounds, and materials made from scratch. He reports a runtime of about 8 hours and an estimated API-price cost of about $550, with roughly 2.7 million output tokens and 445 million input tokens, much of the input served from cache.

Image: The title screen of my current deployed version of Saltline, captured for this article. This version includes later menu interaction fixes and retains Felix's on-screen credit. It is neither my GPT-6 Astra recreation nor the untouched original release. No in-game HUD screenshot is included.

I also tried using GPT-6 Astra to recreate the Saltline workflow from end to end. In my attempt, the gap was not whether it could put a page on screen or make a character move. It was in the shapes of objects and the sheen of their materials: whether silhouettes matched the target, whether surfaces read as the intended material, and whether lighting produced convincing reflections. This was not a controlled model evaluation. But in this particular recreation, I found Fable 5.2 noticeably stronger at visual reasoning and coordinating work across steps.

My work on Saltline did not stop at the public demonstration. Preparing it as a deployable website also meant dealing with obscured buttons, layout at different window sizes, and sluggish click responses. The original demo and the later modifications need to be distinguished. The online version includes subsequent fixes; those fixes should not be credited to the original build as problems it had already solved.

That is the distance between a demonstration and a deliverable. A demo shows that a model can turn a goal into an impressive first version. Deployment asks whether a button can actually be clicked, whether content crowds together in a narrow window, and whether an interaction responds promptly. One case makes those tasks visible. It does not establish a success rate for AI projects in general.

The assumption being challenged may be tool worship

Saltline still uses Three.js, as does Stonehenge. Fable 5.2 has not eliminated the 3D engine. What it challenges is the belief built around engines and manual modeling: that only someone who has mastered specialist software and crafted each model by hand can create a convincing 3D world.

In my GPT-6 Astra recreation, shape and material were where I felt the difference most directly. Brown's example highlights another capability: not only constructing space, but planning shots, choosing rendering resources, and carrying the scene through a production pipeline. Different examples do not make a rigorous leaderboard. Together, though, they show the depth and range of Fable 5.2's approach to these tasks.

None of this makes modelers, technical artists, or engine engineers unimportant. Production content still needs to be controllable, editable, and consistent, and must pass performance and quality checks. The earlier change is more likely to happen in prototyping: someone with an idea can get a visible or playable version sooner, then decide what deserves further work.

The shift goes beyond the barrier to hand-built 3D models. We have often treated knowing a particular application as if it were creative ability itself. Now a model may write code to build a scene, use Blender for animation, rent GPUs to render it, and call an audio tool for a soundtrack. The tools remain, but a person may no longer have to open and operate each one individually.

What is being lowered is the workflow wall between video, games, drawing, and 3D. Professional creators do not lose their value. But making a first watchable or playable piece may no longer require becoming proficient in four different applications first.

To explore an example, try Saltline. For the original accounts, see the Aiden's Revenge article, Turbo Tails post, Jake Eaton's code-driven painting, and Riley Brown's Blender production notes. Times, costs, and production workflows cited here are the creators' own accounts, not independently verified measurements.