I sampled capkiku every second through a 65-minute call. 17% of one core, 85 MB of RAM, and Brave did the expensive work.
Meeting recorders have a reputation for cooking the laptop. Fans, battery, a guest in the call, something uploading in the background.
I don't run that. As an SEO agency owner (goBOFU), I need my device to stay lean. There’s tons of stuff constantly running, including multiple sessions of Grok and Codex.
Before building capkiku, I used Audio Highjack, only for it to completely bog down my Mac and make it almost crash, eating away 4GB of RAM. What for?
Anyway, now I just hit Record Audio in the menu bar and leave the recording running.
For my most recent session, a 65-minute call with my client, it recorded two tracks, the client in Brave (Google Meet) plus my Tula mic, on capkiku 1.0.19, an M3 MacBook Air with 16 GB, macOS 26, sampled every second.
The recorder sat at 17% of one core, median 17.5%. Almost every second of the hour lived between 15 and 20%. Brave as a whole, every helper process included, sat around 73% of one core and spiked past three.
If the laptop got warm, that was the meeting.
What 65 minutes wrote
The audio is 1 hour 5 minutes 42 seconds. The charts run closer to 67 minutes because that is the monitor window, from the files appearing to pressing the Stop button. Others came out at 67.5 MiB and my own track at 72.0 MiB, both AAC at 48 kHz stereo. A 64 KB Markdown file sits next to them with an on-device transcript.
That is about 2 MB per minute, written at 37 KB/s, in a straight line. It did not buffer the hour in RAM and dump it at the end.
The app capkiku started around 97 MB idle, sat near 85 MB while recording, and peaked at 111 MB. RAM did not climb as the files grew. Idle used 16 threads, recording used 21, then it dropped back.
CPU-time for the hour was 699 seconds, 540 user and 159 system, which integrates to 17.4% of one core.
My app doesn’t need an account, and it doesn’t upload the captures. The files landed in a folder I already use as a knowledge base, and I review them before I save. Only thing it doesn’t do is diarization.
Of course, there are some network requests for updates, and on macOS 26 the speech model can initiate a download.
Stop, then the transcript
I hit Stop, and Review Audio showed up in about 12 seconds. The capkiku process barely moved: a few 7–26% flickers, RAM from 110 MB to 137 MB, then idle.
12 seconds is what you need for the on-device model to transcribe 65 minutes times two files, and the menu bar app did not look busy.
So where did the work go?
I ran Apple's SpeechAnalyzer again on the same two .m4a files from a small CLI, and sampled localspeechrecognition.xpc. LocalCapture stayed at 0%, and the XPC sat at about 1.2 cores and 150 MB across two processes.
That is the transcribe tax, it is Apple's process, not a second copy of the recorder.
The CLI replay took 82 seconds, not 12, and the first file logged a speech-model download. Don't mix those clocks. Use 12 seconds for what I waited after the call. Use the XPC chart for who burned the CPU.
I also ran powermetrics with sudo on that replay. Apple says these watts are estimates, so don't compare your Mac with them. The sample covers the first ~60 seconds of the 82-second replay.
Before transcribe, ANE sat at 0 W and combined CPU+GPU+ANE around 3 W. During transcribe, ANE was about 1 W and peaked at 3.1 W. CPU was about 10 W and peaked at 15 W. Combined was about 11 W and peaked at 18 W. Thermal went from Nominal to Moderate for a bit; corespeechd did nothing useful in the samples.
What I could not measure
The processes coreaudiod, audiomxd, and usbaudiod are SIP-blocked, so 17.5% is the capkiku process. The system audio tap may cost more inside Core Audio, and I don't have that number.
I don't have watts for the live hour, only for the transcription replay. Apple Energy Impact on the XPC averaged about 887, which is a dimensionless score, not watts.
The encode is more than voice needs
The writer targets 192 kbps stereo at 48 kHz, and voice does not need that. The mic file came out at 151 kbps of stereo speech, so mono and a lower bitrate on my own track would cut CPU and disk, and the other track can drop too. I’m not sure yet it’s worth optimizing that far.
The good news is that the session didn’t leak memory.
The rule
If your Mac is loud on a call, look at the browser first. That’s usually the bottleneck. But if you use also an app for transcription that brings it to its knees, there’s a better solution.
A recorder like capkiku can sit at 17% of one core for an hour. It writes two files into a folder you own, then gets out of the way.
Boring is good. Boring means it gets the job done fast and efficiently. Also, as a user said to me yesterday, the design is great—so not boring!
capkiku is free, menu bar, macOS 14+, Apple Silicon. capkiku.com
Top comments (0)