I’ve recently received a request to put Meta’s new Muse Spark 1.1 model through the agentic game creation test, to see how it would perform. If I am remembering right, Muse Spark 1.1 was released recently, in early July.
Meta’s blog post states “Muse Spark 1.1 is a multimodal reasoning model built for agentic tasks, with major gains in tool and computer use, coding, and multimodal understanding.”
Among other things (coding for one), Muse Spark 1.1 was trained specifically for orchestration and delegation to sub-agents. The blog states: “[Muse Spark 1.1] tackles complex projects significantly faster than Muse Spark, as it is trained to orchestrate multi-agent systems to optimize end-to-end latency. As the main agent, it can gather context, make a plan, and delegate execution across parallel subagents. As a subagent, it adheres to its job, understands available tools, and knows when to escalate back to the main agent.”
The blog post also states that “[Muse Spark 1.1] zero-shot generalizes to new native tools, MCP servers, and custom skills.”
Did someone say zero-shot? Have I got a prompt for you, Muse Spark 1.1…
A reminder, my one-shot autonomous agent game generation prompt is an offshoot of my older, explicit orchestrator/sub-agent framework, and a model that can do the orchestration itself and delegate to sub-agents should do well at the task.
So, I tried it out…and it did quite well! Using Muse Spark 1.1 served from Open Router, and in the Visual Studio Code GitHub Copilot plugin, it designed, coded, and tested a nice and competent game. Its token cost was among the more reasonable, only about $25, significantly less than Opus and Fable, and more on par with Grok 4.5.
An interesting side note: it spent a significant amount of time and tokens on what seemed to be the initial implementation and feature design; however, once the design was set, it seemed to speed-run the implementation of the 25 new features. My guess is that the features were all being orchestrated and implemented in parallel (when possible) by subagents the LLM spooled up; however, this is just a guess.
Another side note: this was probably the most context heavy run of all the models. Most of the models finished the task with a context in the mid to high 200K token range; Muse Spark 1.1 finished with a context of 437K tokens, significantly more than most of the other models. I’d be interested in looking into why this might be.
All in all, for this autonomous workload, I would put Muse Spark 1.1 in the same (subjective) neighborhood as Grok 4.5, GPT-5.5 and GPT-5.6 Sol, Sonnet 5, and Kimi K3.
As always, the controls are <c> to insert your coin, <1> to start a 1 player game, arrow keys for turning and thrusting, <space> to fire, and <h> for hyperspace.
Last month, Sakana AI released their Fugu LLM, to headlines such as ‘Sakana AI launches Fugu Ultra and its orchestration model matches Fable and Mythos without training a single frontier model’ and ‘Sakana Fugu Ultra promises to deliver “the very best frontier-level performance” by… using frontier AI models.’ YouTube was full of videos asking ‘Is Fugu better than Fable?’
Example of headlines on YouTube when Fugu was released.
Early coverage framed it as “one model to command them all,” a way to match Anthropic’s Fable/Mythos-level results through collective intelligence rather than a single giant model, while also reducing dependence on any one provider or export-control risk. In short: multi-agent coordination packaged as a single model interface.
What may have gotten lost in the hype is what Fugu actually IS. Fugu is a family of “learned orchestrator models”. It is trained as a language model whose job is to read a query and dynamically construct an agentic scaffold (selecting workers, assigning roles, verifying outputs, synthesizing the answer) over a pool of frontier models. The user interacts with it as if it were a single model, but the heavy lifting is done by the orchestrated team.
You talk to it like any other model (OpenAI-compatible API), but under the hood it reads the query and dynamically builds the scaffold and pool of workers, deciding which models to call, what roles to give them, how to verify intermediate results, and when to synthesize the final answer. There are two variants:
Fugu – prioritizes everyday usability and lower latency; it often routes to a single strong worker.
Fugu-Ultra – prioritizes maximum quality on hard, multi-step problems and can spin up richer multi-agent workflows with isolation and shared memory.
Of course, I had to add it to my autonomous agent game creation test.
I tried out “Ultra” because I didn’t know what to expect, and I wanted to give Fugu the greatest chance of creating a playable game.
Some results:
Fugu Ultra ran for a LONG time, compared to even the most powerful “uni-models”. I didn’t expect this, and so I didn’t think to time the run, but it was probably an hour or more. This in comparison to strict Fable or Opus runs (~45-50 minutes) and Grok 4.5 (~20 minutes). Note that Fugu Ultra is designed to spin up multi-agent workflows to solve the problem, and can easily spin up multiple ‘heavy lift’ models that may take a long time to synchronize and complete the task.
Fugu Ultra is EXPENSIVE, somewhere in the $70-$80 range to design and implement the prompted game in my test, similar to strict Fable or Opus. Again, it was likely spinning up expensive models to do a lot of the work. For some reason I had not expected this (duh!), and ended up feeding OpenRouter multiple $20 token buys to get the job done.
Fugu Ultra is INTERESTING in what aesthetics and features it designed. The look and the play of the game it produced has a distinct style, so much so that the style can distract from gameplay; however, I like it in that its style is unique vs. the other LLMs that I’ve tested. For example, it chose to use what looks like swirling confetti for its explosions instead of a more vector graphics look!
What’s really interesting to me is, I don’t know what LLM Fugu outsourced the aesthetics and game design decisions to, and it’s a really unique style. I’m not sure that a second run would recreate that same style. (I’d try a second run as an experiment if the token cost wasn’t so high)
The runable (browser based) version of the Fugu Ultra game (as well as the games from the open model LLMs) can be found here (arrow keys to turn and thrust, space to fire, h for hyperspace):
A friend of mine recently asked me to test my current autonomous LLM game generation pipeline with a few of the latest open weight models. I used Visual Studio Code GitHub Copilot and it’s “Bring Your Own Key” capability to hook it up to the various models on my Open Router account.
I was a bit underwhelmed by the models I tested (DeepSeek 4 Pro, GLM 5.2, and Kimi K 2.7-code), at least for my game generation prompt. It should be noted that, just because one run on my workload resulted in underwhelming results, that doesn’t mean that these models wouldn’t do well on someone else’s coding workload, or even on another run.
Interestingly, just as I was wrapping up my testing, Moonshot AI released Kimi K-3. The drop of K-3 instantly generated a lot of hype, and it was being compared to Opus and Fable on various social media (especially YouTube). I wanted to test it out on my own workload.
Easier said than done, as when I submitted my prompt to Kimi K3 through OpenRouter, the prompt would “bounce”, with a message that seemed to be indicating that K3 was being throttled due to excessive demand, and indicating that I should “try again”. After trying at various hours throughout the day and evening, I resigned myself to waiting until the initial demand had dissipated before trying agin.
Rate limit message from Kimi-K3
Luckily the next day I was able to run the prompt, and lo and behold Kimi K3 generated a nice, playable game autonomously. The game it generated is comparable to ones generated by Fable, Opus 4.8, Sonnet 5, Grok 4.5, and GPT-5.6 Terra and Sol. It didn’t seem to be particular speedy, but cost-wise it produced the finished game for ~$13, as opposed to ~$50-$80 for the Anthropic models.
From my tests, I would rank Kimi K-3 below Fable, Opus 4.8, and Grok 4.5, but above Sonnet 5 and GPT-5.6 Sol and Terra, which is quite amazing. In fact, the rise in ability of Grok 4.5 and Kimi K-3 in these types of tests is truly amazing. A reminder, the prompt has the agent implement AND design the features, so I am not only testing coding, but the “aesthetic” ability of the models.
Run-able versions of the open weight models’ generated games on a new website.
The run-able versions of the games generated by the open weight models can be found here:
I still like the design chops of Fable, but I can’t justify its cost for a project like this. I’ve run some tests with using Fable for explicit game design and project scaffolding, and then switching to Grok 4.5, GPT-5.6, or Sonnet 5 for the code implementation and testing phases, all in the same context. The initial results are encouraging, and I’ll post another blog post soon with the details.
Things have been moving fast. SpaceXAI dropped Grok 4.5 and OpenAI released GPT-5.6 Sol, Terra, and Luna. For me the real surprise was Grok. I’d been using it mostly for research and had never reached for it on coding work — Claude Sonnet had been my default for that. My quick-and-dirty way of checking whether a model was actually useful was a one-shot prompt that asked it to build a browser-based clone of the 1979 vector Asteroids game.
I picked that old game for a few reasons that still hold up. It touches on a lot of what makes games interesting: graphics, basic physics, sound, scoring, projectiles, collisions, and even a little destruction effect when the ship blows up. At the same time it’s simple enough to describe without locking the model into every last detail, so you can see what it decides on its own for the ship, rocks, and UFO. JavaScript is one of the languages these models have seen the most of, and the whole thing runs in any browser with zero install.
Back in March 2026 I ran Grok 4.1 through that same prompt and it was pretty rough. Asteroids came out warped, the ship thrust sideways instead of forward, you’d hear the shot sound but nothing actually appeared on screen. It was one of the weaker results I got at the time.
Grok 4.2 AutoGPT-5.3 Codex
Around then I started putting together a multi-agent setup — an orchestrator that would hand work to a planner, then a coder, then an auditor, and so on — so the models could build a small game feature by feature.
Before I had the whole thing tuned the way I wanted, the newer models (Grok 4.6 and GPT-5.5 among them) got noticeably better at just working through things on their own. They could plan, implement, test, and even come up with the next feature without constant hand-holding. I ended up shelving the orchestrated pipeline for a while.
The other big jump has been in vision. These models are now decent at looking at a screenshot of the game and checking whether what they think is happening actually matches what’s on screen. That self-verification step removes a lot of the back-and-forth that used to require a human in the loop.
To keep testing meaningful I put together a tougher prompt. On top of just building Asteroids, the new version asks the model to:
Follow SOLID and KISS/YAGNI principles where they make sense.
Use test-driven development for the pieces where it’s practical.
Avoid the usual LLM shortcuts when it comes to testing.
Wire up Playwright so it can actually verify graphics, physics, and on-screen behavior.
Support custom game modes (single-step mode has been especially useful for debugging).
Come up with 25 new features that feel fun and replayable, then plan, build, test, and commit each one to git in sequence.
Some of the games available on the game examples web page, generated by LLMs.
I’ve put the playable game results from the latest runs here, in a game examples web page:
Example of a game designed, generated, and tested by an LLM
Every game is a full browser version of Asteroids with 25 new features the model designed itself. I’ve also included two earlier builds (the ones with the gold background) that only had 20 features. I liked the feel of those two enough that I wanted to show what was possible with this single prompt pipeline.
Lastly, I’ve included the prompt used to make these games at the bottom of the game examples web page. Feel free to use it as inspiration for your own prompts.
One practical note: running these long agentic loops eats tokens, especially once the context grows. Grok 4.5 and GPT-5.6 Terra Medium were both quick — around 15-20 minutes per game — and Grok barely touched my monthly token budget. Claude Sonnet 5 took an hour and forty minutes and ran up $112 in tokens. Opus 4.8 and Fable sat in the middle at about 45 minutes and roughly $60 each.
The frontier models have reached the point where they can keep iterating on a messy, ambiguous problem until it’s done. The older and smaller models still tend to stop after the first pass and wait for you to say “go do the next feature.” I’m planning to run a side-by-side on the single-agent approach versus the older orchestrator setup to see how they compare on speed, cost, and context size.
Giving the model a way to look at its own output visually has been one of the bigger practical wins. The more ways you can let it check its own work, the fewer obvious mistakes make it into the final build. The long-term interesting question is whether these models can eventually judge whether a feature or a whole game actually fun. That’s going to take more experimentation.
I was able to test Anthropic’s newest welterweight class model, Sonnet 5, on the one-shot “make me a game” agentic prompt I had developed in my last post. I’ll go into more detail about the prompt after the Independence Day holiday,.
Briefly, the prompt instructs a single agent in a single context to create a basic Asteroids game, then come up with 20 fun new features all on its own, and iterate on them one by one, using Playwright autonomously to take screen captures of the game to validate the graphics.
I’ll analyze the pros and cons of the one-shot prompt versus the much more structured feature orchestrator agentic pipeline I had been using before the (on again, off again) release of Claude Fable. I’ll also discuss some interesting observations and challenges I noted while watching Sonnet 5 iterate on the features, including intuitions on what fully agentic LLM pipelines may struggle with in the future, and the high token and money costs of fully agentic flows such as this one.
But for now, I present you Claude Sonnet 5’s solution.
The attract screenBasic GameplayBonus modes designed by the LLM.More bonus modes designed by the LLM.
We’ve all heard that AI is going to eliminate our jobs, especially those in “knowledge work”, and more specifically those of us in software engineering.
I got to thinking, how real is the possibility? I only started to use LLMs for coding projects in November 2025, seven scant months ago. In that time, I’ve seen LLM based coding tools go from barely able to one-shot code an old 1979 arcade game (Asteroids ’79) to being able to pair code (with myself) sophisticated tools, back-ends, and game clients.
Still, I wondered, how close are we to having LLM based tools design, code, and test a simple, yet fun game all on its own; a completely autonomous game generation system.
I’ve spent the past 3 months of my off-work time working on such a system.
It is glorious. I have fully autonomous agentic pipelines, complete with a state machine “orchestrator”, orchestrating development agents such as a “planner”, a “coder”, and adversarial “code auditor” and “test auditor” agents. These separate agents minimize common LLM coding mistakes, emphasize DRY, SOLID, and YAGNI, and TDD principles, and minimize well-known LLM test cheating patterns.
I also enforce rigid policies on context separation, in order to keep each agent working on clear and concise tasks to minimize task drift. The system uses successive development, having the orchestrator task out each feature in sequence, so that the agents can implement each feature as a step-wise addition to the previous features, in the hopes of keeping the agents focused one feature at a time.
There are also a lot more blah blah blah principles and features of the pipeline, rooted in LLM research and simple blood and sweat of trial and error.
In a word, it is quite fabulous. And it works.
To a point.
I still have to generate the feature specs “offline” and paste them into the pipeline, by prompting a web based chatbot of the LLM model, as feature generation wasn’t implemented in my pipeline. And each “run” of a feature, including the planning->coding->auditing flow often gets stuck in a loop, with the auditors screaming that “just one more thing” needs to be fixed, with the coder dutifully implementing each revision, burning token after token. And sometimes the agents “drift” or even go completely off the rails, examining each other’s configuration files, and even each other’s prompts, in order to be “helpful” despite prompts telling them not to.
A reminder, a paraphrase of Captain Barbosa from “Pirates of the Caribbean” : “Prompts are more, what you’d call ‘guidelines’ than actual rules. Welcome aboard the Black Pearl Miss turner.”
Life is good, and although I still have a way to go to get Github Copilot, Claude Code, or OpenAI Codex to design, build, and test a simple game from beginning to end, I’ve learned a lot about designing, implementing, and testing these fully autonomous agentic pipelines.
However…
An interesting thing happened during the past month or two.
The LLM harnesses got better. And the LLM models got more capable. Much more capable. Actually, much MUCH more capable.
I saw it first with GPT 5.5, with its ability to code, stay on task, and use its multi-modal ‘vision’ capabilities. All of a sudden, I had a model that wouldn’t often drift off task, that was really good at coding, and that could be tasked with checking its work VISUALLY. I started having the agents use Playwright (for web based games) and AppGhost (my own custom app for Mac and Windows games) to have the agent visually verify what was on the screen; no more arguments with the agent about if the spaceship was oriented on the screen correctly, or why the entire terrain mesh was outside the 3D rendering area.
With the later versions of Opus and now Fable, I also noticed that the agents could now iterate on their own; no longer did “one shot” equate to “make it all at once”…it could now mean “do these operations once for each feature for these ten features”, and reasonably expect the agent to stay on task until the last feature was planned, coded, and tested fully.
In other words, they could now, on their own, manage the whole pipeline I had spent months architecting and verifying, in one prompt, in one messy but somehow effective context…and in a way that produced a better game implementation, in far less times, with far fewer tokens.
My characterization of “better game implementation” is based on several runs of my old pipeline using various GPT and Claude models (mostly Claude Sonnet and earlier versions of Opus), and one run of the “one-shot” pipeline using Fable, before it was taken off-line.
As far as “far less time”, I’m talking 1-2 hours for the old pipeline, vs. 20 or so minutes for the 1 shot pipeline…and the 1-shot pipeline also includes having the LLM come up with new features and the feature specs each and every run.
I’m not sure about the token counts of each pipeline; my claim about “far fewer tokens” is based on the fact that the “rigid” pipeline generated many artifacts (coding plans, testing plans, auditing reports, etc.) that seemed to take quite a while to generate (reasoning tokens), tokens that maybe, just maybe, didn’t contribute to the end product as much as I would have liked.
I’ll be experimenting with the new “pipeline”, refining the testing requirements, etc. and examining the output (code, architecture, tests) vs. what was produced by my old pipeline.
Honestly, besides the models and harnesses becoming more capable, the biggest change towards fully autonomous game generation has been giving the agent “vision”, so that it can verify on screen what it thinks it “knows” about the game.
Lastly, one of the insights I’ve learned is that one of the biggest hurdles to a fully autonomous game generation system is something that I’ll call “aesthetics”. Not necessarily what is beautiful, although “aesthetics” can encompass that. By “aesthetics” I mean the emotional aspects of art in general and games in particular; what makes a game exciting, frustrating, boring, interesting to look at? Is the story engaging, are characters relatable? Does the story have irony, pathos, love, heroism, duty, sacrifice? An LLM can be prompted to approximate many of these qualities, but humans seem to be far better at creating and judging (gating) these aspects of a game, as they have been trained on these qualities literally all of their lives.
