Retry a dictation that failed

Agents: claude, codex, opencode · On: phone, desktop · optional

When the clip does not reach your workstation because the connection dropped, the app sends it again by itself: after 2, 5 and 10 seconds. If the third retry fails too, or the transcription fails for another reason, the clip you just recorded is kept in memory for five minutes. The mic turns into a retry arrow, and one tap sends the same clip again.

Why you would use it

You dictate on a train and the signal drops while the clip is on its way. The app tries again on its own, and the words land when the connection comes back. If the service was down for longer, or your login had expired, you said the words once; the retry sends the same recording rather than making you say them again.

How to use it

Nothing to do while the app retries by itself. The mic shows the upload arrow, breathing, labelled Connection lost, trying again (1 of 3), then 2 of 3 and 3 of 3. No toast shows until the retries are used up.

A failed transcription shows a toast: <what failed>. Tap the mic to retry.
The mic (#mic) becomes a retry arrow, labelled Retry the transcription that failed.
Tap it on the tab you recorded in. The kept clip goes again. Nothing is recorded by that tap. On every other open tab the mic is dimmed and disabled, labelled Dictating in another tab. If the recording tab was closed, the tab in front takes the retry and the words land there.
If it fails again, the clip is kept again and the arrow stays.

Starting a new recording is not possible while a clip is kept. The tap sends the kept clip, and the other tabs' mics are disabled until it goes. To drop it, wait five minutes, or let a successful transcription clear it.

What you see

Messages that can reach the toast, each followed by . Tap the mic to retry:

the voice service is not answering: the transcription service is down, unreachable, or took more than 60 seconds.
the voice service refused the clip (400) and the service's own wording for 400, 413, 415 and 422.
dictation accepts audio/webm, video/webm, audio/mp4, video/mp4, audio/x-m4a, audio/ogg, audio/wav, not <type>: the browser recorded a container the server does not take.
the voice service answered without a transcript.

When the five minutes pass with no retry, the button goes back to the plain mic icon on its own.

A box that refuses this device (a 401 or 403) fails the upload like any other error: the clip is held for one retry.

Options and settings

Option	Default	What it changes
`RETRY_DELAYS_MS` in `public/voice.js`	2 s, 5 s, 10 s	The waits before each automatic resend. Three resends. Not configurable
`RETRY_TTL_MS` in `public/voice.js`	`300000` (5 minutes)	How long a failed clip is offered for a retry. Not configurable
`REQUEST_TIMEOUT_MS` in `lib/voice.js`	`60000`	How long VCode waits on the transcription service before calling it unreachable
`UPLOAD_TIMEOUT_MS` in `public/net.js`	`120000`	How long the phone waits for VCode to return the text

Limits and known gaps

One clip is kept at a time. A new recording replaces it, and a successful transcription clears it.
The clip is held in memory only. A page reload, a closed tab or a killed app loses it.
Only a clip that did not get through is sent again by itself: a dropped connection, an upload that ran out of time, or a 502, 503 or 504 on the way. A clip the service refused, an expired login and a cancel are not.
There is no outbox. Speech is not worth sending an hour late, so store.transcribe() is deliberately not an outbox item. The automatic retries end about 17 seconds after the first failure, plus the time each try takes.
An upload that runs out of time waits the full 120 seconds before its retry, so a connection that hangs instead of dropping takes up to 8 minutes to use up the three retries.
A refused microphone is not retryable this way: it is toasted once and no clip exists.
The tap is still refused while the app is offline, with offline: dictation needs the server.