ReMynddoes screen recording slow down your mac?
on apple silicon, not in any way you will notice, and the number people worry about is the wrong one.
everyone asks about cpu. cpu turns out to be nearly free, because the hard part runs on dedicated media hardware. the costs that actually bite are disk and battery, and both are design choices rather than laws of physics.
nobody publishes real figures for this, so we measured it. here is the method, the numbers as of september 2026, and what they mean for a machine you actually work on.
the method
we sampled a continuously running screen recorder with ps every 5 seconds for 104 consecutive readings, roughly 9 minutes, during ordinary desktop use.
- machine: apple m5, 10 cores, macos 26.6.2
- workload: normal use during the sample, not an idle desktop and not a stress test
- what is measured: the main recorder process, plus its helper processes
one caveat that matters for reading the numbers: macos reports %cpu per core, so 100% means one full core saturated, not the whole machine. on a 10 core m5, dividing by 10 gives the share of the machine.
this is a single machine over a single session. it is not a fleet study, and your mileage will vary with display count, frame rate and what else is running. treat it as a real data point rather than a benchmark, which is more than the 0 published figures the rest of the category offers.
the cpu numbers
screen recording cpu usage was low and bursty, which is exactly the shape you want.
| measure | share of one core | share of a 10 core m5 |
|---|---|---|
| median | 1.05% | 0.11% |
| mean | 3.96% | 0.40% |
| 90th percentile | 9.8% | 0.98% |
| peak | 72.6% | 7.3% |
the median is the number to hold onto. half the time the recorder used about 1% of a single core, which on a 10 core machine is roughly one part in a thousand. the mean sits nearly 4x higher than the median, and that gap is the whole story: this is not a constant load, it is mostly idle with short spikes.
the 72.6% peak looks alarming until you notice it lasted one 5 second sample. that is capture, ocr and indexing happening to land in the same instant. a spike to three quarters of one core for a few seconds is invisible on a machine with 9 other cores.
for comparison, a single busy browser tab running a modern web app will routinely hold more than 1% of a core for minutes at a time.
the memory numbers
screen recording memory usage was steady, which matters more than the absolute figure.
| measure | resident memory |
|---|---|
| median | 121mb |
| mean | 149mb |
| peak | 343mb |
the helper processes are rounding errors: an xpc communication agent at about 4.8mb, a local redis instance at about 2mb, and a python runtime at about 9.3mb. total helper overhead is under 20mb.
121mb is roughly two browser tabs. on a machine with 16gb that is 0.7% of memory, and on 32gb it is 0.4%. the important property is that it plateaued rather than climbing across the sample, because a background app that grows steadily has a leak, and a leak is what eventually makes a mac feel slow.
why the cpu cost is so low
because the expensive part is not running on the cpu.
apple silicon ships a dedicated media engine for video encoding, and a neural engine for the machine learning work. a well built recorder uses screencapturekit for capture and hands encoding to the media engine, then runs ocr on the neural engine through the vision framework. the general purpose cores mostly coordinate.
that is why "does screen recording slow down your mac" has a different answer in 2026 than it did in 2019. on an intel mac, encoding fell to the cpu and the answer was yes. on apple silicon the work moved to hardware built for it.
the same shift is why microsoft could ship recall on copilot+ pcs at all: those machines are specified with a neural processing unit rated at 40+ trillion operations per second, precisely so continuous capture and on device analysis do not land on the cpu. apple made the same bet earlier, putting the neural engine in every m series chip. google, openai and anthropic went the other way and run their vision work in the cloud, which costs you latency and a network round trip instead of local watts.
| where the work runs | cpu cost to you | per image cost | data leaves the machine |
|---|---|---|---|
| media engine and neural engine, on device | near zero | zero | no |
| general purpose cpu, on device | high | zero | no |
| a cloud vision model | near zero | metered | yes |
three implementation choices still separate a good recorder from a bad one:
- focused window versus every pixel. capturing one window rather than 2 full displays is a large constant factor on every stage downstream.
- frame skipping. if nothing changed, there is nothing to encode, ocr or index. a recorder that processes identical frames is doing all the work for none of the benefit.
- batched writes. writing continuously keeps the ssd awake. batching lets it idle.
the cost that is actually real
disk is where continuous recording genuinely costs you something.
we measured a working install across 17 days of capture. it held 26gb. video was roughly 24.6gb, about 95% of the total. the searchable index, the ocr text and its metadata, was 1.4gb, about 5%. that is roughly 1.5gb per recorded day.
extrapolate and the shape is clear. a year of searchable index runs around 20gb. a year of the video it came from runs around 360gb, about 18x more for the part you almost never replay.
it is worth asking what that disk buys. per the anthropic economic index for may 2026, searching electronic sources is the single most common work task in sampled claude conversations at 4.95%, with reference searching second at 3.74%. yet knowledge retrieval and enterprise search is only 3.61% of conversations and conversation and meeting intelligence just 0.26%, because almost nobody has an index of their own work to search. 1.5gb a day is the price of having one.
this is why retention settings matter more than any performance tuning. keeping 30 days of video and years of index gives you nearly all the recall at a small fraction of the disk. the full working is in screen recording storage on a mac.
battery, which the cpu numbers understate
on a laptop the battery cost is larger than 0.4% of the cpu would suggest.
continuous capture prevents components from reaching their deepest idle states. the media encoder stays warm, the ssd wakes to write, and the whole system spends less time in the low power modes that make apple silicon laptops last a day. the drain comes from keeping things awake rather than from raw computation, so it does not show up in a cpu percentage at all.
the practical levers are the same three as above. capturing the focused window rather than every display, skipping unchanged frames, and batching writes all reduce wake ups, and wake ups are what cost battery.
if you work unplugged for long stretches, the honest advice is to check your own numbers over a few days rather than trust anyone's benchmark, including this one.
how to measure it yourself
mac performance monitoring is a 2 minute job, and you should trust your own numbers over ours.
- open activity monitor, or run
ps -Ao pid,pcpu,rss,comm | grep -i <app>in terminal. this is the only reliable way to read background app cpu on a mac. - sample repeatedly rather than once. a single reading catches a spike and tells you nothing.
- remember
%cpuis per core. divide by your core count for the share of the machine. - watch resident memory across an hour. flat is healthy, a steady climb is a leak.
- check the energy tab in activity monitor for the battery picture, because cpu percentage will not show it.
point 2 is the one people skip, and it is why screen recorders get a bad reputation. open activity monitor at the exact moment a recorder is indexing and you will see a scary number that was true for 3 seconds.
where remynd sits
remynd records the focused window on a mac rather than every pixel of every display, which is the single biggest reason the numbers above are small. ocr runs locally on the neural engine through apple's vision framework, and the index stays on your machine.
the sample in this post came from a development build on an m5 running normal desktop work. the scope, stated exactly: focused window capture, local ocr and storage, recordings default to 30 days of retention, app and site exclusions, and history that is read only everywhere in the app. call transcription runs on device using an mlx speech model on apple silicon.
what it does not do: asking a question sends the retrieved slices to a cloud model, so this is not a claim that nothing ever leaves the machine.
if you want the category rather than the performance question, start with screen memory. if you are weighing the privacy architecture, read private ai on your mac. for how the ocr step works, see what is ocr.