How Claude Helped Track Down a Mystery Beep Using Sound Triangulation
Simon Willison used Claude Code to build a sound triangulation system that located a mystery beeping device within 40cm, drawing on a 2007 academic paper and conversational feature prompts. The project demonstrates how AI coding agents can be given real-world perception through browser microphones and WebSocket infrastructure.
A Carbon Monoxide Detector, a Box Room, and a Very Patient AI
Somewhere in a cluttered box room — the kind that accumulates after a move when you run out of energy to unpack — something was beeping. Not constantly. Just often enough to be maddening, and infrequently enough that standing in the room waiting for it felt like a waste of an afternoon.
That was the starting point for a genuinely fascinating engineering story. Simon Willison’s blog describes, in precise detail, how he used Claude Code to build a custom software system he called Beep Locator — a tool that used multiple devices scattered around a room to triangulate the source of a sound. The system worked. It located the beep to within roughly 40 centimetres, and the culprit turned out to be an ancient carbon monoxide detector crying out for new batteries.
The story is worth your time not because you are likely to need a beep triangulator, but because it demonstrates something important about what AI coding agents can now do — and how far that extends beyond writing conventional software.
What Beep Locator Actually Does
According to Simon Willison’s write-up, Beep Locator works by running a Python web server that acts as a central coordinator. You open the main interface on one device, then connect as many other devices as you can spare — phones, tablets, laptops — by visiting a URL or scanning a QR code. Each connected device uses its browser microphone to listen continuously, storing a rolling 60-second audio buffer.
When any device detects a beep, the server instructs one of the listening devices to play a short chirp. Every listener then uploads a clip of audio from just before the beep through to just after the chirp. That chirp acts as a synchronisation point — it allows the server to align the clips from each device precisely in time. With precise timing across multiple devices at known positions, the system can calculate where in the room the sound originated.
To detect beeps in the first place, the system uses a technique called Fast Fourier Transform combined with a high-pass filter — a standard method for identifying sounds at specific frequencies. This runs in JavaScript on each listening device.
The positional awareness of the devices themselves was handled through a combination of automated sound-based ranging (the devices play sounds to each other to estimate distances) and a manual fallback Willison called ‘Rough mode,’ where you drag icons on a map to approximately where the devices sit in the room. The automated method was imperfect, so the manual drag-and-drop fallback was crucial.
Willison also added a clapping mode — clap your hands in different spots, see diamonds appear on the map — purely to test whether the triangulation was working before the mysterious beep decided to cooperate.
The Research Behind It: A 2007 Academic Paper
One detail that stands out in Willison’s account is how Claude found the theoretical foundation for the project. When he began describing the problem, Claude surfaced an academic paper from 2007 titled BeepBeep: A High-Accuracy Acoustic-Based System for Ranging and Localization Using COTS Devices, authored by Chunyi Peng, Guobin Shen, Yongguang Zhang, Yanlin Li, and Kun Tan. The paper describes a pure software approach to acoustic ranging using only a speaker, a microphone, and device-to-device communication — which is precisely what Willison needed.
This is a capability that often gets underestimated. Claude did not just write code on demand. It identified a relevant research direction, read the paper, summarised its relevance in a problem specification document, and used the paper’s core concepts to shape the architecture of the system. For a non-technical person working through an unusual problem, this kind of research synthesis can be as valuable as the code itself.
How the Build Unfolded
Willison’s account describes starting the project using Claude Code on his iPhone, with the Opus 5.5 model running in what he calls ‘Extra thinking effort mode.’ He opened with a prompt asking Claude to write a problem specification document first — before writing a single line of code. That document captured the full scope of the problem, the constraints, and the research Claude had found.
Once the problem was clearly defined, he instructed Claude to build it — and to include a mechanism for pushing new code to the listening devices over the WebSocket connection so that he could update the software without physically touching each device. This meant that once the devices were placed around the room, Claude could continue iterating on the software remotely, without anyone having to reload pages or grant microphone permissions again.
Willison describes his role from that point as largely conversational. He would describe a feature in plain language — ‘I want to be able to drag devices around the map,’ or ‘can it listen for claps so I can test it?’ — and Claude would implement it. Each feature prompt reads like something you might type in a chat window rather than a technical specification.
Later in the project, he switched to working with Fable 5.2 on his laptop, allowing Claude Code to both run the server and make live changes while observing what was happening in real time.
What This Means for You: An Indian Professional Scenario
Consider a facilities manager at a large commercial building in Pune — say, a corporate campus with multiple server rooms, storage areas, and utility corridors. Equipment in these spaces routinely emits alerts: UPS units, fire detection sensors, environmental monitors. When an alert goes off in a poorly organised storage room, identifying which device is triggering it can consume hours of staff time.
Using the approach Willison documents, a technically curious team member — not necessarily a software engineer — could describe the problem to Claude in plain language and work through building a custom detection tool. They would need someone to run the Python server and deploy it on a laptop, but the conversation-driven development model means the shape of the solution can come from someone who understands the problem, not just someone who knows how to code.
Similarly, a property management company in Noida handling multiple residential towers could use this pattern to think about acoustic monitoring — not just for mystery beeps, but for detecting unusual sounds in common areas, plant rooms, or electrical substations. The underlying concept of using multiple cheap consumer devices as a distributed microphone network is genuinely novel and was assembled, start to finish, in a single project session.
Giving Claude ‘Ears’: The Bigger Idea
Willison explicitly frames the most interesting part of this project as the question of how to extend a coding agent’s perception beyond text. Claude does not natively hear audio. But by building a web server that collects audio data from browser microphones and feeds it back as structured information, Willison effectively gave Claude Code access to real-world sound.
He draws a parallel to a story from Martin Woodward at GitHub Universe, where a developer debugged hardware by pointing a webcam at a screen so a coding agent could see whether updates were working. The common thread is that agents can perceive the world through code — through cameras, microphones, sensor feeds — when given the right instrumentation.
This reframes what ‘using AI’ means. It is not only about generating text or summarising documents. It is increasingly about building bespoke perception systems tailored to specific, unusual real-world problems.
Limitations and Honest Tradeoffs
Willison’s account is candid about where the system struggled. The automated sound-based device positioning did not work well enough to rely on alone — hence the manual ‘Rough mode.’ Triangulation accuracy at roughly 40 centimetres is impressive for an ad-hoc system but would not be sufficient for applications needing centimetre precision.
The system also requires a Python environment to run the server, which puts it outside the reach of users with no technical support at all. Browser microphone permissions add friction, particularly on mobile devices where pages request permission on every reload — a problem the hot-swap code mechanism was specifically built to work around.
There is no packaged product here. Beep Locator is a bespoke tool built for one problem in one room. Replicating it requires access to Claude Code, comfort with running a local server, and the patience to iterate through a conversational build session. For Indian users, Claude Code availability and pricing (Claude’s Pro plan is priced at approximately ₹1,700 per month at current exchange rates, though Claude Code access tiers vary) are worth checking against Anthropic’s current regional offerings before planning a similar project.
What to Watch Next
Simon Willison’s full write-up at simonwillison.net includes links to the shared starter session, the problem specification document Claude produced, and the repository itself — all worth reading if you want to understand the step-by-step progression from blank repository to working system.
The broader pattern to watch is the agent-as-perceiver model: coding agents being given structured access to cameras, microphones, sensors, and external data streams so they can reason about the physical world rather than just documents. As that capability matures, the class of problems that a non-technical professional can describe and have an agent solve will expand significantly.
