Muse Spark 1.1 Enters the Game Creation Arena

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.

You can play the Muse Spark 1.1 generated game here, in your web browser; just look for the Muse Spark 1.1 game card: https://rgm-llm-asteroids-arcade.netlify.app

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.

Meta AI’s blog post announcing Muse Spark 1.1 : https://ai.meta.com/blog/introducing-muse-spark-meta-model-api/

Let’s try the latest open weights models

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.

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:

https://rgm-llm-asteroids-openweight-arcade.netlify.app

You can compare the results of the open weight models to the games previously generated by the frontier LLMs:

https://rgm-llm-asteroids-arcade.netlify.app

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.

Testing Claude Sonnet 5 as an autonomous game development agent

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.

The full prompt is here, and includes guidance to the LLM on code architecture, testing, and choosing new features : https://github.com/rgmarquez/devrep20-claude-sonnet-5/blob/main/notes/prompt.md

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 game can be played in a web browser here : https://rgmarquez.github.io/devrep20-claude-sonnet-5/

The actual GitHub repository can be found here : https://github.com/rgmarquez/devrep20-claude-sonnet-5

The pragmatics of priorities

In looking at my list of projects, it occurs to me that in order to make a dent in most of them, I really should step up to the plate and learn the front-end Javascript framework “React”. I’m choosing to learn React over something newer (like Svelte) as a great deal of companies use React, and I’m trying to make myself more marketable as well as learning front end coding for my projects. A two birds with one stone kind of thing.

I actually know a bit of front-end coding with both straight HTML/CSS/JavaScript and with Angular.js, but again, I believe that React knowledge will get me farther with prospective employers, while allowing me to create professional quality front-ends for my projects.

I’ll be using Mosh Hamedani’s “Code with Mosh” videos to learn React. In theory, his videos will be building my knowledge up to coding a “production grade app for discovering video games”, and I like the idea of learning enough about React to be able to code such an app:

If you are interested in Mosh’s coding courses, they can be found here: https://codewithmosh.com