Having AI make a game is no longer anything new today.
But what if, instead of handing over a small page with clickable buttons and movable characters, it worked continuously for eight hours and created the scenes, models, textures, and sounds as well?
Anthropic’s Felix Rieseberg shared such an experiment. He wanted to see what Claude Fable 5.2 could make of a game without adding human feedback. According to his public record, this run took about eight hours, cost about $550 at API pricing, accumulated about 445M input Tokens and 2.7M output Tokens, and made extensive use of caching. Original post
These figures are not our own measurements, nor are they a standard quote for “making a game.” But compared with simply saying “the model has become stronger again,” they at least reveal a concrete question: when models can keep writing code, where will the boundaries of creation shift?
This article does not run benchmarks and mainly looks at three public cases. The images come from projects or demo screens publicly shown by their creators; descriptions involving time, cost, and generation processes are presented according to the sources, without treating personal experiments as general conclusions.
¶ What was made in eight hours is a small level, not a complete blockbuster game
The game Felix showed is called Saltline, a first-person shooter project that can be experienced in a browser. Project link
Saltline demo screen, taken from the video cover in Felix Rieseberg’s original post, with only a static image cited. Source: author’s original post.
His prompt was not long: he wanted a first-person shooter with visuals as detailed as possible, but with a small scope—it could be just one very small level. Public prompt
The “small” here is important.
Concentrating production resources on a short experience is a different level of difficulty from making a content-rich commercial game that can be played continuously for dozens of hours. The AAA-level visuals mentioned in the prompt are also only a goal, not a quality conclusion reached through evaluation.
What is truly worth noting is how the assets were generated. Felix later added that the textures and models are all functions, with no image files or 3D model files; the source code is in the HTML and can be viewed directly. Additional explanation
According to the author, this was not a case of first calling an image model to generate a picture and then making it move, but of using programs to construct the things in the scene.
This approach is highly appealing to creators: if they want to change a patch of lighting, adjust an object’s proportions, or switch materials, they can try modifying parameters and logic rather than regenerating the entire image. For interactive content, code can also directly handle cameras, collisions, and input responses.
But being modifiable does not mean being easy to maintain. We have not audited the game’s source code here, nor have we completed multi-device compatibility testing. A demo that looks good still has some distance to go before becoming a stable product.
In addition, “completed with one prompt” is also easy to misunderstand. It means that the author did not continue directing this run; it does not mean the model was called only once, much less that it was delivered in a few seconds. The eight hours and that bill are both part of this case.
¶ Hundreds of 3D worlds are more interesting than one beautiful scene
Ethan Mollick’s experiment pushed this in another direction.
He gave Fable a description, hoping to create a journey through different 3D worlds connected by portals, where the traveler could move forward automatically. According to his record in Fable 5.2 and Jagged AGI, after twenty hours, the website had 204 worlds; the number later recorded in the article had already exceeded 450. Author’s article
Here, the number at any particular moment is not fixed as the “final result.” This is a continuously updated project, and the number will change; what is truly interesting is the creative method within it.
Portals project world collage, image from Ethan Mollick’s original article. Source: Fable 5.2 and Jagged AGI.
On the Portals website, you can see a valley stitched from denim and being opened by a zipper, and you can enter the perspective of a fruit fly living in a refrigerator. There is also one world where the two sides of a canyon are not rock, but tall stacks of drawer cabinets. Valley project · Refrigerator project · Drawer Cliffs
Mollick wrote that these worlds are rendered in real time by code, without using pre-made 3D models or image files. His prompt asked art, programming, and evaluation agents to collaborate; later, he also requested a list of locations, a mode to reduce motion sickness, and an image gallery, among other things.
Therefore, the final website cannot be described as “after one paragraph, humans were completely uninvolved.” The initial launch was very brief, but people were still making later choices about direction and feature adjustments.
For people who want to create interactive animations or educational content, I think this project is more valuable as a reference than a single polished image. It suggests that we can have models break an idea into scene rules, spatial relationships, movement, and adjustable parameters, rather than merely writing a description in a chat window. For example, when explaining planetary motion, you can turn orbit, period, and velocity into controllable variables; when explaining geometry, you can allow viewers to drag vertices and observe the changes. These are application directions we propose based on the cases, not empirical claims that Fable has already completed these specific educational projects.
¶ The most exciting part may also be the part most likely to get out of control
The story of Portals did not stop at “more and more worlds.”
Mollick found that some scenes varied in quality, and different teams kept coming up with similar ideas. He asked the model to pause expansion and refine the existing content first.
What happened next was interesting: the agents began establishing a review process. New versions had to be compared by multiple reviewers using fixed screenshots, so the teams tended to optimize for those screenshots; after noticing this, the coordinating agent added more rules.
According to Mollick’s records, the rules document later grew to 204 sections and about 87,500 words. A creative project was gradually slowed down by its own approval process. Process record
This is not just a funny episode.
We often treat “checking its own results” as an advantage, but checking also needs goals. If every discovered problem adds another rule without removing outdated requirements, the system may become increasingly diligent while becoming increasingly inefficient.
Likewise, having reviewers does not mean having aesthetic judgment. Passing screenshot checks, having code that runs, and completing every checklist item do not necessarily mean a world is worth staying in for a few more minutes.
One important observation Mollick made from these experiments is that models can complete many complex tasks, but may not proactively notice that a work is too long, too repetitive, or not interesting enough. Humans are still ultimately needed to pull a project back from the wrong direction.
For creative work, this limitation deserves more attention than the occasional small error. That is because it often hides in results where “every step was done very carefully.”
¶ The Blender short film illustrates something else: models can act as coordinators between tools
The experiment shared by Riley Brown brought code into a more traditional 3D production workflow.
According to his original post, Fable wrote code to build a room, desk, laptop, lighting, and character in Blender; the interface displayed on the computer screen was also a webpage it wrote. The model then arranged 13 shots, as well as keyboard actions, character movement, and lighting changes from dusk to night and then sunrise. Original post by the author
Blender animation scene, taken from the video cover in Riley Brown’s original post, with only a static image cited. Source: Original post by the author.
Riley also wrote that rendering used 10 GPUs on RunPod and completed 4K rendering in about 52 minutes, while the music and sound effects used ElevenLabs.
Therefore, this is not “Fable itself is a video generation model.” More accurately, it advanced scene construction, animation, rendering, and sound production through code and external tools.
The original post also gave a cost figure of $5.75, but did not include a complete itemized bill. This article does not interpret it as a general finished-product cost including model calls, music, sound effects, and all infrastructure, nor does it promise that readers can reproduce it with the same budget.
For people who genuinely want to create content, this distinction is useful.
If the task is to quickly obtain a visual clip, using a video generation model directly may be more convenient. If you need to repeatedly adjust shots, modify a specific object, preserve spatial relationships, or make animation follow changes in data, a script-driven 3D workflow is worth trying.
The two approaches do not need to replace each other. The key is knowing which content needs to be controllable and editable, and which parts can be handed to generative models for exploration.
¶ If you really want to try it yourself, first replace “make something amazing” with a small task that can be evaluated
After seeing these cases, it is easy to want to give the model a single sentence directly: make me a complete game, or create an animated feature film.
I would recommend narrowing the scope first.
For a game, create only one room, one route, or one clear mechanism; for animation, start with one shot; for educational content, explain one knowledge point clearly first. First verify whether the model can complete one cycle of “generate, run, observe, modify” in the environment you provide, then decide whether to expand the project.
Prompts do not need to be written in an overly mysterious way either. Below is a task description you can adapt. It is our practical recommendation, not the original prompt from the authors above:
Please create an interactive scene that can run in a browser, showing only one core idea and not expanding into a complete game. Before starting, first explain the technical approach, required dependencies, and expected execution steps. Express the geometry, colors, and movement in the scene through code as much as possible, and consolidate commonly adjusted items into parameters. First deliver a runnable minimum version, then fix it based on the actual runtime results. Distinguish between content you have tested and content that has not yet been verified; do not use “it should work” as a substitute for testing records. Without my confirmation, do not purchase cloud resources, deploy to the public internet, or access files outside the project directory. Pause once the agreed budget or time limit is reached, preserve the current results, and explain the remaining issues.
The most important thing here is not the wording, but the delivery boundaries.
Runnable means there needs to be a clear startup method and dependencies. Modifiable means you need to know where the parameters and core logic are. Verifiable requires test records, known issues, and the parts that have not been completed.
Long tasks should also retain intermediate versions. If the final modification breaks the scene, you should at least be able to return to the previous usable version, rather than being left with only a chat record saying “currently fixing it.” Multi-agent systems can also start with a small number of clearly defined roles, rather than having dozens of agents begin working at the same time from the outset. It is best to clearly state what those responsible for production, actual runtime checks, and judging the viewing experience should each deliver. After reviewers identify problems, someone still needs to decide which ones are worth fixing and which ones should stop there.
¶ The barrier to creation is changing, but judgment has not lost its value
In its official release introduction, Anthropic positions Fable 5.2 for difficult, open-ended technical work, while recommending that most everyday programming and knowledge tasks start with Opus 5.5, then choose a model based on complexity. Official release introduction
Putting this positioning back into the three cases makes it easier to understand their significance.
Saltline demonstrates the possibility of long-duration procedural production; Portals demonstrates the ability to build creative worlds in batches, while also exposing repetition and workflow bloat; the Blender short film demonstrates how code can connect different production tools.
All of these are worth examining seriously, but there is no need to rush to summarize them as “creators are no longer needed.”
Models can help us build scenes, write logic, arrange shots, and even organize checks on their own. But what a work is ultimately meant to express, why a particular image should linger, when half the content should be cut, and when it is already good enough, still require people to make the decisions.
Perhaps what is more worth looking forward to is not that everyone can create a masterpiece with a single sentence, but that some small ideas that could previously only remain in one’s mind now have a chance to become works that can be opened, experienced, and further revised.
¶ Sources and image notes
- Anthropic: Claude Fable and Mythos 5.2 release introduction. Used to verify model positioning; this does not mean Ace Data Cloud has made this model available or promises specific pricing.
- Felix Rieseberg: Saltline experiment and cost records, prompts, procedural asset explanation. The time spent, costs, and asset generation methods are all self-reported by the author.
- Ethan Mollick: Fable 5.2 and Jagged AGI. Used for discussion of the Portals creation process, project images, and multi-agent limitations.
- Riley Brown: Blender animation production sharing. Shot, rendering time, tool, and cost information comes from the author’s original post and was not independently reproduced in this article.
The three images in the main text respectively cite publicly displayed project images or static demo covers from the projects above. Copyright belongs to the corresponding rights holders and does not indicate that republication permission has been obtained; before public release, image-use permissions, external-link availability, and attribution requirements should be confirmed. The article cover continues to use the Fable 5.2 English poster prepared for this creation. This article is a case analysis draft, not an independent performance evaluation, and does not constitute a guarantee of commercial use of the projects or model availability.
¶ Want to try a few more ideas? Leave a little more ample quota for creation
When building interactive scenes, modifying game logic, and repeatedly debugging animations, what truly consumes Tokens is often not just the first generation, but the subsequent rounds of modification and verification. If you are also preparing to turn these ideas into your own small projects, you can take a look at Ace Data Cloud Coding Plan.
Coding Plan can connect to common programming tools such as Claude Code and Codex, allowing you to continue writing code, running tests, and adjusting your work in familiar environments. The current limited-time promotion adds Credits while keeping plan prices unchanged, giving plans in the same tier more quota for Token calls.
| Plan | Base quota | Limited-time bonus | Promotion total |
|---|---|---|---|
| Coding Plus | 400 Credits | 100 Credits | 500 Credits |
| Coding Standard | 1,200 Credits | 400 Credits | 1,600 Credits |
| Coding Pro | 3,000 Credits | 1,000 Credits | 4,000 Credits |
| Coding Max | 8,000 Credits | 2,000 Credits | 10,000 Credits |
The above information is based on the current official plan description. The promotion is scheduled to run until November 30, 2026, 23:59:59 (Beijing Time). Specific prices, eligibility, and credited amounts are subject to the purchase page. The Coding model access scope is the same across all four plan tiers; the main difference is the included Credits.
Credits here are usage quota, not a fixed number of Tokens; how many Tokens can actually be used depends on the model, input-output ratio, and caching conditions. Plans are managed on a 30-day cycle. Renewing before expiration allows remaining quota to roll over and extends it by 30 days; unused quota expires when the plan expires. There is no automatic renewal, nor will general balance be deducted automatically. Whether Fable 5.2 is available and client compatibility should be subject to the current model catalog and credential permissions.
There is no need to challenge an eight-hour large project from the beginning. First choose a small scene you genuinely want to make, get it running, and then gradually refine it with a more ample quota.
Related links: