Claude Code Located a Beeping Sensor by Sound Using Five Gadgets, to Within 40 cm

A familiar household story: in a room with boxes still unpacked after a move, something beeps from time to time. The sound is infrequent, impossible to locate by ear, and nobody wants to dig through everything. The author of the original post solved the problem the way many small problems get solved today: he handed it to Claude Code. The result is called Beep Locator, and it is interesting less for the beep itself than for how the work was divided between human and agent.

How Beep Locator works

A Python web server runs on a laptop. The other devices open the page via a QR code or a link and become listeners. The test involved two iPads, a phone, a MacBook Pro and a Surface. Each device gets microphone access through WebAudio and keeps the last 60 seconds of audio in memory. A simple detector based on a fast Fourier transform with a high-pass filter flags suspicious beeps and reports them to the server.

Then comes the main part. The server asks one of the devices to play a short chirp, and requests from each listener a fragment of recording from roughly 0.6 seconds before the beep to 0.8 seconds after the chirp. The chirp serves as a common reference point: it is used to align recordings from different devices, revealing how much earlier the beep reached one microphone than another. The position on the map is calculated from that time difference.

Claude found the idea on its own: a 2007 paper called BeepBeep on measuring distances by sound on ordinary phones and PDAs. It needs only a speaker, a microphone and a communication channel. For setup, the devices first played sounds to each other to determine their relative positions, but this worked poorly. So a "rough mode" was added: icons are dragged on the map to roughly where the devices stand, and the system then refines the coordinates.

Hot code swapping and iterating with the agent

The most practical solution here has nothing to do with acoustics. Back in the first stage, the listeners were given an installModule() method: via WebSocket, the server can send new JavaScript to any device, and it runs immediately. The reason is prosaic: on some devices the browser asks for microphone access again after every page reload, and walking around to every gadget by hand after each change would be torture.

Thanks to this, the agent could change the behavior of the "ears" on the fly, read the sound logs and retune the detector without human involvement. The author mostly sat nearby and gave tasks in plain language. He asked for a clap mode to test the system, timestamps on the icons, a log with a button to play back the recording from each device, and a "This is the mystery beep" button. The marking helps the system recognize the right frequency and track exactly that. Next came a "Rearrange devices" function without restarting the listeners and a hint about where to place one more microphone to refine the position by about 12%.

The project was started on an iPhone in Claude Code with the Opus 5.5 model, and finished on a laptop with the new Fable 5.2. It's a good example of a division of labor: the first session wrote problem.md and the foundation, while the second debugged the system in the live environment.

Takeaways

The author's main idea: a coding agent can be given senses even if the model has none. Claude has no audio input of its own, but it can write and run code that analyzes sound from other people's microphones, and tune that code itself. A similar trick was described at GitHub Universe: a webcam was pointed at a device screen so the agent could see whether an update had worked. For developers the takeaway is simple: if the agent is "blind," think about what cheap feedback channel to give it (camera, microphone, logs, screenshots), and it will start closing the "change — check" loop on its own.

There are caveats. This is a home experiment, not a precision instrument: accuracy is about 40 cm in a single room with five devices, and without this result you would have had to dig through the boxes anyway. Automatic calibration by sound worked poorly, so manual placement was needed. Moreover, a mechanism that executes arbitrary code on clients over WebSocket is convenient for debugging, but on someone else's network it is a ready-made hole. It should only be used in a trusted environment and for the duration of the experiment.