[macOS 26.5][26.727.51351] Composer dictation takes 3–17 seconds while ChatGPT Classic is fast

Start at the composer dictation microphone entry point and trace the completed-recording batch transcription request, comparing it with the low-latency path described here. Done means short phrases return promptly and consistently after recording stops, with an explicit transcription-in-progress state throughout the server wait.

What version of the Codex App are you using (From “About Codex” dialog)?

26.727.51351 (build 6119)

What subscription do you have?

Paid ChatGPT subscription (exact tier omitted)

What platform is your computer?

Darwin 25.5.0 arm64 arm

MacBook Pro with Apple M4 Pro.

What issue are you seeing?

Composer dictation in the current unified ChatGPT/Codex macOS app records audio normally, but after recording stops, transcription of even a very short phrase takes a highly variable 3–17 seconds before text appears.

This reproduces both when dictation is started from the app's microphone control and when it is started by a Codex Micro hardware button. Starting dictation directly from the app is equally slow, so the hardware is not the cause.

A same-machine A/B test is decisive: ChatGPT Classic transcribes the same short phrases much faster using the same Mac, account, microphone, network, and test session.

Local timing instrumentation isolated the delay:

• recording startup: approximately 124 ms
• recording stop/finalization: approximately 24 ms
• successful batch transcription response waits: approximately 3.0 s, 4.4 s, and 16.95 s
• the slow requests returned successfully; the delay was waiting for transcription, not local audio capture

The unified app appears to use the completed-recording batch transcription path for this session rather than a low-latency streaming path. The large fixed and variable post-stop delay makes short dictation feel broken even when it eventually succeeds.

Observed August 3–4, 2026 (Europe/Berlin).

What steps can reproduce the bug?

1. Open the current unified ChatGPT desktop app and enter a Codex task.
2. Start composer dictation using the microphone button.
3. Speak a short phrase such as “One, two, three.”
4. Stop recording.
5. Measure the time until editable text appears in the composer.
6. Repeat several times. The post-stop wait varies from roughly 3 seconds to more than 15 seconds.
7. Open ChatGPT Classic on the same Mac and dictate the same short phrase.
8. Observe that Classic returns the transcript much faster.

The slow behavior also reproduces when the Codex Micro starts dictation, but the hardware is not required.

What is the expected behavior?

Short composer dictation should be transcribed promptly and consistently after recording stops, ideally with latency comparable to ChatGPT Classic on the same account and machine.

The app should also show an explicit transcription-in-progress state for the entire server wait.

Additional information

Troubleshooting already performed:

• Confirmed microphone capture and recording finalization are fast.
• Confirmed macOS microphone permission is granted.
• Confirmed ordinary app/network requests are responsive.
• Confirmed no VPN, proxy, or local network filter is active.
• Restarted and retested the current app.
• Confirmed the installed app was the latest public build available during testing.
• Reproduced without relying on the Codex Micro hardware.
• A/B tested against ChatGPT Classic immediately afterward; Classic is much faster.

Related but distinct reports:

• #35677 — unified app transcription fails while ChatGPT Classic works on the same Mac/account
• #33989 — no transcription progress indicator after dictation stops
• #35508 — realtime GPT-Live transcription slows during longer sessions; this report concerns ordinary short composer dictation

This report is distinct from #35677 because transcription usually succeeds here; the defect is severe and highly variable turnaround latency. No raw audio or unsanitized logs are attached for privacy.