A Swarm of AI Agents Builds the Game Spawn, and Tokens Cost $3 Million a Month

Spawn is a multiplayer game with voxel 3D graphics where players change the world with text requests. The player tells a built-in AI assistant named Savvy what they want to add, and she builds it into the world. Developer Simon Willison tried the game from his phone and within a few minutes had a castle, then a dragon, and then flew around the castle on its back.

The more interesting part, according to founder Jacob Sansbury, is that a swarm of agents running on the Fable model develops the game itself. Humans are barely involved in the process, and tokens cost more than $3 million a month. Tokens here are the unit of payment for a language model's work.

Sansbury says the team spends 30 times more on them than on salaries. By rough math, that puts the team's payroll at around $100 thousand a month.

Hourly deploys and bugs the game files itself

The agents change live code directly and push fixes to production (that is, to players) once an hour. They read errors, bug reports, and metrics on their own. About 60% of tasks start from one of four sources:

• a production error; • a bug report from Savvy; • a strange entry in the logs; • a feature request.

Savvy files bugs herself, both when a player ran into a problem and when she noticed a failure from inside the game. The report goes to an agent, which picks one of three outcomes: it is a real bug and needs fixing; it will not be fixed; or it is intended behavior that requires a decision from humans. Most often the result is a fix, and the player sees it within an hour, along with a message in the same chat.

This pace holds only as long as the cycle never stops. At Spawn, an hour without a deploy counts as a SEV-0, the highest-severity incident level. Accumulating fixes prolong existing problems and slow down feedback. There is also an argument rooted in how the models work. An agent can hold only a few hours of work in its head, so frequent small deploys help it stay coherent.

30-second rollbacks and planned breakage

To keep that speed from turning into chaos, the team built a fast rollback. A broken change is reverted in 30 seconds, exactly where it broke, and nothing else is touched. When a monitor or a log alert fires, the system launches or wakes the agent responsible for that incident. The team tests recovery paths in practice: it breaks the product on purpose and watches whether the agents cope.

Which model could handle it, and which could not

According to Sansbury, Fable 5, and then 5.1, made this level of autonomy possible. Opus 5.5 falls short for their tasks. There is a separate story about GPT-6 Astra. It was asked to apply fixes after a security review. The result was that all features were switched off and marked to be re-enabled once the fixes were finished. In Sansbury's words, the model "made the unsafe thing safe by simply turning it off." Technically there are no vulnerabilities, but there is no product either.

Simon Willison notes that his eyebrows went up more than once while reading. He doubts the approach suits software where mistakes are costly. For a game, he says, the setup works surprisingly well. A game is a good proving ground: a failure threatens neither money nor health, and the limits of coding agents get tested quickly.

What engineers can take from this

The $3 million figure and the 30x multiple over salaries are so far only the founder's own account, with no independent confirmation. But the set of practices is concrete and portable:

• Short deploys as a way to keep the agent in context. Small changes fit within the few hours an agent can hold in mind. • Fast, surgical rollback. A 30-second rollback makes hourly deploys acceptable. • Recovery drills. Deliberate breakage verifies that the agents who own an incident can actually bring the service back up. • Bug triage by an agent. Three outcomes (fix, don't fix, needs a human decision) leave people with only questions of intent. • Testing models on your own tasks. The same security task led Fable to a working product and Astra to a disabled one.

For business, the takeaway is direct: with this approach, the main expense shifts from paying people to paying for compute. The setup works where the cost of a mistake is low and rollback is cheap. For banks and healthcare, as Willison rightly points out, it is unlikely to transfer in this form.