Why video editing should happen on your own Mac
There is a reasonable argument for doing video work in the cloud. Rendering is expensive, machine learning models are large, and a browser tab runs everywhere. Upload the footage, let a datacentre do the heavy lifting, get a link back.
The argument is reasonable and the trade is worse than it looks, particularly on a Mac built in the last few years.
The trade you are actually making
Uploading source media buys you compute you may not need and costs you four things that are easy to overlook until they bite:
Time to first edit. A forty-minute 4K recording is tens of gigabytes. On a normal domestic connection that is a wait measured in hours before you can do anything at all. The processing might be fast. Getting the file there is not.
Working offline. Editing on a train, in a hotel with hostile wifi, or on a plane is either impossible or degraded. This is not an edge case for anyone who travels.
A dependency on someone else's uptime. If the service is down, your footage is not editable. If the company shuts down, your projects are wherever their export function leaves them.
Where the footage sits. Unreleased material, client work under NDA, medical or legal recordings, anything with a face in it that has not consented to being on a third party's storage. For a lot of professional work this is not a preference, it is a contractual requirement.
What changed on the hardware side
The cloud argument was strongest when local machines could not run the models. That has shifted.
Apple silicon ships with a Neural Engine and unified memory, which is a genuinely good arrangement for this kind of work: the model and the media are in the same memory, so there is no copy across a bus before anything can start. Speech recognition models that needed a server a few years ago now run on a laptop faster than real time.
The practical result is that for the specific work of transcribing speech and cleaning up audio and video, the local machine is no longer the compromise option. Sending a file to a datacentre to do something your laptop can do while you wait for the upload to finish is a strange arrangement.
Local-first is not the same as offline-only
Worth being precise, because these get conflated.
Offline-only means the software refuses to use the network. That is rarely useful and usually just inconvenient - you cannot download a model, you cannot publish anything.
Local-first means the default place for your work is your machine, and network use is deliberate, specific and listed. Downloading a transcription model the first time you need one is a network call. So is uploading a finished export to somewhere you chose. Neither of those is your source footage leaving without you deciding it should.
The distinction matters because the second is achievable and the first is theatre.
How to check the claim
Any tool can say your data is safe. The useful question is what would have to be true for the claim to be false, and whether you can check it yourself.
For local processing there are a few things you can actually verify:
- Pull the network cable, or turn wifi off, and see what still works. If transcription runs with no connection, it is running locally.
- Watch the outbound network traffic with Little Snitch or similar while you import and edit. Source media is large, so a file leaving is not subtle.
- Check whether there is an account. A tool that holds your projects on a server needs to know who you are. One that does not, does not.
The third is the strongest signal. Sign-up requirements exist for a reason, and the reason is usually that something is being stored.
Where Rooster sits
Rooster is a Mac video editor that runs transcription and effects on the machine rather than a server, with no account and no project sync. It is in active development and not released yet.
We have written up the specifics of what runs where, including the short list of things that genuinely do use the network, on the how it works page. It is deliberately checkable rather than reassuring.