Transcribe After the Meeting, Not During It (and What That Costs in Disk)

Short answer - should you turn it on?

• Yes, if your Mac is working hard during the call anyway. Screen share, a 12-person grid, Docker, a build running, or a fanless Air. The transcript can wait twenty minutes; the call can't.
• Yes, if you'd rather check the language before the words get made. A deferred take reads the language and speaker count at Transcribe time, so a Norwegian meeting that came in on the wrong setting is a picker change, not a re-run.
• No, if you want to watch the transcript fill in. That's a genuinely nice thing to have and this setting takes it away. That's the whole trade.
• No, if you don't want audio on disk. It needs audio retention turned on, because a deferred meeting exists only as audio until you transcribe it. On a Mac that stores no audio the setting can't do anything but destroy the recording, so it's inert there and Settings doesn't even show it.

Bias, up front: I make Humla, so this is a post about my own app's setting, written by the person who wrote the setting. Every number below is one you can check against the source.

What your Mac is actually doing during a live transcript

Here's the thing nobody puts on a landing page. When a local notetaker shows you the transcript filling in during the meeting, that is not a free feature. That is Whisper on your Metal GPU, chewing through a chunk of audio every few seconds, for as long as the meeting lasts.

Humla slices both audio streams at natural speech pauses using a voice-activity gate rather than a fixed timer, so chunks land somewhere between 1 and 15 seconds apart, and each one gets transcribed as it arrives. I wrote about the on-device Whisper path in detail here, including the rough realtime numbers: the Quality preset - beam search, width 5, which is the default because it's the right default for meetings - runs at somewhere around 2× realtime on an M-series chip.

Two-times realtime sounds fast. Turn it around, though. It means that for a one-hour meeting, your GPU is doing roughly half an hour of flat-out inference work, spread across the hour, while you are also on a video call. On an M4 Pro with headroom you will never notice this. On a fanless MacBook Air, with a screen share running and someone's slide deck animating, you might. And the failure mode is not "the transcript is slow" - it's "the call is worse", which is a much more annoying thing to trade for a feature you were going to read afterwards anyway.

(The GPU thing is also why this only applies to local Whisper. If you've pointed Humla at a cloud provider with your own key, the request goes out over the network and your machine does approximately nothing. Deferring there would trade a live transcript for no saving at all, which is a bad deal even by the standards of settings nobody reads.)

The setting

Settings → Recording → Audio retention → Transcribe manually. Shipped in v0.51.0, 20 August 2026. Off by default, and it lives behind a second switch that's also off by default, so getting here is a deliberate two-step:

That nesting is load-bearing rather than tidy. Deferring transcription means the meeting exists only as audio until you ask for text. On a Mac with retention off there is no audio after the recording stops, so the setting could only ever throw the meeting away. The obvious fix - quietly force-retain audio when this setting is on - is exactly the kind of hidden exception I spent a whole issue removing from this app, so no. The feature is inert while retention is off, the backend gate and the UI agree about that, and the toggle simply isn't shown.

The decision gets made once, when you hit Record, off two things: is this note's provider on-device Whisper, and is the setting on. Flipping the switch mid-meeting doesn't change a capture that's already running, because half a transcript is worse than either regime. And because the provider is resolved through the note's own language, a per-language override that routes today's note to a cloud provider keeps its live transcript while the Norwegian one next to it defers. That's either elegant or confusing depending on how many language overrides you've set up, and I'd like to hear from anyone who's in the confusing camp.

One thing that does still happen at Record time: the provider pre-check. Whisper model present, API key set, all of it. Finding out at Transcribe time that the model was never downloaded would mean you captured a meeting against a pipeline that was never going to work, and there is no version of that conversation I want to have.

What it looks like while you're recording

Mostly: like recording, minus the words. The bar runs, the elapsed clock runs, the two streams get written, and the Transcript tab shows a skeleton instead of text because there's nothing to stream into it.

When you stop, the note lands with its audio, no timeline, and a Transcribe button - in the toolbar next to Record, and again in the Transcript tab's empty state, where the text says "This recording hasn't been transcribed yet." rather than the default "start a recording to capture audio", because telling you to start a recording when the meeting is already sitting on your disk would be actively bad advice.

Pressing Transcribe

It replays each pending take's retained audio through the same decode → chunk → transcribe → diarize path that a file import uses. Oldest take first, because each take's timeline is numbered off the ones before it.

Three things make it not-a-recording, and all three are the kind of detail you only care about once it's bitten you:

• It never takes the live-capture slot. Replaying an hour of audio on yesterday's note does not stop you recording the meeting that just started. It refuses only for that note, with "This note is recording - stop the recording first.", because there its post-stop chain is about to rewrite the same transcript and two writers would race.
• It reports on its own per-note channel. A replay can't blank the recording bar of a capture running on a different note, which is the kind of thing you only get right by having separate channels rather than one shared one.
• The text arrives in one write at the end, rebuilt from every session's timeline, rather than streaming in chunk by chunk. So a replay that dies half-way leaves nothing behind that no timeline accounts for - and a newly transcribed take lands at its own position in the transcript even when a later take already has text.

Two smaller behaviours worth knowing, both chosen on purpose:

A diarize pass that can't run isn't treated as a failure here. The text lands without Speaker N: prefixes instead of being thrown away along with the labels, because this pass is what puts words in the note at all. Unlabelled words beat no words.

And a take that transcribed nothing is deliberately not marked as done. From where the code stands, "the room was silent" and "every chunk failed" look identical, and the second one has to stay retryable. So it stays pending and the button stays there.

The button also knows the difference between "this note has audio" and "this note has audio I can replay". A take that's been reduced to just its mixed playback file still has audio on disk and still can't be re-run, so it doesn't offer you an action that can only fail.

What it costs, in megabytes

This setting is a trade - a quieter Mac in exchange for audio sitting on disk - so the disk side deserves a real number rather than a shrug.

Humla's retained audio is 16 kHz mono 16-bit PCM, one WAV per source. That's 32,000 bytes a second, which works out at 1.92 MB a minute, per channel. The files on my own disk measure 1.84 MiB a minute, which is the same number wearing the other unit. For a remote call with both mic and system audio retained, that's about 230 MB an hour.

My own ~/Library/Application Support/no.humla.app/recordings folder is currently 14 GB. I have been running with retention on since I built it, and I have deleted approximately none of it. There's a "delete stored audio for existing notes" sweep in Settings for exactly this, and I should probably take my own advice.

(Yes, you could store this smaller. Opus at 24 kbps would put an hour of speech in about 10 MB and sound fine. The reason it's PCM is that both the replay path and the re-diarize path want raw samples, and a decode step between the disk and the model is one more thing to get wrong on a file you may only ever read once.)

So who should actually turn this on

Fewer people than the feature deserves, probably.

If you're on a machine with headroom and you like watching the transcript scroll, leave it off. It's a good feature. I built the live path first for a reason.

Turn it on if your Mac is already at the edge during calls, or if you record long sessions where the transcript genuinely isn't urgent - interviews, workshops, a day of client meetings you'll write up tomorrow. Turn it on if you want a second look at the language picker before an hour of Norwegian gets transcribed as English. And turn it on knowing it costs you a couple of hundred megabytes an hour, which is the part worth deciding on rather than discovering.