What on-device transcription costs on an iPhone

Aurora transcribes speech on the device that recorded it. Offline processing uses your phone's storage, memory and battery instead of somebody's server. Here is what we have measured on an iPhone 15 Pro, what Aurora actually puts on your phone, and what we have not measured yet — stated as "not measured yet" rather than estimated.

What this means for you

• Recording works immediately. A 75 MB recognizer ships inside the app, so the live transcript starts before anything is downloaded.
• Better models are a download. The recognizer Aurora fetches at onboarding is 145 MB; the speaker model is another 246 MB; the model that writes summaries and answers questions is 2.4 GB or more. You do not need all of them, and the app tells you the size before it starts.
• Re-processing after a meeting takes minutes, not hours. On the one device we measured, a one-hour recording takes roughly five minutes of Neural Engine work, in the background, chunk by chunk.
• Aurora will not flatten your battery to do it. That work is deferred below 20% battery while unplugged, with a notice and a control to run it anyway.

Why run speech recognition on the phone at all

Aurora runs speech recognition on the phone because sending audio to a server changes what the product is, not just where it computes. A recording that leaves the device becomes somebody else's asset: it exists in a log, it is subject to a retention policy written by a third party, and it can be produced under a request the speaker never hears about. Keeping the audio on the device removes that entire category of exposure rather than promising to manage it well.

The engineering case is narrower and worth stating honestly. On-device inference removes network latency from the live path, which is what makes a transcript that keeps up with the room possible at all. It also removes a per-minute marginal cost, which is why Aurora can be free during the beta without rationing minutes. Neither of those is the reason for the decision; both are consequences that make it affordable.

How fast it is, where we have measured it

Throughput here is a multiple of realtime: 12.4× means an hour of audio is processed in about four minutes fifty seconds of work. Two passes matter. The live pass has to keep up with speech as it happens. The offline refinement pass re-transcribes the saved recording at higher quality after the conversation ends, and its throughput is what decides how long you wait for the finished transcript.

One measured device is one measured device. On that iPhone, a one-hour recording is roughly five minutes of Neural Engine work, which is why Aurora runs refinement as a chunked background job that reports progress rather than a modal wait. Older iPhones are slower and we have not published a figure for them; a smaller recognizer tier is faster and we have not published a figure for that either.

An earlier version of this article printed throughput ranges for a Mac and for the live path. Neither could be traced to a run, so both are gone. What is left is the measurement that exists.

What Aurora puts on your phone

"Runs on your device" has a storage bill, and it is worth being exact about it rather than waving at "a one-time download". One recognizer ships inside the app so recording works on first launch; everything better than it is fetched, with the size shown before the transfer starts.

There is deliberately no single total in that table, because only one recognizer tier and one summary tier are active at a time and no device installs all of them. The summary model is picked from the phone's physical memory — an 8 GB-class device gets the larger one, a 6 GB device the faster one — and the recognizer defaults to whichever installed tier is best, moving up as better ones finish installing rather than asking you to choose. Before any transfer starts, the setup flow sums the bytes it is about to fetch and asks. Once the assets a device needs are installed, the recording and transcription path does not need the network.

The memory ceiling on iOS

Memory, not compute, is the binding constraint for speech models on iOS. An app is terminated by the system when it exceeds a per-process limit that varies by device and by what else is running — the mechanism generally called jetsam. A recognizer, a speaker model and an audio buffer held at once can approach that ceiling on older hardware, and the failure mode is not a slow transcript but a killed process mid-recording.

Aurora treats residency as a scheduling problem rather than hoping. Before the language model loads, a gate asks the system how many bytes the process may still allocate and refuses the load if the headroom is not there. The diarizer's catch-up path fetches audio in 60-second windows specifically so peak memory does not scale with recording length.

What we do not have is a number. No published measurement of Aurora's peak memory during recording or refinement exists, on any device, so this section describes mechanisms and not a figure. Not measured yet.

Battery, heat and Low Power Mode

Sustained on-device inference is more expensive than idle recording, and any claim otherwise should be treated with suspicion: the Neural Engine is efficient per operation, but running it for an hour is still an hour of compute that would otherwise not be happening. How much battery that costs per hour is not measured yet — we have no figure to publish, and will not invent one.

What is decided and implemented is the policy around it. Refinement runs immediately after a session, chunk by chunk so it stays interruptible, and is deferred when the battery is below 20% and the phone is unplugged — with a visible notice and a control to run it anyway rather than a silent stall. And iOS Low Power Mode genuinely slows the work: Aurora reads that state and says so in the setup banner, so a slow first setup reads as Low Power Mode rather than as a broken app.

When on-device transcription loses

On-device transcription loses in three specific cases, and Aurora does not pretend otherwise:

• The largest models. The highest-accuracy speech models do not fit comfortably on a phone. A server can always run a larger model than an iPhone can.
• Cold start. The first transcription after an install or an update pays a model load and, on some paths, an on-device compilation cost that a warm server never pays.
• Bulk historical processing. Transcribing a back catalog of hundreds of hours is a task a data center finishes in minutes and a phone finishes overnight.

None of those three is going to be argued away here. If you need a thousand hours transcribed by morning, use a server and accept what that means. Aurora is built for the conversation you just had, turned into a record nobody else holds.

Methods, and what is not measured

The throughput row above comes from one fixture run on one phone: 97.432 seconds of audio, decode 7.673 s, diarization 5.223 s, total refinement wall-clock 7.858 s, on an iPhone 15 Pro on 26 August 2026, with the 600 MB distil-large-v3-turbo recognizer and the community-1 offline diarizer, diarization enabled. 97.432 ÷ 7.858 = 12.4. The JSON file carries those fields, the asset list carries every size, and both name the source file in Aurora's repository for each figure.

Limits worth knowing before you rely on any of it:

• One run, one fixture, one device. 97 seconds is a short fixture for a throughput claim, and thermal state and Low Power Mode were not recorded for the run — both change the result.
• Model-dependent. That figure used the largest recognizer tier, not the onboarding default. A different tier is a different number.
• No independent verification. Every figure here is first-party and provisional.
• Not measured yet: live-path sustained throughput, end-to-end refinement on a Mac, refinement on any iPhone other than the 15 Pro, peak memory, and battery drain per hour.

Is Aurora a good fit for you?

Aurora fits when the conversations matter more than the throughput: interviews, meetings where decisions are made, lectures, appointments, working sessions. It fits badly if you need to process large archives quickly, or if you need automatic identification of named speakers — Aurora separates voices automatically but you name them yourself.

The honest summary: on-device transcription costs storage, a few minutes of background processing after a meeting, and the loss of the very largest models. What it buys is that the recording, the transcript, the speaker structure, the summary and the action items exist in one place — the device in front of you.

Published results

1. refinement-throughput-2026-08-26.csv and its JSON twin — the measured run, the two Mac decode comparisons, and an explicit list of what is not measured.
2. model-download-sizes-2026-09-18.csv and its JSON twin — every model asset, whether it ships or downloads, its size, and the source file each figure was read from.

References

1. Radford et al. Robust Speech Recognition via Large-Scale Weak Supervision. arXiv:2212.04356 — the Whisper architecture, from which several on-device speech models derive.
2. Xu et al. Efficient Sequence Transduction by Jointly Predicting Tokens and Durations. arXiv:2304.06795 — the token-and-duration transducer approach used for low-latency streaming recognition.
3. Apple. Core ML. developer.apple.com/documentation/coreml — compute unit selection across CPU, GPU and Neural Engine.
4. Apple. Reducing your app's memory use. developer.apple.com — iOS memory limits and termination behavior.