What happened
Willison describes a box room where an intermittent beep was difficult to trace by ear. Rather than search through every box, he asked Claude Code to help build Beep Locator, a software system that uses multiple devices in the room to triangulate a sound. The devices he used were two iPads, a phone, a MacBook Pro and a Surface Ultra. A Python web application serves the main interface; other devices join through a URL or QR code and act as listeners in a browser.
The listeners connect to the server over WebSockets and request browser microphone access. Each records a rolling 60-second buffer and runs a simple beep detector using a Fast Fourier Transform and a high-pass filter. When a listener detects a candidate beep, it reports the event to the server. The server selects a device with the lowest round-trip time to play a short chirp, then asks each listener to upload a clip covering roughly 0.6 seconds before the beep and 0.8 seconds after the chirp. The chirp provides a reference for aligning recordings, which the system needs in order to estimate where the sound originated.
Initial attempts to determine device locations by having them play sounds to each other did not work particularly well. Willison added a “Rough mode” that lets him drag devices to approximate positions on a map, after which the sound measurements adjust those estimates. He also added a clap-detection mode to test whether the system could locate a sound at a known place. Claps and beeps appear as different markers; recordings can be replayed from each listener, and a sound can be marked as the mystery beep. The system then tracks its frequency and the interval between occurrences to refine the likely location.
Willison says the system pinpointed the beep to within about 40 cm. He dug through the indicated pile and found an old carbon monoxide detector that needed new batteries. He reports that Claude Code began the work through Claude Code Cloud on his iPhone with Opus 5.5 in Extra thinking effort mode. After a repository and problem description were created, he moved to a laptop, started the server and used Claude Code with Fable 5.2 to make changes while the application was running.
A key implementation detail was a module-installation mechanism built into the listener clients. The server could send new code to clients over their WebSocket connection. Willison says this let him update the listeners without manually interacting with each device or reloading pages that might otherwise prompt again for microphone permission. He describes requesting features in conversation, including repositioning devices, timestamps, replay controls and suggestions for where an additional listener might help. The system draws on the 2007 BeepBeep paper, which Claude found during the project.
What the archive adds
New Runtime's earlier coverage has followed Willison's creative coding with Claude, including a playable game built from an open-ended prompt (October 21, 2026) and browser games made with Claude Opus 5.5 (November 4, 2026). Beep Locator is a new event in that thread: a more instrumented application, with live devices, audio measurements and an explicit test mode, rather than a game artifact.
Trend signal
This case offers a modest example of harness architecture outliving model choice: Willison began with Opus 5.5 and continued with Fable 5.2 while the Python server and browser clients remained the working application. The account does not compare models or establish that the harness itself is broadly reusable. It does show why an agent workflow that can observe and modify a running system may matter more than a single model's coding session.
Why it matters
The practical lesson is about the boundary between generated code and a working experiment. The project connected a server, browser microphone permissions, audio buffers, timing, a map interface and several physical devices. Claude Code's role extended across problem definition, implementation, testing and feature changes. A builder could use the same shape of workflow for a prototype that depends on several devices or sensors: keep the system observable, make tests easy to run, and give the agent a narrow mechanism for changing components while the experiment is active.
That last mechanism also raises an operational question. Beep Locator could execute newly delivered client code, according to Willison's description. That made iteration convenient, but any team adapting the idea should treat server-to-client code updates as a privileged deployment path, not an ordinary messaging feature. In a controlled home experiment, the convenience may outweigh the overhead; a shared or production environment would need explicit authorization and safeguards.
Limits and uncertainty
The roughly 40 cm result is Willison's account of one room and one beep source, not an independently measured benchmark. The post describes the devices and test, but this case does not establish performance across room shapes, background noise, different microphones or larger listener counts. Browser microphone access and device placement are part of the setup, and rough positioning was needed after automatic location estimation proved weak. The detector's behavior across other sound sources and the reliability of the live code-update mechanism beyond this experiment are not established here.
Skill to build now
For a multi-device prototype, separate detection from confirmation. Beep Locator reports candidate sounds, lets the operator replay clips, and asks the operator to mark the target before using repeated detections to refine its position. Builders can adopt that pattern this week: expose uncertain events, preserve the evidence behind them and provide a simple human confirmation step before the system treats a signal as ground truth.
Reader takeaway
Beep Locator is a useful demonstration of agent-assisted software iteration around a real, testable task. The notable result is not that one agent autonomously built a dependable acoustic product; it is that a developer combined model assistance, a live application and several devices to solve a specific problem, then checked the result against the physical world.