The fast transcription docs for MAI-Transcribe in LLM Speech API (updated 2026-07-21) say:
Optionally, for mai-transcribe-1.5, you can specify the style of the transcript output by using transcribeStyle. By default, the model returns a readability-optimized transcript. You can set the value to verbatim to preserve the original spoken content, including filler words and disfluencies.
We cannot reproduce this documented default. Observed behavior (region southeastasia, api-version=2025-10-15, AIServices resource, tested 2026-08-10 with filler-laden audio in Japanese and English):
- Omitting
transcribeStyle and sending "transcribeStyle": "verbatim" produce identical transcripts — filler words and disfluencies are preserved in both. This holds both for the pinned model ("model": "mai-transcribe-1.5") and for enhanced task mode ("task": "transcribe").
- Sending
"transcribeStyle": "readability" is rejected with HTTP 400: transcribeStyle must be 'verbatim' if specified.
- Net effect: the default is effectively verbatim, and there appears to be no way to obtain the documented readability-optimized output.
Repro (the doc's own request shape):
curl "https://<resource>.cognitiveservices.azure.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15" \
-H "Ocp-Apim-Subscription-Key: <key>" \
-F 'audio=@filler_sample.wav' \
-F 'definition={"locales":["en-US"],"enhancedMode":{"enabled":true,"model":"mai-transcribe-1.5"}}'
# -> transcript retains "um / uh / you know"; identical when "transcribeStyle":"verbatim" is added
# -> "transcribeStyle":"readability" -> 400 "transcribeStyle must be 'verbatim' if specified"
Why it matters: downstream integrators are building on the documented default. One public project shipped and then reverted a verbatim/readability toggle based on this exact doc text (ahmedmuhi/whisper-transcribe#70 -> #71). We integrate mai-transcribe-1.5 in a production dictation product and have paying users asking for the documented filler cleanup.
Questions:
- Has the readability-optimized style actually rolled out? If not, could the doc mark it as upcoming (or region-gated), and is there a timeline?
- If it exists behind a different request shape, api-version, or region, could that be documented?
For reference: we first reported this at Azure-Samples/cognitive-services-speech-sdk#3065, which was closed as out of scope for that repo (samples only) with a pointer to Azure support tickets; we don't have a paid support plan, so we're asking here.