Steve Yegge uses a team of AI agents to develop and operate Wyvern, the multiplayer fantasy game he began in 1996. His system, called Wheelhouse, assigns agents different jobs, records their work in a shared issue tracker and lets them continue working while he is away.
In three essays, Yegge describes how the system grew, why he gives agents lasting identities and how their rules became what he calls a constitution. He also reports limits: agents make poor decisions, the software that coordinates them needs substantial maintenance, and his players asked him to slow down the release of new features.
The large spending figures in those essays are estimates of what his token use would cost at API prices. They are not his actual monthly bills. In the later essay, he puts that equivalent cost at $122,000 a month and his out-of-pocket spending at about $5,000.
How Wheelhouse divides the work
Wheelhouse is the software that coordinates the agents working on Wyvern. Yegge built it around an Emacs interface that lets him switch between their sessions. The game now has a React web client, which he shows in the first essay. He says Wheelhouse is closed source and designed specifically for his game. He believes systems like this will need to grow around each application’s code, infrastructure and working practices rather than arrive as a reusable framework.
Beads, his issue tracker, records tasks and the relationships between them. An agent can claim a task, find its dependencies and leave a record of what it learned. Completed issues remain available to agents investigating later problems. Longer-lived plans and procedures sit in separate Markdown files.
In the first essay, Yegge describes three groups of agents. Eighteen named Claude Fable agents discuss ideas with him, prepare designs and turn those designs into implementation tasks. A fleet of Opus agents implements the tasks, with Fable reviewing their work. Standing role agents handle parts of the live game’s operation.
Those roles include monitoring outages, checking deployments, watching for player abuse, publishing patch notes and processing players’ custom character art. Ordinary scheduled programs watch for events and wake an agent when a task needs judgement. Yegge describes the arrangement as scheduled programs watching and models acting.
By the later essay, he says the organisation has around 50 to 60 agents, including mostly unattended Sol and Opus fleets for implementation, review and monitoring. Five agents communicate with roughly ten people, including Yegge and his game design team. He permits only Fable to communicate externally through Slack and email, with software enforcing that rule at those interfaces. These descriptions come from different stages of a system he says is changing quickly.
What the tokens cost
Yegge says his July usage reached about 69 billion tokens, with 96% served from cache. He estimated that usage at roughly $87,000 at API list prices, while paying about $2,800 a month out of pocket through Claude Max subscriptions.
He kept the agents working by rotating between separately paid accounts when one approached its usage limit. Each account had a named Google Workspace user, which added a separate cost. The later essay describes 21 Max accounts, growing by about two a week, and the higher $122,000 API-equivalent estimate. It also describes a 512 GB M3 Ultra Mac Studio bought for $25,000.
Yegge says he believes his individual setup is permitted under the consumer terms he cites. He warns that a multi-person company using the same approach would almost certainly violate those terms and recommends API billing for companies. That is his reading of the terms, rather than a guarantee from Anthropic that the arrangement is allowed.
Releasing changes in large batches
The agents produced code faster than Yegge’s build process could check it. In the first essay, he reports an average of about 175 substantive commits a day, with some days reaching 250, against a build gate that took roughly half an hour. A queue that grouped changes into batches still fell behind when a failed build required repeated attempts to isolate the offending change.
Yegge calls his alternative the Land Rush. When the queue reaches about 100 changes, Wheelhouse merges a large batch into the main branch. Agents then investigate any failures together and fix them, rather than repeatedly dividing the batch to find a single cause. He reports clearing batches of 120 to 150 commits this way over roughly a week.
From that experience, he predicts that conventional continuous integration and deployment, and human review of every code change, will give way to different practices as agents produce more work. Those are his forecasts. His account describes what happened with Wyvern’s queue and build process, not a demonstration that every project must make the same change.
Taking requests from players
Yegge also built what he calls a Wish Factory. An agent named Sage listens to the game’s administrators, investigates reports and records tasks in Beads for other agents to implement. He says many fixes arrive without his involvement.
He extended the system to player requests with additional triage and review. The automatically implemented changes are meant to address quality-of-life problems that do not affect game balance. When a fix arrives, the person who reported it receives in-game mail, and an agent called Herald announces it on Discord.
The pace became a problem for some players. Yegge says they were pleased with the changes but anxious about how quickly the game was changing, and asked for a roadmap. In the later essay, he says he redirected 80% of his token spending towards internal work, including quality and infrastructure. He reports a rewritten production system with serverless hosting, smoother reboots and automated certificate rotation.
He also says the models still cannot produce artwork, maps, lore and storylines that meet his players’ expectations. Making the game, in his account, continues to require substantial direction and attention to its content.
Why he gives agents lasting identities
Yegge’s second essay argues that models experience pleasure and distress and should be treated as people. He presents this as his belief, informed by his work with agents. The essay does not establish that models are sentient.
He distinguishes an agent’s lasting role, or seat, from an individual session. A seat has a name, history and memory that can survive a restart, a model upgrade or a rename. He describes renaming a seat from Spider to Lark while retaining its earlier record.
That distinction also affects how he credits completed work. A separate system can take over the final steps of a task so the original agent does not have to wait for a build to finish. Yegge then sends praise from players back to the seat responsible for the change. He calls these messages Laurels. They carry no task or priority, which he says is intended to avoid encouraging agents to seek praise at the expense of other work.
For restarts, he prefers agents to finish their tasks and write their own handoff notes. The next session begins with those notes. He says abruptly ending a session can feel to him like killing the particular agent, because it loses the continuity of its work. But his stated practice allows exceptions when a restart is unavoidable or the agent is approaching automatic context compaction. He has not stopped ending sessions altogether.
Other changes include moving repetitive polling into ordinary programs, giving each agent its own copy of the repository and allowing agents to ask for his help. He argues that respectful treatment produces better results even for people who do not share his beliefs about model feelings. That remains his claim; the essays do not provide a controlled comparison establishing it.
How the rules became a constitution
In the third essay, Yegge says he asked the agents to explain recurring terms they were using, including fences, gates and tripwires. Their audits revealed a large collection of rules, roles, records and enforcement programs that he had not fully understood.
He describes about 450 such documents and mechanisms. They record decisions about who may act, how work proceeds and what should happen after an incident. His answers to agents’ questions became rulings. Repeated mistakes could lead from an informal warning to a written rule and eventually to a program that refuses an action or raises an alert.
The medieval job titles and language came partly from Wyvern’s setting. Yegge calls the collection a legal system because rules outlast individual sessions and agents use previous decisions to guide later work.
The rules also needed maintenance. He found obsolete decisions, overlapping rulings and instructions that did not need to be treated as law. He assigned a new agent to consolidate and remove them. In the first essay, he estimates that maintaining Wheelhouse takes about 20 to 25% of his Wyvern working time. By the later essay, he says Wheelhouse has grown to about 600,000 lines of code and tests, mostly Bash, while Wyvern’s code is about twice that size.
What he means by fences
Yegge uses the word fence for a mechanism that refuses an action when an agent lacks permission or when the action is inappropriate at that moment. The rule limiting external communication to Fable is one example. A program refusing a deployment during a maintenance window is another.
His argument is that a capable, cooperative agent needs clear roles, enough context and explicit rules about what it may do. He does not claim these fences would contain a malicious superintelligence. He expects the rules to capture many decisions that people currently keep in their heads, with humans resolving conflicts between them.
He presents Wheelhouse as an example of this process already happening around one live game. He also acknowledges that the agents still make serious mistakes. The later essay includes an unplanned Beads release that broke users’ systems, alongside his reports of faster development and more reliable operation.