Claude Fable 5.2 built a browser shooter in 8 hours for about $550

Leaving AI to build a prototype overnight is a tempting idea—until the bill arrives in the morning. The story of browser shooter Saltline shows what to watch for in advance: the agent needs to receive the task context many times, and that incoming stream can cost more than the code it writes. For a team experimenting with autonomous development, this is a concrete budget item.

According to Anthropic engineer Felix Rieseberg, Claude Fable 5.2 created Saltline in about eight hours from a single initial prompt, with no human feedback during the run. The reported cost at API rates was about $550. The creator also reported roughly 2.7 million output tokens and 445 million input tokens, a substantial share of which were cached. Links to the creator's post and the game accompany the original report; we do not have a detailed, verified breakdown of the costs.

What eight hours produced

Saltline is a browser-based first-person shooter with a single mission. According to the experiment's description, the model created the code, models, sounds and textures. It is an interesting example of a task that requires several components to work together: visuals, controls, gameplay and sound all need to function as a whole.

The headline “Call of Duty for $550” sets expectations too high. One mission does not establish the cost of a large game with a campaign, multiplayer modes, support for different devices and extensive testing. It is more useful to view this experiment as an attempt to produce a limited game prototype in one extended run.

Another point: one prompt does not mean one model response. Even without human feedback, an agent can take many steps, call tools, receive results and keep working. The reported figures do not reveal which checks were performed during this run. Before applying the result to your own project, it makes sense to start with a small trial run.

Why input tokens outnumbered output tokens by 165 to one

Imagine an agent adding a door to the game. It receives the task and the relevant code. After making a change, it receives a tool result, then fixes an error or moves on to the next object. The next request again includes some of the previous material alongside new data. Over a long session, the volume of billable input adds up.

Dividing 445 million by 2.7 million gives roughly 165 input tokens for every output token. This is the ratio of the total volumes across the run. It does not prove that the model received the entire project at every step or that the context kept growing: drawing that conclusion would require a request log.

Caching makes repeated portions of the input cheaper to process. It does not automatically give the model long-term memory: developers still need to manage which materials go into each request. The practical value of caching is especially clear when an agent repeatedly works with the same instructions and large chunks of context.

What the numbers actually tell us

Anthropic lists base rates for Fable 5.2 of $8 per million input tokens and $40 per million output tokens. At those rates, 2.7 million output tokens cost $108. Charging all 445 million input tokens at the base rate would add another $3560. That totals $3668, roughly 6.7 times the reported $550.

But this is a hypothetical calculation without caching, not a reconstruction of the experiment's bill. If we accept the $550 total and the $108 output cost, that leaves about $442 for input, or an average of roughly $0.99 per million tokens. The exact cache hit rate cannot be derived from this without a breakdown of cache reads, cache writes and the rates applied.

Before a run like this, developers should enable tracking for these cost categories and set a spending limit. Product managers should define completion criteria in advance: does the mission launch, can it be completed, and which devices does it run on? For founders, the next useful step is to repeat a limited task several times and compare the cost of an accepted result. One successful run demonstrates what is possible; a product budget also requires predictability.