Developer Builds Local Call Transcription for Mac in 9 Days with Claude Code

Cloud call-transcription services usually work the same way: a bot joins the call, and the recording goes off to someone else's servers. For many teams this is uncomfortable, especially when the conversation involves client code, pricing or HR matters. The alternative is obvious: do everything locally. But as a recent write-up on Habr shows, between "grab Whisper" and "get a working tool" lies a set of non-obvious traps.

What the author built

The developer, who runs about six projects and is constantly on calls, wrote a macOS app in nine days together with Claude Code. It records a call on two tracks (probably your own microphone separately from the other participants' audio), transcribes it and separates it by voice. All of this runs on the Mac itself: no bot in the call, no external servers. The source code is open, so it can be studied and used as a starting point.

The very fact that such a tool can be assembled in nine days with an AI assistant is telling. But what's more interesting is that the author put into the article not triumphant numbers but a list of pitfalls. For anyone building something similar, this is the most useful part.

The pitfalls listed in the announcement

According to the description, there are several problems, and they come from different layers of the stack.

Audio capture. ScreenCaptureKit can deliver digital silence instead of real audio, and FaceTime sound can't be heard at all. These are platform bugs, not model issues, and they are unlikely to be documented.

Echo without headphones. If the other person's audio plays through speakers, it gets into the microphone. The two tracks turn into two copies of the same conversation. The author writes that the offset between them changes 69 times during a single call, which means a simple fixed delay cannot remove the echo.

Whisper hallucinations. On silence the model outputs "Thank you", and in the end about a thousand of them pile up. This is known behavior for models of this family: they have to write something, so they write the most frequent phrase from the training data. It is fixed at the pipeline level: detect speech before recognition and don't feed empty chunks to the model.

Diarization. The author notes that voice separation sometimes splits people by speaking style rather than by identity. For example, calm lines and emotional ones may end up assigned to different speakers.

Memory. At one point the app took up 17 GB on a Mac with 16 GB. That means the system was swapping, which is unacceptable for a live application running alongside a call. Local models easily consume everything available, so memory has to be budgeted in advance.

Separately, the article includes a comparison of models on Russian speech. For Russian-speaking teams this is arguably the most practical section, because public benchmarks are mostly about English.

Takeaways

First: if you build local transcription, don't trust the incoming audio. Check that the tracks aren't empty, and add a silence filter before running recognition.

Second: echo and offsets between tracks are better handled dynamically, or you can simply recommend headphones. For a consumer product the second option is often cheaper.

Third: budget for memory. On 16 GB, the model, diarization and the call itself compete for the same resource.

Fourth: test models on your own language and your own recordings, not by leaderboards.

Limitations

The announcement itself offers only theses, with no numbers on quality or speed. Which model won on Russian and exactly how the problems were solved can only be seen in the full article and the repository. The app, judging by the description, is tailored to macOS, and the author gives no accuracy metrics in the teaser. Still, as a checklist of pitfalls, the piece is worth reading before you start your own version.