The first thing to talk about is the infrastructure, because getting all this work moving meant figuring out where it could actually run.

Infrastructure Overview

The Shrimp Hub Swarm Controller runs on a Mac with Unreal Engine 5.8 installed. At least for now, the editor instances have to run on that same machine.

There’s also an instance of Claude Code on the Mac acting as support for the controller. This is critical infrastructure for the jam, so I want help keeping it working and adjusting things like load balancing as we go.

A separate Linux machine handles remote builds and playtesting. That takes some pressure off the controller’s Mac, and the swarm can send agents over to play the games there.

Then there’s another Linux server handling local inference. It runs Qwen 3.8 Flash Next for search and diagnosis tasks, so the cloud models can spend more of their time implementing things and less of it exploring.

That server also provides a few other tools:

  • Whisper for speech-to-text, which I’m using heavily.
  • KREA 2 and MOSS for image generation.
  • A 3D generation endpoint running modified Trellis 2 and Pixal 3D.

And the machine I’m orchestrating all of this from? A five-year-old ThinkPad running Fedora.

Inside the swarm

At the controlsThinkPad · FedoraHuman direction and orchestration
MacShrimp Hub Swarm Controller

Coordinates agents and shares work across three games.

  • Feral Divinity
  • The Price of Power
  • SCRAPHEAP
Unreal Engine 5.8Editor instances run hereClaude CodeController support and load balancing
Up to 20 concurrent agents across the whole swarm
Work and tools use these shared resources
Linux · builds

Build & playtest

Remote builds and agent playtesting take pressure off the Mac.

Linux · inference

Local models & tools

  • QwenSearch and diagnosis
  • WhisperSpeech to text
  • KREA 2 · MOSSImage generation
  • Trellis 2 · Pixal 3D3D generation
Cloud · providers

Fallback chain

  1. MiniMax
  2. OpenCode Go
  3. Mistral

Move to the next provider when the current budget runs out.

A logical overview, rather than a network map. The twenty-agent maximum came after Day 1’s provider fallbacks. By Night One, editor and build capacity had each increased from four slots to six.

Editor Instances and stuck agents

As the day went on, we ran into cases where agents were getting stuck. We started taking measurements and trying to work out where the bottlenecks actually were.

In some cases, Unreal editor instances were sitting unused while agents were waiting. We needed better load balancing and a checkout system so an agent could claim a specific editor instance and keep working.

Having resources available wasn’t enough. We had to get the work assigned to them properly.

Builds had a similar problem. The Linux worker had spare capacity, but agents couldn’t reach it directly from their sandbox. We routed their compile requests through the controller so they could use it.

Build routing

Before

Agent compile requestsFrom their own worktrees
Mac build queueAgent compiles compete for local slots
Linux workerMostly post-merge validation; spare capacity

After

Agent compile requestsFrom their own worktrees
Swarm ControllerRoutes the sandboxed agent’s build request
Linux build workerCompiles the agent’s worktree

Editor work stays on the Mac. Remote compile checks free local capacity; they don’t replace editor builds.

Increasing throughput

I’d started the swarm conservatively, with a maximum of eight agents. In previous large-scale tests, I’d reached roughly eighteen simultaneous agents, but I hadn’t been able to sustain that. We were hammering the MiniMax endpoint and getting a lot of 429 responses.

On Day 1, we raised the number of agents that could run at once. That was when we started hitting the provider limits.

MiniMax 3.1 Flash was the main model because that was where I had the most token budget. More agents meant putting more pressure on that budget.

Adding fallback providers

That was when we hooked up OpenCode Go and Mistral as backups.

Provider fallback order
  1. 01 · PrimaryMiniMaxMain token budget
  2. 02 · FallbackOpenCode GoDeepSeek 4.1 Flash
  3. 03 · FallbackMistralDeepSeek backfill

When a provider reaches its limit, requests move to the next available provider.

I was backfilling with DeepSeek 4.1 Flash through the other providers, giving the work somewhere to go instead of stopping at the first exhausted provider.

Once the fallback providers were set up, we increased the maximum to twenty concurrent agents across the whole swarm.

Three projects sharing the same compute

Initially, agents could pick any project to work on, with no per-project limit.

Feral Divinity ended up taking ten agents at once. The other projects weren’t getting as much attention, and that created another bottleneck.

Throughout the day, we had to balance the task load across projects, look at how far along each one was, and share the available compute more deliberately.

Meanwhile, the devlog needed somewhere to live

While all this was happening, I was also getting the infrastructure together for this devlog.

The original plan was to put it on GitHub Pages. That didn’t work out, so I asked Codex to add the functionality to my existing company website.

Instead of just doing that, it overhauled the website.

It looks a lot better now. It got excited and went ham on it, which is cool.