Hi,
I think the newly added “Show the text only when I stop” option is one of the biggest improvements you have made to real-time transcription, and I want to explain why. I am also attaching a video with this feedback. Please try to reproduce the retry behavior; I tried to reproduce the same failure by turning my mobile data off, because I cannot reliably record the exact operational moment when the live model itself fails.
- Why “Show the text only when I stop” is such a big improvement
Now that real-time transcription has three options:
- Off
- Show the text while I speak
- Show the text only when I stop
I think the third option is extremely good.
Earlier, when I was using the second option — Show the text while I speak — the text was immediately coming into my text box, but it was also changing very frequently.
For example:
Sometimes the text would become English temporarily and then change to Hindi & vice versa
Sometimes capitalization would change.....
The text would constantly be rewritten/updated on textbox to update comma, capitalization because it was live.
Sometimes, if the microphone was ON and I clicked the Back button, some of the extra text would get deleted.
Sometimes the text would even become duplicated, Even like I spoke one time.
So it felt like the transcription was buffering directly inside my text box because everything was live.
But after switching to:
Show the text only when I stop
the experience is completely different.
It never keeps buffering/re-writing things inside my text box while I am speaking.
Instead, the transcription is happening in the background, and when I click Stop, the text is immediately thrown into the text box.
That is the best part.
The text is already available in the background, so when I stop, it comes through extremely smoothly and immediately.
Because I cannot see all the live/interim changes happening in the UI, it actually feels like I am using a normal non-live transcription model — except the result appears almost immediately when I stop.
So this option has made the real-time model feel much faster and much more stable, even though the underlying transcription is still happening live.
I really like this behavior.
👇👇👇👇👇👇👇👇
2. But there is a problem with Retry for live models
There is one thing I noticed.
Sometimes — very rarely — when I use "Show the text only when I stop" it throws nothing when I stop when I click Send....& it starts showing the Retry behavior. 1 2 3
I understand why this can happen because this is a live model & Maybe some because of technical glitch. Okay.
But my question is:
What exactly can Retry do in this situation?
As far as I understand, the live transcription is happening through the live model websockets, and if it fails, I don't think the original recording is currently being retained in a way that allows Retry to actually retranscribe it.
Even if the recording were kept, how would Retry send that recording back to the live model? (But. Because if. The same audio will be sent again to the same live model. Then it will again take equal time. Because it will do word by word)
The live model is meant for streaming, so sending the entire previous recording again to the live model would basically require doing the whole live process again and could take the full amount of time.
So in this situation, I feel the current Retry feature is not very useful here As per the implemented.
The same thing can also be seen from History.
If a recording failed while using a live model and I go to History and click Retry, it can keep showing Retry because there isn't really a usable recording available for the live model to retry from.
You can actually reproduce this behavior yourself by turning mobile data off while doing a live transcription. The recording will fail and you can see how Retry behaves.
👇👇👇
- My main suggestion: keep a separate recording even for live transcription
I think the solution is quite simple:
Let the live transcription work exactly as it works now, but simultaneously keep a separate audio recording of the same session.
So there would effectively be two things happening at the same time:
Microphone → Live model for real-time transcription
AND
Microphone → Separate local recording kept as a backup
The live model can continue working exactly as it currently does.
The backup recording would simply be there in case the live transcription fails or the user wants to retry the transcription with another model.
- What Retry should do with that recording
Then Retry becomes genuinely useful.
For example, suppose I have selected:
Google Gemini 3.5 Transcribe Live
and, for whatever reason, the live transcription fails.
When Retry appears, Dictate already has the audio recording.
So instead of trying to retry the same live session, Retry should send that saved recording to the normal transcription model.
For example:
Live model → Google Gemini 3.5 Transcribe Live
If that fails:
Retry → send the saved recording to a normal transcription model
This makes Retry actually meaningful.
- Retry would also be useful when the user simply doesn't like the live model result
This is not only about failures.
Suppose someone is using:
Show the text while I speak
The live model produces some text, but the user feels that the result is inaccurate or simply doesn't like the transcription....
They could go to History and press Retry.
Because Dictate has kept the original recording, Retry can send that same audio to a normal transcription model instead.
👇👇👇👇👇
Feedback (And I think it will be best)
Providing an extra option. As retry.And by default, the same model will get selected in the retry which is chosen for main transcription.
For example:
Main transcription → Google Gemini
Rewording → whatever model the user selected
Retry → Grok, for example
So the user can essentially say:
“I don't like what the live model produced. Try this same recording with another transcription model.”
That would make Retry much more useful than simply trying to reconnect to the same live model.
- For my specific case, this would solve the rare failure perfectly
In my case, when I use:
Show the text only when I stop
very rarely the live model doesn't produce anything and then Retry starts appearing/loading.
At that point I already know that the live transcription has failed.
But currently, I don't think Retry has much it can actually do because it doesn't have the recording available in a useful way.
Instead, if Dictate had kept the recording separately:
Live transcription fails
↓
Retry appears
↓
Use the already-recorded audio
↓
Send it to the selected Retry transcription model
↓
Text comes back
That would make the failure recoverable instead of effectively losing the transcription.
- Add a separate “Retry” provider/model selection
I also have one additional idea.
Inside Active providers, currently there are two options:
-
Transcription
-
Rewording
I think there could be a third option:
- Retry
So the user could independently select which model/provider should be used when Retry is triggered.
For example:
Transcription → Google Gemini
Rewording → whatever model the user wants
Retry → Grok
This gives the user complete control.
- Retry should automatically use the normal transcription model by default
However, the user should not be forced to configure another model.
By default:
Retry model = currently selected Transcription model
So if I have selected Google Gemini as my transcription model, Retry automatically uses Google Gemini too.
The user doesn't have to do anything.
But if the user wants to configure it, they can select a different provider/model for Retry.
This is especially useful when the primary provider has a problem.
For example:
Main transcription → Gemini
Retry → Grok
Then if Gemini fails because of:
API limit
API key problem
API key being blocked
API key quota being exhausted
or any other provider-side problem
the saved voice recording can instead be sent to the Retry provider.
So Retry becomes an actual fallback transcription path, rather than simply retrying the same failed live operation.
So, by giving an extra option to choose independent model for the retrial, it is beneficial here. The user is independent. To retry with another model here. Because if there is actually any problem in the API key. In the transcription model, then it will keep happening retry and retry.
- One more UI improvement: only show selectable models whose API key is configured
There is also something I noticed in Active providers.
When I tap Transcription, it currently appears that all available models can be shown, even when the required API key for a particular provider has not been configured.
So a user can potentially select a model for which they haven't even entered an API key.
I think it would be better if:
All models remain visible.
But models whose API key is not configured are muted/blurred/disabled.
Their Select button should also be disabled/muted.
Models for which the API key is already configured should appear at the top.
For example, suppose I have API keys configured for:
Grok
Gemini
Deepgram
Then these three could appear at the top and be selectable normally.
The other providers can still remain visible below them, but their selection button would be disabled/muted, communicating something like:
API key required to select this model.
This should apply consistently to:
Transcription
Rewording
Retry
So the user immediately understands which models are actually ready to use.
Overall idea
The main thing I am suggesting is not to change how your live transcription works.
The current live behavior — especially Show the text only when I stop — is excellent, and I would keep it exactly as it is.
The additional idea is simply:
Live transcription + separate backup recording
Then:
Live transcription continues normally.
The user gets the extremely fast background/live experience.
If the live model succeeds, everything works exactly as today.
If the live model fails, the saved recording can be sent to the Retry model.
If the user dislikes the live transcription, they can also manually Retry the same recording using another model.
By default, Retry uses the selected Transcription model.
Optionally, the user can choose a completely different provider/model for Retry.
That would make the Retry feature genuinely useful for live transcription instead of having a Retry action that has no meaningful audio to retranscribe.
Below is AI generated reference image
Hi,
I think the newly added “Show the text only when I stop” option is one of the biggest improvements you have made to real-time transcription, and I want to explain why. I am also attaching a video with this feedback. Please try to reproduce the retry behavior; I tried to reproduce the same failure by turning my mobile data off, because I cannot reliably record the exact operational moment when the live model itself fails.
Now that real-time transcription has three options:
I think the third option is extremely good.
Earlier, when I was using the second option — Show the text while I speak — the text was immediately coming into my text box, but it was also changing very frequently.
For example:
Sometimes the text would become English temporarily and then change to Hindi & vice versa
Sometimes capitalization would change.....
The text would constantly be rewritten/updated on textbox to update comma, capitalization because it was live.
Sometimes, if the microphone was ON and I clicked the Back button, some of the extra text would get deleted.
Sometimes the text would even become duplicated, Even like I spoke one time.
So it felt like the transcription was buffering directly inside my text box because everything was live.
But after switching to:
the experience is completely different.
It never keeps buffering/re-writing things inside my text box while I am speaking.
Instead, the transcription is happening in the background, and when I click Stop, the text is immediately thrown into the text box.
That is the best part.
The text is already available in the background, so when I stop, it comes through extremely smoothly and immediately.
Because I cannot see all the live/interim changes happening in the UI, it actually feels like I am using a normal non-live transcription model — except the result appears almost immediately when I stop.
So this option has made the real-time model feel much faster and much more stable, even though the underlying transcription is still happening live.
I really like this behavior.
👇👇👇👇👇👇👇👇
2. But there is a problem with Retry for live models
There is one thing I noticed.
Sometimes — very rarely — when I use "Show the text only when I stop" it throws nothing when I stop when I click Send....& it starts showing the Retry behavior. 1 2 3
I understand why this can happen because this is a live model & Maybe some because of technical glitch. Okay.
But my question is:
As far as I understand, the live transcription is happening through the live model websockets, and if it fails, I don't think the original recording is currently being retained in a way that allows Retry to actually retranscribe it.
Even if the recording were kept, how would Retry send that recording back to the live model? (But. Because if. The same audio will be sent again to the same live model. Then it will again take equal time. Because it will do word by word)
The live model is meant for streaming, so sending the entire previous recording again to the live model would basically require doing the whole live process again and could take the full amount of time.
So in this situation, I feel the current Retry feature is not very useful here As per the implemented.
The same thing can also be seen from History.
If a recording failed while using a live model and I go to History and click Retry, it can keep showing Retry because there isn't really a usable recording available for the live model to retry from.
You can actually reproduce this behavior yourself by turning mobile data off while doing a live transcription. The recording will fail and you can see how Retry behaves.
👇👇👇
I think the solution is quite simple:
So there would effectively be two things happening at the same time:
Microphone → Live model for real-time transcription
AND
Microphone → Separate local recording kept as a backup
The live model can continue working exactly as it currently does.
The backup recording would simply be there in case the live transcription fails or the user wants to retry the transcription with another model.
Then Retry becomes genuinely useful.
For example, suppose I have selected:
and, for whatever reason, the live transcription fails.
When Retry appears, Dictate already has the audio recording.
So instead of trying to retry the same live session, Retry should send that saved recording to the normal transcription model.
For example:
If that fails:
This makes Retry actually meaningful.
This is not only about failures.
Suppose someone is using:
The live model produces some text, but the user feels that the result is inaccurate or simply doesn't like the transcription....
They could go to History and press Retry.
Because Dictate has kept the original recording, Retry can send that same audio to a normal transcription model instead.
👇👇👇👇👇
Feedback (And I think it will be best)
Providing an extra option. As retry.And by default, the same model will get selected in the retry which is chosen for main transcription.
For example:
Main transcription → Google Gemini
Rewording → whatever model the user selected
Retry → Grok, for example
So the user can essentially say:
That would make Retry much more useful than simply trying to reconnect to the same live model.
In my case, when I use:
very rarely the live model doesn't produce anything and then Retry starts appearing/loading.
At that point I already know that the live transcription has failed.
But currently, I don't think Retry has much it can actually do because it doesn't have the recording available in a useful way.
Instead, if Dictate had kept the recording separately:
Live transcription fails
↓
Retry appears
↓
Use the already-recorded audio
↓
Send it to the selected Retry transcription model
↓
Text comes back
That would make the failure recoverable instead of effectively losing the transcription.
I also have one additional idea.
Inside Active providers, currently there are two options:
Transcription
Rewording
I think there could be a third option:
So the user could independently select which model/provider should be used when Retry is triggered.
For example:
Transcription → Google Gemini
Rewording → whatever model the user wants
Retry → Grok
This gives the user complete control.
However, the user should not be forced to configure another model.
By default:
So if I have selected Google Gemini as my transcription model, Retry automatically uses Google Gemini too.
The user doesn't have to do anything.
But if the user wants to configure it, they can select a different provider/model for Retry.
This is especially useful when the primary provider has a problem.
For example:
Then if Gemini fails because of:
API limit
API key problem
API key being blocked
API key quota being exhausted
or any other provider-side problem
the saved voice recording can instead be sent to the Retry provider.
So Retry becomes an actual fallback transcription path, rather than simply retrying the same failed live operation.
So, by giving an extra option to choose independent model for the retrial, it is beneficial here. The user is independent. To retry with another model here. Because if there is actually any problem in the API key. In the transcription model, then it will keep happening retry and retry.
There is also something I noticed in Active providers.
When I tap Transcription, it currently appears that all available models can be shown, even when the required API key for a particular provider has not been configured.
So a user can potentially select a model for which they haven't even entered an API key.
I think it would be better if:
All models remain visible.
But models whose API key is not configured are muted/blurred/disabled.
Their Select button should also be disabled/muted.
Models for which the API key is already configured should appear at the top.
For example, suppose I have API keys configured for:
Grok
Gemini
Deepgram
Then these three could appear at the top and be selectable normally.
The other providers can still remain visible below them, but their selection button would be disabled/muted, communicating something like:
This should apply consistently to:
Transcription
Rewording
Retry
So the user immediately understands which models are actually ready to use.
Overall idea
The main thing I am suggesting is not to change how your live transcription works.
The current live behavior — especially Show the text only when I stop — is excellent, and I would keep it exactly as it is.
The additional idea is simply:
Then:
Live transcription continues normally.
The user gets the extremely fast background/live experience.
If the live model succeeds, everything works exactly as today.
If the live model fails, the saved recording can be sent to the Retry model.
If the user dislikes the live transcription, they can also manually Retry the same recording using another model.
By default, Retry uses the selected Transcription model.
Optionally, the user can choose a completely different provider/model for Retry.
That would make the Retry feature genuinely useful for live transcription instead of having a Retry action that has no meaningful audio to retranscribe.
Below is AI generated reference image