Claude Opus 5.5 bouwde een RTS die je via geluid speelt: een kijkje in de audiomodem van Battle Drones

Twee telefoons op een tafel, geen Wi-Fi, geen Bluetooth, nergens een server. De ene host een real-time strategiespel, de andere doet mee, en het enige dat tussen hen wordt uitgewisseld is geluid — een draaggolf rond 10 kHz in de ene richting en 17 kHz in de andere, die spelersopdrachten vervoert met ongeveer 1.880 bits per seconde. Dat is de nieuwste functie in Claude Opus 5.5 — het meest ambitieuze publieke artefact tot nu toe: Battle Drones, een browser-RTS in de stijl van Command & Conquer die Simon Willison op 20 oktober 2026 publiceerde, na twaalf grote iteraties en 321 commits, grotendeels van codingagents. Anthropic bracht Claude Opus 5.5 op 22 september 2026 uit voor $4 per miljoen invoertokens en $20 per miljoen outputtokens, dus het model zelf is een maand oud; wat deze week nieuw is, is het ding dat ermee is gebouwd, en de open specificatie die erbij hoort. Openbare artefacten zoals dit laten meestal weg hoe het model eronder faalt, en de geregistreerde incidenten zijn gecatalogiseerd in the OrcaRouter AI Incident Archive waarbij elke vermelding eigen bronnen, ernst, betrouwbaarheidsgraad en een betwistmarkering heeft.

Beide helften van die bewering zijn controleerbaar. Het spel draait op simonw.github.io/battledrones/, de broncode staat op GitHub onder Apache-2.0, en de akoestische link is geen blackbox — de repo bevat SOUND-DUEL.md, een volledige modemspecificatie met bandplannen, coderingssnelheden, packetformaten en gemeten signaal-ruisverhoudingen. Wat volgt is wat dat document en het bericht daadwerkelijk zeggen, gescheiden van wat ze niet zeggen.

Wat is er op 20 oktober uitgebracht?

Battle Drones is geen demo-reel. Zoals beschreven in het artikel heeft het negen gebouwen, zeven grondvoertuigen, zes luchtvoertuigen en drie infanterietypen, allemaal gebouwd als 3D-modellen die in TypeScript zijn gegenereerd in plaats van uit een assetpack te worden geladen. Er is fog of war, met afzonderlijke wapenvereisten voor lucht- en gronddoelen. Zes kaarten beslaan vijf biomen, plus een op seeds gebaseerde willekeurige kaartgenerator die een puntsymmetrisch slagveld van 108×108 oplevert — volgens het bericht gebouwd in een sprint van 45 minuten nadat de auteur merkte dat hij nog 25% van een wekelijkse Claude-limiet over had en 45 minuten tot de reset.

Modi omvatten skirmish, Last Stand-overlevingsgolven, AI-tegen-AI-toeschouwen, een campagne van acht missies, en iets werkelijk ongewoons: een agent-tegen-agentmodus waarin twee taalmodellen tegen elkaar spelen via een tool die alleen fog-of-war-zichtbare, niet-visuele spelstatus blootlegt. Opgenomen replays van die wedstrijden worden meegeleverd met de repo, samen met een debugviewer die de onderliggende modelreacties toont.

De aantallen in de README van de repository zelf zijn licht afgedreven van de functielijst in het bericht — de README zegt zestien eenheden en tien gebouwen, terwijl het bericht negen gebouwen en zestien eenheden opsomt, verdeeld over grond, lucht en infanterie. Zestien klopt; het aantal gebouwen niet. Klein, maar het is het soort afwijking dat je krijgt wanneer een agent de README schrijft en niemand die controleert, en de auteur zegt ronduit dat hij "bijna geen van de code heeft nagekeken."

De geluidslink, in cijfers

Dit is het deel waarvoor het de moeite loont de specificatie te lezen, want "multiplayer via audio" klinkt als een stunt tot je ziet binnen welk engineeringbudget het moest passen. Twee apparaten delen één ruimte en één akoestisch kanaal, dus het ontwerp is frequency-division duplex: beide telefoons zenden continu uit, de host in 9,525–12,5 kHz en de gast in 15,975–18,95 kHz, waarbij de banden zo zijn geplaatst dat de tweede harmonische van de host boven 19,05 kHz begint en intermodulatie van derde orde uit elke band buiten de andere blijft.

• Modulatie — OFDM met 25 Hz toonafstand, 40 ms nuttige symboolduur plus een cyclische prefix van 10 ms, dus 50 ms per symbool en 20 symbolen per seconde

• Payload — 188 bits per pakket in het plan voor de hoge band, 186 in het terugvalplan voor de lage band, identiek in beide modi, zodat een moduswissel nooit verandert wat er past

Doorvoer — 1.880 bit/s in de hoge snelle modus, 940 bit/s in de hoge robuuste modus, 930 en 465 op het lage plan; pakketten doen er respectievelijk 100, 200, 200 en 400 ms over

• Foutbeheersing — convolutionele code met K=7, rate ½, polynomen 133/171, zachte Viterbi-decodering, interleaving over symbolen en tonen, CRC-16 met polynoom 0x1021, en een harde afwijzing als meer dan 10% van de opnieuw gecodeerde bits niet overeenkomt

• Framing — één synchronisatiesymbool plus 40 datasymbolen per superframe, 41 symbolen of 2,05 seconden, met 20, 10, 10 of 5 pakketten afhankelijk van plan en modus

• Gemeten link — 40–70 dB vermogens-SNR in elke 1 kHz-band van 1 tot 21 kHz bij 10–30 cm, afnemend tot een effectieve 17–31 dB bij 10 cm en 9–19 dB bij 30 cm wanneer echo wordt meegerekend, met reflecties die 8–15 ms na het directe pad aankomen

Het eerlijke deel van de specificatie is wat ze weigert te beloven. Er is geen ARQ: een verloren pakket wordt niet opnieuw verzonden, het volgende beschrijft simpelweg elke niet-bevestigde beurt opnieuw, en als de achterstand groter wordt dan één pakket, wordt die verdeeld over maximaal vier roterende segmenten. Grote achterstanden veranderen daardoor in lockstep-blokkades in plaats van corruptie. Beurten worden elk één keer geaccepteerd aan de hand van een high-watermark, en spelpakketten worden beschermd door een CRC met beide pairing-nonces als sleutel, zodat een opname van een andere wedstrijd de controle niet doorstaat. Zoals de specificatie het formuleert: jamming kan worden overleefd, maar niet voorkomen: je komt vast te zitten, je raakt nooit stilzwijgend gedesynchroniseerd.

De leveringscijfers uit de kamermodeltests zijn 99% of beter bij 20 cm en 95% bij 40 cm in de robuuste modus, en 98% bij 20 cm in de snelle modus. Dat zijn simulatieresultaten die in de specificatie worden gerapporteerd, geen veldonderzoek — en de post zelf zegt dat de functie heel nieuw was toen die werd uitgebracht: "Ik heb dit pas net aan de praat gekregen, dus ik heb nog niet veel tijd gehad om het actief te testen."

De bug die belangrijker is dan de modem

Diep in de afsluitende observaties zit het detail dat waarschijnlijk het nuttigst is voor iedereen die stateful software met een agent bouwt. Omdat replays en lockstep-multiplayer allebei vereisen dat de simulatie op elk apparaat bitidentiek is, moest Claude stoppen met het aanroepen van Math.sin() en Math.cos() — Chrome en Safari retourneren heel iets andere waarden — en zijn eigen implementaties gebruiken. Twee browsers die het in de laatste bits van een transcendente functie oneens zijn, volstaan om een wedstrijd minuten later te desynchroniseren.

Dat is een echte technische beperking, gevonden door het model en opgelost door het model, en ze generaliseert ruim voorbij games. Elk door een agent gebouwd systeem met een deterministische kern — een scheduler, een replay van een financieel grootboek, een simulatieharnas, een reproduceerbare build — zal tegen dezelfde klasse van problemen aanlopen, en het zal dat stilletjes doen. De les voor een lezer is niet "Claude is goed in games." Het is dat determinisme een expliciete vereiste in de prompt moet zijn, omdat niets in een standaardimplementatie het waar maakt.

De Radio Probe, en een promptingpatroon dat het stelen waard is

Voordat de modem werd geschreven, bouwde het model een meetpagina. De post beschrijft een "Radio Probe"-tool, die nog steeds in de repo staat als radio-probe.html, met als taak één vraag te beantwoorden: hoeveel bandbreedte kunnen twee apparaten in deze ruimte, op deze afstand, daadwerkelijk tussen hen beiden krijgen? De volledige implementatie ging pas door nadat de probe cijfers opleverde die goed genoeg waren om die te rechtvaardigen. Hetzelfde bestand documenteert de twee dingen die de probe niet heeft gemeten — een iPhone die uitzendt met zijn eigen microfoon open, en een telefoon die zijn eigen uitzending hoort — en dat zijn precies de storingsmodi die in het veld van belang zouden zijn.

Het patroon is het kopiëren waard, welk model je ook gebruikt: vraag de agent om het instrument te bouwen voordat hij de functie bouwt. Eerst meten, dan bouwen is hoe je voorkomt dat een week werk rust op een aanname die niemand heeft gecontroleerd. Het levert ook de cijfers op die een bewering als "audio-multiplayer werkt" verifieerbaar maken in plaats van charmant.

Wat dit zegt over Claude Opus 5.5, en wat het niet zegt

De sterkste beweringen in het bericht zijn concreet. Willison schrijft dat Claude Opus 5.5 "spectaculair is in 3D-modellering met Three.js" — elk gebouw, voertuig en landschap in het spel wordt procedureel in code geconstrueerd, en hij plaatst GPT-6 Astra in dezelfde categorie. Hij merkt ook op dat het model muziek schrijft: er zijn geen audiobestanden in het project, en de soundtrack wordt in code gegenereerd, verschilt per kaart en wordt intenser naarmate het gevecht heviger wordt.

Twee verdere resultaten zijn door de auteur gerapporteerd in plaats van onafhankelijk gereproduceerd, en moeten ook zo worden gelezen. De “fun-update” was één enkele prompt — “Dit spel is nog niet leuk genoeg. Maak het VEEL leuker.” — uitgevoerd in een dynamische workflowmodus die urenlang veel subagents aanstuurt, waarbij het model meer dan duizend gesimuleerde playtestsessies uitvoerde. De gerapporteerde uitkomst, op basis van 1.200 AI-tegen-AI-wedstrijden op Normal-moeilijkheidsgraad: het aandeel partijen dat na 25 minuten nog onbeslist was, daalde van 14% naar 0,9%, en het aandeel overwinningen van een zijde die 800+ scrap achterstond, steeg van 24% naar 46%. Dat zijn de metingen van de auteur van zijn eigen spel, geen benchmark van het model.

Wat het stuk niet laat zien, is even belangrijk. Er is geen evaluatie door derden van Claude Opus 5.5 op het gebied van gameontwikkeling, geen rechtstreekse vergelijking met een ander model op dezelfde taak, en geen token- of dollarverantwoording voor de runs. De auteur zelf stelt dat hij "bijna niets van gameontwikkeling afweet", "bijna geen van de code heeft beoordeeld" en het resultaat niet als een serieus indieproject beschouwt. Dat is een ongewoon openhartige reeks voorbehouden, en het beperkt hoe ver het resultaat kan worden gegeneraliseerd: dit is één persoon uit de praktijk, één codebase, één maand.

Wat het kost om een project als dit te runnen

De gepubliceerde tariefkaart van A​nthropic voor Claude Opus 5.5 is $4,00 per miljoen invoertokens, $20,00 per miljoen uitvoertokens en $0,20 per miljoen voor cache-leesacties. Een project van deze vorm is vrijwel volledig outputgebonden — het model schrijft TypeScript, leest geen grote vaste corpus — dus de uitvoerregel van $20 is degene die de rekening bepaalt, en de urenlange nachtelijke runs met hoge parallelliteit zijn wat "goedkoop per token" in een echt getal verandert. Er is geen totaal gepubliceerd voor Battle Drones, dus de eerlijke uitspraak is dat het plafond wordt bepaald door hoeveel agent-uren je bereid bent te kopen, niet door enig cijfer in het bericht.

Dat is ook het argument om een productiepad niet aan één model vast te leggen op basis van één indrukwekkend artefact. Claude Opus 5.5 is bij OrcaRouter tegen Anthropic's lijstprijs met 0% opslag, zodat een prijswijziging van de leverancier dezelfde dag aan onze kant live is, en automatische failover betekent dat een lange agentrun niet sterft omdat één upstream-endpoint een slechte middag heeft. Als je wilt testen of een nachtelijke build zoals deze reproduceerbaar is op een ander model, één API voor 200+ modellen is de goedkoopste manier om erachter te komen — dezelfde requestvorm, een andere modelnaam, geen tweede contract.

Wat is niet vastgesteld

• Populariteit — de repository had 4 sterren en 0 forks toen er op 21 oktober 2026 werd gekeken, een dag nadat het bericht online verscheen. Dit is geen fenomeen; het is het project van één persoon, gepubliceerd.

• Betrouwbaarheid van de audiolink in de praktijk — de afleverpercentages in de spec komen uit kamermodeltests, en de auteur geeft aan dat hij niet veel tijd heeft gehad om de functie actief te testen. Zie 99% niet als een belofte over je keukentafel.

• Eerder werk — de post noemt Siner van Alon Horesh en ggwave van Georgi Gerganov als het enige vergelijkbare werk dat hij kon vinden, en noemt audiomultiplayer voor statische HTML-games "een primeur voor een RTS voor zover ik kan zien." Dat is de zoektocht van de auteur, geen literatuuronderzoek.

• Toeschrijving van de code — Claude Opus 5.5 was verantwoordelijk voor de meeste latere iteraties, maar de eerste versie werd in juli gebouwd met Claude Fable 5, en de README zelf zegt dat de rest van het document door Claude is geschreven. Behandel de repo als een artefact met gemengde herkomst.

• Een benchmarkresultaat — dat is er niet. Niets hier vergelijkt Claude Opus 5.5 met een ander model op een taak met een score.

De eigenlijke les is specifieker en nuttiger dan "een AI heeft een game gebouwd." Een browser-RTS zonder backend, een deterministische simulatie en een werkende akoestische modem tonen aan dat het moeilijke deel van door agents gebouwde software is verschoven van het genereren van code naar het specificeren van beperkingen — determinisme, meting, foutgedrag — nauwkeurig genoeg dat de gegenereerde code controleerbaar is. Het SOUND-DUEL.md-document is het bewijs: het bestaat omdat iemand het model heeft laten opschrijven wat de verbinding wel en niet kon voordat die werd uitgebracht. Als je wilt zien of die discipline overdraagbaar is naar je eigen werklast, voer dan dezelfde prompt uit bij een tweede model en vergelijk de specs, niet de screenshots.