Transcribing on a plane

If transcription runs on somebody's server, "no connection" is not a topic. It is the end of the product, and there is nothing useful to say about it.

But the situation is completely ordinary. A plane. A train through a tunnel. A client's guest wifi behind a captive portal you cannot get past. A hospital, a courthouse, a construction site, a field interview two valleys from the nearest mast. So here is the practical version for a pipeline that runs on your own machine: what it genuinely needs the network for, what it does not, and what to do before you leave.

What a local pipeline needs the network for

Four things, none of which is your audio.

Model downloads, once. Speech and language models are files. They come down the first time you choose one and then they are yours — and they live in the app-data folder rather than in your vault, which is why a vault on a USB stick stays small. This is the only large transfer in the whole product and it is a one-off per model.

Licence checks, in the background. Activation talks to the payment provider once. After that the app re-checks quietly, never blocking anything you are doing, and a failed check is not treated as a failed licence.

Update checks. Ordinary application updates.

The lens registry, when you go looking for new lenses. Browsing a catalogue of prompts and schemas.

That is the list. Recording, transcription, speaker labelling, running a lens, searching the archive and playing anything back are all local operations on local files, so they behave identically at 38,000 feet and at your desk. Nothing in that list carries a recording, which is the same reason the network can be absent without breaking anything.

The grace period, stated plainly

The one thing worth knowing before a long trip is how the licence behaves when it cannot phone home.

You get 14 days of offline grace, which is part of what the licence promises rather than a courtesy. Beyond that the app asks you to get online once so the licence can re-check itself. Crucially, a check that fails to reach the server is never read as "no licence" — the only thing that blocks the app is an explicit rejection, meaning a key that has been revoked or has expired. A laptop that is simply offline never locks you out.

Fourteen days covers a holiday, a research trip, a conference week, a boat. It does not cover a season in Antarctica, and we are not going to pretend it does. If you are going somewhere with no connectivity for longer than a fortnight, connect once on the way out and once when you can, and plan the middle around that.

The pre-flight checklist

Five minutes at the gate, or ideally the night before.

Download the models you will actually use. Whichever speech model you have chosen, plus the local language model if you run summaries or lenses. A model you have never selected has never been downloaded. Pick it once on wifi and run one short recording end to end to confirm the whole chain works, rather than discovering at cruising altitude that the summary step was pointed at something that was never fetched.

Point any bring-your-own cloud model somewhere else, or accept it will not run. If you have connected a hosted provider for the language step, that step needs the internet by definition. Switch that lens to a local model before you go. This is the one genuine gotcha, because everything else keeps working and the failure looks arbitrary if you have forgotten the setting.

Check the grace clock. If the laptop has already been offline for a while, open it on wifi once before you leave.

Charge the phone if you are recording away from the laptop. The phone captures on its own and hands the take to the desktop over the local network later. No internet is needed for the handoff — the two devices only need to be on the same network, which a hotel wifi with no working uplink provides perfectly well.

Bring the microphone you would have brought anyway. Cabin noise is the real enemy on a plane, not connectivity, and no amount of local processing fixes a bad recording. Two people talking into a laptop's built-in array over engine noise will transcribe badly, on any tool, anywhere.

What it is actually like

Realistic expectations, since this is the part a marketing page would skip.

Transcription on battery is slower than transcription on mains, on every laptop, because the machine throttles. A local run that takes a few minutes plugged in takes longer on a plane, and it will warm the machine and cost you battery. That is the honest trade for the audio never leaving the tray table.

The workable pattern is to record on the flight and transcribe at the hotel, plugged in. Recording is cheap; transcription is the expensive step and it does not have to happen immediately. Nothing expires while it waits.

Speaker labelling and lenses run afterwards from the stored transcript, so you can do those on the ground too, in any order, as many times as you like.

Two people this actually matters for

Field researchers and journalists. Interviews happen where the story is, which is frequently somewhere with no bars — the practical version is in how journalists record interviews privately, and there are facet pages for journalists and researchers. A pipeline that needs to upload means either carrying the audio home unprocessed for days or paying for satellite data to send somebody's testimony to a server. A pipeline that runs locally means the transcript exists that evening, in the tent, and can be checked while the person is still reachable for a follow-up question.

Anyone working somewhere that bans the network. Secure facilities, some hospitals, some legal and government settings, plenty of manufacturing sites. In those buildings the question is not whether the vendor is trustworthy. The question is whether the device can be carried past the door at all, and a tool that must reach a server cannot be.

For both, "works offline" is not a row in a comparison table. It is the difference between a tool that can be used at all and one that cannot.