Claude Opus 5.5 Built an RTS You Play Over Sound: Inside Battle Drones' Audio Modem

Two phones on a table, no Wi-Fi, no Bluetooth, no server anywhere. One hosts a real-time strategy match, the other joins, and the only thing passing between them is noise — a carrier around 10 kHz going one way and 17 kHz the other, carrying player orders at roughly 1,880 bits per second. That is the newest feature in Claude Opus 5.5's most ambitious public artifact so far: Battle Drones, a Command & Conquer-style browser RTS that Simon Willison published on 20 October 2026, after twelve major iterations and 321 commits, mostly from coding agents. A​nthropic shipped Claude Opus 5.5 on 22 September 2026 at $4 per million input tokens and $20 per million output, so the model itself is a month old; what is new this week is the thing it was used to build, and the open specification that comes with it. Public artefacts like this one tend to leave out how the model fails underneath, and the recorded incidents are catalogued in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

Both halves of that claim are checkable. The game runs at simonw.github.io/battledrones/, the source is on GitHub under Apache-2.0, and the acoustic link is not a black box — the repo carries SOUND-DUEL.md, a full modem specification with band plans, coding rates, packet formats and measured signal-to-noise figures. What follows is what that document and the post actually say, separated from what they don't.

What shipped on 20 October

Battle Drones is not a demo reel. As described in the write-up, it has nine buildings, seven ground vehicles, six aerial vehicles and three infantry types, all built as 3D models generated in TypeScript rather than loaded from an asset pack. There is fog of war, with separate anti-air and anti-ground weapon requirements. Six maps span five biomes, plus a seeded random map generator that produces a 108×108 point-symmetric battlefield — built, per the post, in a 45-minute sprint after the author noticed he had 25% of a weekly Claude allowance left and 45 minutes until it reset.

Modes include skirmish, Last Stand survival waves, AI-vs-AI spectating, an eight-mission campaign, and something genuinely unusual: an agent-vs-agent mode where two language models play each other through a tool that exposes only fog-of-war-visible, non-visual game state. Recorded replays of those matches ship with the repo, alongside a debug viewer that shows the underlying model responses.

The counts in the repository's own README have drifted slightly from the post's feature list — the README says sixteen units and ten buildings, while the post enumerates nine buildings and sixteen units across ground, air and infantry. Sixteen matches; the building count does not. Small, but it is the kind of drift you get when an agent writes the README and nobody audits it, and the author says plainly that he has "reviewed almost none of the code."

The sound link, in numbers

This is the part worth reading the spec for, because "multiplayer over audio" sounds like a stunt until you see the engineering budget it had to fit into. Two devices share one room and one acoustic channel, so the design is frequency-division duplex: both phones transmit continuously, the host in 9.525–12.5 kHz and the guest in 15.975–18.95 kHz, with the bands placed so the host's second harmonic starts above 19.05 kHz and third-order intermodulation from each band stays clear of the other.

• Modulation — OFDM at 25 Hz tone spacing, 40 ms useful symbol plus a 10 ms cyclic prefix, so 50 ms per symbol and 20 symbols per second

• Payload — 188 bits per packet on the high band plan, 186 on the low fallback plan, identical in both modes so a mode switch never changes what fits

• Throughput — 1,880 bit/s in high fast mode, 940 bit/s high robust, 930 and 465 on the low plan; packets take 100, 200, 200 and 400 ms respectively

• Error control — convolutional code at K=7, rate ½, polynomials 133/171, soft Viterbi decoding, interleaving across symbols and tones, CRC-16 with polynomial 0x1021, and a hard reject if more than 10% of re-encoded bits disagree

• Framing — one sync symbol plus 40 data symbols per superframe, 41 symbols or 2.05 seconds, carrying 20, 10, 10 or 5 packets depending on plan and mode

• Measured link — 40–70 dB power SNR in every 1 kHz band from 1 to 21 kHz at 10–30 cm, degrading to an effective 17–31 dB at 10 cm and 9–19 dB at 30 cm once echo is accounted for, with reflections arriving 8–15 ms behind the direct path

The honest part of the spec is what it refuses to promise. There is no ARQ: a lost packet is not retransmitted, the next one simply re-describes every unacknowledged turn, and if the backlog outgrows one packet it is split across up to four rotating segments. Large backlogs therefore turn into lockstep stalls rather than corruption. Turns are accepted once each by high-water mark, and game packets are protected by a CRC keyed to both pairing nonces, so a recording of a different match fails its check. As the spec puts it, jamming can be survived but not prevented: you stall, you never silently desynchronise.

Delivery figures from the room-model tests are 99% or better at 20 cm and 95% at 40 cm in robust mode, 98% at 20 cm in fast mode. Those are simulation results reported in the spec, not a field study — and the post itself says the feature was very new when it shipped: "I only just got this working, so I've not had much time to actively test it yet."

The bug that matters more than the modem

Buried in the closing observations is the detail most likely to be useful to anyone building stateful software with an agent. Because replays and lockstep multiplayer both require the simulation to be bit-identical on every device, Claude had to stop calling Math.sin() and Math.cos() — Chrome and Safari return very slightly different values — and substitute its own implementations. Two browsers disagreeing in the last bits of a transcendental function is enough to desynchronise a match minutes later.

That is a real engineering constraint, found by the model and fixed by the model, and it generalises well past games. Any agent-built system with a deterministic core — a scheduler, a financial ledger replay, a simulation harness, a reproducible build — will hit the same class of problem, and it will hit it silently. The lesson for a reader is not "Claude is good at games." It is that determinism has to be an explicit requirement in the prompt, because nothing in a default implementation makes it true.

The Radio Probe, and a prompting pattern worth stealing

Before writing the modem, the model built a measurement page. The post describes a "Radio Probe" tool, still in the repo as radio-probe.html, whose job was to answer one question: how much bandwidth can two devices actually get between them, in this room, at this distance? The full implementation only went ahead after the probe returned numbers good enough to justify it. The same file documents the two things the probe has not measured — an iPhone transmitting with its own microphone open, and a phone hearing its own transmission — which are exactly the failure modes that would matter in the field.

The pattern is worth copying whatever model you use: ask the agent to build the instrument before it builds the feature. Measured first, built second is how you avoid a week of work resting on an assumption nobody checked. It also produces the numbers that make a claim like "audio multiplayer works" verifiable rather than charming.

What this says about Claude Opus 5.5, and what it doesn't

The strongest claims in the post are specific. Willison writes that Claude Opus 5.5 is "spectacular at 3D modeling using Three.js" — every building, vehicle and landscape in the game is procedurally constructed in code, and he rates GPT-6 Astra in the same bracket. He also notes the model writes music: there are no audio files in the project, and the soundtrack is generated in code, varies by map and intensifies as combat heats up.

Two further results are author-reported rather than independently reproduced, and should be read that way. The "fun update" was a single prompt — "This game isn't fun enough yet. Make it a LOT more fun." — run in a dynamic-workflow mode that orchestrates many subagents for many hours, during which the model ran over a thousand simulated playtest sessions. The reported outcome, from 1,200 AI-vs-AI matches on Normal difficulty: games still undecided after 25 minutes fell from 14% to 0.9%, and the share of wins by a side that had been 800+ scrap behind rose from 24% to 46%. Those are the author's measurements of his own game, not a benchmark of the model.

What the piece does not show is equally important. There is no third-party evaluation of Claude Opus 5.5 on game development, no head-to-head against another model on the same task, and no token or dollar accounting for the runs. The author's own framing is that he knows "almost nothing about game development," has "reviewed almost none of the code," and does not consider the result a serious indie project. That is an unusually candid set of caveats, and it caps how far the result can be generalised: this is one practitioner, one codebase, one month.

What it costs to run a project like this

A​nthropic's published rate card for Claude Opus 5.5 is $4.00 per million input tokens, $20.00 per million output, and $0.20 per million for cache reads. A project of this shape is almost entirely output-bound — the model is writing TypeScript, not reading a large fixed corpus — so the $20 output line is the one that governs the bill, and the multi-hour overnight runs at high parallelism are what turn "cheap per token" into a real number. No total was published for Battle Drones, so the honest statement is that the ceiling is set by how many agent-hours you are willing to buy, not by any figure in the post.

That is also the argument for not committing a production path to a single model on the strength of one impressive artifact. Claude Opus 5.5 is on OrcaRouter at Anthropic's list price with 0% markup, so a price change from the vendor is live on our side the same day, and automatic failover means a long agent run does not die because one upstream endpoint is having a bad afternoon. If you want to test whether an overnight build like this is reproducible on a different model, one API for 200+ models is the cheapest way to find out — same request shape, different model name, no second contract.

What is not established

• Popularity — the repository showed 4 stars and 0 forks when checked on 21 October 2026, a day after the post went up. This is not a phenomenon; it is one person's project, published.

• Field reliability of the audio link — the spec's delivery percentages come from room-model tests, and the author states he had not had much time to actively test the feature. Do not read 99% as a promise about your kitchen table.

• Prior art — the post cites Siner by Alon Horesh and ggwave by Georgi Gerganov as the only comparable work it could find, and calls audio multiplayer for static HTML games "a first for an RTS as far as I can tell." That is the author's search, not a literature review.

• Attribution of the code — Claude Opus 5.5 drove most of the later iterations, but the first version was built with Claude Fable 5 back in July, and the README itself says the rest of the document was written by Claude. Treat the repo as a mixed-provenance artifact.

• A benchmark result — there isn't one. Nothing here measures Claude Opus 5.5 against another model on a task with a score.

The thing to actually take away is narrower and more useful than "an AI built a game." A browser RTS with no backend, a deterministic simulation, and a working acoustic modem is a demonstration that the hard part of agent-built software has moved from generating code to specifying constraints — determinism, measurement, error behaviour — precisely enough that the generated code is checkable. The SOUND-DUEL.md document is the evidence: it exists because someone made the model write down what the link could and could not do before shipping it. If you want to see whether that discipline transfers to your own workload, run the same prompt against a second model and compare the specs, not the screenshots.