Idea: Always-on replay buffer for retroactive transcription

[curreta]

I've been using Handy daily and ran into a recurring situation: something worth capturing gets said before I think to start recording. By the time I reach for the hotkey, the moment has passed.

I ended up building a ring buffer mode in a local fork that keeps a rolling window of audio in memory (configurable, 1–30 minutes). When I hit a hotkey, it clips whatever's in the buffer, runs it through VAD to strip silence, transcribes it, and pastes the result — same as a normal transcription, just retroactive.

The mental model is similar to NVIDIA ShadowPlay or a dash cam: always capturing, but only saving when you ask it to.

A few things that surprised me in practice:

• The most useful captures aren't meetings or long recordings — they're short moments. A 2-minute conversation where you and someone else work through a problem together, or a quick aside that turns out to be the important part.
• Post-processing becomes more interesting when the input is conversational. Longer clips often contain multiple distinct ideas that could be split and routed separately rather than treated as one block of text.

I wrote up a longer description of the motivation and first real use case here: https://carlosurreta.com/2026/03/04/replay-buffer-for-handy/

My fork with feature: https://github.com/curreta/Handy/tree/feature/ring-buffer

Not proposing a PR — just wanted to put the idea somewhere visible in case others have felt the same friction or have thoughts on how something like this could work.

[AlexanderYastrebov]

There is a related Always-On Microphone debug feature:

Its an interesting idea but UX might be a bit challenging - a second shortcut (actually third if you count LLM post process and people ask for more e.g. to trigger different models) could be confusing. Maybe it could be a menu item or a tab where user can see and copy transcription for the last several minutes when it is needed (forgot to press transcribe). The transcription could run on-demand from the audio buffer only when needed.

[curreta]

The extra shortcut has for sure been a tradeoff. Expanding on your idea for improved logs, the transcription itself and where the post process flows to could also use a cleanup. I find there's a mental load when knowing whether I want to grab my transcription, the processed version, and whether I want it processed through a certain prompt for that given scenario.

My apologies, I included an out of date screen cap in the original post. I've implemented it with a dedicated post processing pipeline just for the replay "clips" since the context of "you're likely going to receive a scattered conversation of ideas in the past" vs the cleaner "transcribe this thought going forward" are different.
.

Thanks for taking a moment to ponder the idea, and for raising points on the challenging UX!

[cjpais]

Yeah, I just wanna say thank you for putting your idea and fork out here for visibility. Super encourage it. I don't think it will be pulled into the main app, but those who want this feature should definitely check out your fork.