Pro User
  • All of Microsoft
  • My Role
    • All in My Role
    • Pro User
    • Administrator
  • Focus
    • All in Focus
    • Microsoft Build 2026
    • Microsoft Copilot
    • All about AI
    • M365 Admin
    • What's Hot
    • M365 Release
Timespan
explore our new search
Claude Fable 5.2: what its long-build demos show
All about AI

Claude Fable 5.2: what its long-build demos show

by HubSite 365 about Matthew Berman

Artificial Intelligence (AI), Open Source, Generative Art, AI Art, Futurism, ChatGPT, Large Language Models (LLM), Machine Learning, Technology, Coding, Tutorials, AI News, and more

Claude Fable 5.2 is put to work on games, simulations, and creative software, with build times and estimated token costs shown.

Key insights

  • The demonstrated projects range from browser-based spreadsheet software to games and 3D scenes.
  • Several builds ran for many hours and used billions of tokens, according to on-screen estimates.
  • The water-balloon simulation was built as a single HTML file using JavaScript, CSS, and WebGL2.
  • The demonstrations include failures and visible flaws as well as successful results.
  • The transcript does not establish model access, licensing, or commercial availability.

Claude Fable 5.2 is presented as a model for building substantial software and creative projects from high-level prompts, rather than just generating short code snippets. This matters to developers, makers, and technical teams assessing whether AI can help with complex, iterative work. Matthew Berman demonstrates the model through games, simulations, and software projects, while reporting the time and token estimates shown for some builds.

What's new

The practical focus of these demonstrations is the scale of the requested work: a playable game level, a spreadsheet clone, a video editor, and 3D environments. The examples suggest a workflow in which the model is given a broad project brief and then allowed to produce and refine a larger deliverable. They do not establish that every project was made in one short exchange; several builds ran for many hours.

The demonstrations include browser-based and desktop work. One simulation used a single HTML file with JavaScript, HTML, CSS, and WebGL2, with the prompt explicitly excluding external libraries. A separate video editor was described as a local Windows PC application, while the spreadsheet clone ran in a browser.

There are also examples beyond conventional app development, including motion graphics, a house designed in Blender, a 3D-printed tower design, and a populated European town simulation. This range is useful for readers deciding whether to test a model on a particular kind of work. It is not evidence that all these outputs are production-ready or that the same results will follow from a different prompt or environment.

Who it is for and what you need

The examples will interest software developers, game makers, designers, and technical teams exploring AI-assisted project work. They show that the builder supplied project descriptions and, in some cases, constraints such as a target engine, a printer and filament specification, or a requirement to avoid external web libraries. Those details matter because a broad prompt alone does not describe the full setup.

The transcript does not state which plan, account, interface, or API configuration was used to access Fable 5.2. It also does not establish licensing, general availability, regional availability, or whether the named model can be selected by other users. The examples should therefore be read as demonstrations of one person's testing, not as an access guide.

Some outputs required substantial compute time and token use, according to cost and usage figures displayed during the demonstrations. The video reports estimates for API-equivalent costs, not a confirmed price paid or a universal cost for reproducing a project. Actual requirements and results for a similar project are not established by these examples.

How it works

The recurring approach is to describe the target outcome, add constraints that matter, and give the model time to build. In the game examples, prompts named the type of game, requested playable levels, and specified qualities such as varied or complex stages. One game prompt also had a separate instruction to add multiplayer.

  1. Describe the project and its intended outcome. For example, the water-balloon prompt asked for a ray-tracing simulation of a bullet passing through a water-filled balloon.
  2. Set constraints and desired interactions. The simulation brief asked for animation freeze and camera controls, plus sliders for speed, size, lighting, gravity, and other parameters.
  3. Let the model generate and iterate on the project. The Gears of War-style level was run in an effort mode described as “Ultra Code,” and the build was still running during the demonstration.
  4. Inspect the output and test it. Berman played the games and interacted with the spreadsheet and simulation, and also pointed out issues such as awkward movement in the game and a tree in the house's driveway.

The examples show why testing is part of the process: a result can be impressive while still containing defects. The spreadsheet demo included formulas and a pivot table, while the game demos included playable controls and multiplayer. These are the publisher's observations of specific builds, not independent assessments of feature completeness.

Limitations and open questions

The demonstrations are selected examples, and their quality varies. The Roadster-event recreation is described by Berman as a weak result, and other scenes have small visible flaws. That contrast is important: a high-level request does not guarantee accurate output, even within the same set of experiments.

Build time and token figures also complicate the idea that complex software can be produced quickly or cheaply. The video gives estimates running from tens of millions of tokens for a small simulation to billions for larger projects, and reports long build times for several of them. Those figures are tied to the showcased builds and should not be treated as benchmarks for every user or project.

The material does not verify the model's benchmark claims independently, provide a reproducible testing method, or confirm the legal or commercial status of clones based on existing games and software. It also does not explain access requirements, deployment, security review, or how to maintain these projects. Teams considering similar work should validate outputs and costs in their own environment before relying on them.

Sources

Frequently asked questions

What kinds of projects does Claude Fable 5.2 build in these demonstrations?

The examples include games, a browser-based spreadsheet clone, a local video editor, simulations, motion graphics, and 3D scenes. They are demonstrations of specific builds, not guarantees for other projects.

How long do the Fable 5.2 projects take to build?

The video reports times ranging from under an hour for some smaller examples to roughly 70 hours for larger projects. These are figures for the demonstrated builds, not standard completion times.

How much does it cost to use Claude Fable 5.2?

The demonstration shows estimated API-equivalent costs for individual builds, but it does not establish a general price or actual amount paid. Access and pricing details are not stated in the transcript.

Can anyone access Claude Fable 5.2?

The source material does not state access requirements, licensing, or regional availability. It therefore does not confirm whether the model is generally available.