GPT-4o Transcribe Diarize is OpenAI's automatic speech-recognition model with built-in speaker diarization. It associates transcribed audio segments with different speakers in a conversation. The useful result is a transcript organized by speaker and time, rather than only a continuous block of words. It is intended for recorded speech that needs speaker labels, such as a meeting, interview or multi-person discussion.
Supply the recording that should be transcribed. The documented file workflow accepts MP3, MP4, MPEG, MPGA, M4A, WAV and WebM, with a file-size limit of 25 MB. Keep the source recording available so that a speaker turn, name or unclear phrase can be checked against the actual audio.
For a meeting, retain the conversation's sequence rather than cutting out the short pauses that help distinguish turns. For an interview, keep the question and response together when the task needs their relationship. Audio preparation should make the speech audible without removing information important to the speaker-labeled result.
This is a file-transcription workflow. Processing a completed recording and recognizing an audio stream that is still arriving are different tasks; the model's speaker labeling is not supported in Realtime transcription sessions.
The diarized_json result format returns segments with speaker identity labels and start and end timing. Each segment also contains its transcribed text. Keep those fields together so that the words can be connected to the relevant part of the recording.
For a useful meeting transcript, retain the segment sequence and display each speaker's words with their timing. A later task can use that transcript to prepare minutes or action items, but diarization itself does not decide what the meeting agreed or generate a verified summary.
Speaker labels describe the model's grouping of the speech. Inspect transitions where people interrupt each other, speak briefly or overlap. A well-structured result is helpful for navigation and review, while a particular attribution can still require listening to the original audio.
The documented workflow can accept up to four named speaker references. Each reference is a short audio clip of 2–10 seconds in a format supported by the main upload. The names and references are supplied together so that segments can be associated with known speakers.
Prepare a reference that clearly contains the intended speaker, and keep its name consistent with the transcript's intended labels. For an interview, a reference for the host can help organize the speaker-labeled result without turning every participant into an anonymous label. The reference is an input to attribution; it is not a general voice-cloning operation or proof of a person's identity.
Do not confuse naming a speaker with editing the words that were spoken. The useful output still needs to preserve the recording's content and the actual order of turns.
For audio longer than 30 seconds, the producer requires a chunking strategy, either automatic chunking or a voice-activity-detection configuration. That requirement is not a maximum recording duration. It describes how longer input is divided for processing.
The model card lists a 16,000-token context window and a maximum of 2,000 output tokens. These are model token limits, separate from the file workflow's 25 MB upload limit and the chunking threshold. They should not be converted into an invented number of minutes that applies to every recording.
Keep timing and segment identity when assembling or inspecting a longer transcript. If a recording has been split before submission, retain each part's relationship to the original audio so that a local timestamp is not confused with its position in the full conversation.
The file-transcription workflow can stream text while the recording is processed. With speaker-labeled streaming, completed segments produce segment events. Text deltas include a segment identifier, but they do not contain partial speaker assignments; a speaker is assigned when the segment is finalized.
This distinction matters for presentation. Show provisional text and a finalized speaker turn as different states rather than attaching an uncertain speaker label before the model has completed the segment. Preserve the completed result when the transcript is needed for later editing or analysis.
This profile is the diarization model, separate from ordinary GPT-4o transcription, Mini transcription, speech synthesis and live conversation models. It does not support transcription prompts; keep any terminology review or correction as a separate step checked against the original audio. Its producer interface is transcription of recorded audio into text. It does not generate an audio reply or translate a recording through the separate audio-translation workflow.
Use it for transcripts that need both content and speaker structure. Check names, technical terms, numbers, turn boundaries and attributions against the recording. Retain the audio, chosen result format, references and completed transcript so that a correction can address one concrete phrase or speaker assignment.
", "aboutText": "GPT-4o Transcribe Diarize is OpenAI's automatic speech-recognition model with built-in speaker diarization. It associates transcribed audio segments with different speakers in a conversation. The useful result is a transcript organized by speaker and time, rather than only a continuous block of words. It is intended for recorded speech that needs speaker labels, such as a meeting, interview or multi-person discussion.\n\n### Prepare the completed recording\n\nSupply the recording that should be transcribed. The documented file workflow accepts MP3, MP4, MPEG, MPGA, M4A, WAV and WebM, with a file-size limit of 25 MB. Keep the source recording available so that a speaker turn, name or unclear phrase can be checked against the actual audio.\n\nFor a meeting, retain the conversation's sequence rather than cutting out the short pauses that help distinguish turns. For an interview, keep the question and response together when the task needs their relationship. Audio preparation should make the speech audible without removing information important to the speaker-labeled result.\n\nThis is a file-transcription workflow. Processing a completed recording and recognizing an audio stream that is still arriving are different tasks; the model's speaker labeling is not supported in Realtime transcription sessions.\n\n### Request a speaker-labeled transcript\n\nThe `diarized_json` result format returns segments with speaker identity labels and start and end timing. Each segment also contains its transcribed text. Keep those fields together so that the words can be connected to the relevant part of the recording.\n\nFor a useful meeting transcript, retain the segment sequence and display each speaker's words with their timing. A later task can use that transcript to prepare minutes or action items, but diarization itself does not decide what the meeting agreed or generate a verified summary.\n\nSpeaker labels describe the model's grouping of the speech. Inspect transitions where people interrupt each other, speak briefly or overlap. A well-structured result is helpful for navigation and review, while a particular attribution can still require listening to the original audio.\n\n### Known-speaker references\n\nThe documented workflow can accept up to four named speaker references. Each reference is a short audio clip of 2–10 seconds in a format supported by the main upload. The names and references are supplied together so that segments can be associated with known speakers.\n\nPrepare a reference that clearly contains the intended speaker, and keep its name consistent with the transcript's intended labels. For an interview, a reference for the host can help organize the speaker-labeled result without turning every participant into an anonymous label. The reference is an input to attribution; it is not a general voice-cloning operation or proof of a person's identity.\n\nDo not confuse naming a speaker with editing the words that were spoken. The useful output still needs to preserve the recording's content and the actual order of turns.\n\n### Chunking and model limits\n\nFor audio longer than 30 seconds, the producer requires a chunking strategy, either automatic chunking or a voice-activity-detection configuration. That requirement is not a maximum recording duration. It describes how longer input is divided for processing.\n\nThe model card lists a 16,000-token context window and a maximum of 2,000 output tokens. These are model token limits, separate from the file workflow's 25 MB upload limit and the chunking threshold. They should not be converted into an invented number of minutes that applies to every recording.\n\nKeep timing and segment identity when assembling or inspecting a longer transcript. If a recording has been split before submission, retain each part's relationship to the original audio so that a local timestamp is not confused with its position in the full conversation.\n\n### Streaming finalized segments\n\nThe file-transcription workflow can stream text while the recording is processed. With speaker-labeled streaming, completed segments produce segment events. Text deltas include a segment identifier, but they do not contain partial speaker assignments; a speaker is assigned when the segment is finalized.\n\nThis distinction matters for presentation. Show provisional text and a finalized speaker turn as different states rather than attaching an uncertain speaker label before the model has completed the segment. Preserve the completed result when the transcript is needed for later editing or analysis.\n\n### Model and output boundaries\n\nThis profile is the diarization model, separate from ordinary GPT-4o transcription, Mini transcription, speech synthesis and live conversation models. It does not support transcription prompts; keep any terminology review or correction as a separate step checked against the original audio. Its producer interface is transcription of recorded audio into text. It does not generate an audio reply or translate a recording through the separate audio-translation workflow.\n\nUse it for transcripts that need both content and speaker structure. Check names, technical terms, numbers, turn boundaries and attributions against the recording. Retain the audio, chosen result format, references and completed transcript so that a correction can address one concrete phrase or speaker assignment.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "06f8d8f55ba9709096ccd3d08295d9cf351739b826c49fd43c5849fec988d18e", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "openai/gpt-4o-transcribe-diarizeGPT-4o Transcribe Diarize converts recorded speech into text with speaker-labeled segments and timing. It suits meetings, interviews and multi-person recordings where the transcript must show who spoke when, with optional short voice references for known speakers.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
GPT-4o Transcribe Diarize is OpenAI's automatic speech-recognition model with built-in speaker diarization. It associates transcribed audio segments with different speakers in a conversation. The useful result is a transcript organized by speaker and time, rather than only a continuous block of words. It is intended for recorded speech that needs speaker labels, such as a meeting, interview or multi-person discussion.
Supply the recording that should be transcribed. The documented file workflow accepts MP3, MP4, MPEG, MPGA, M4A, WAV and WebM, with a file-size limit of 25 MB. Keep the source recording available so that a speaker turn, name or unclear phrase can be checked against the actual audio.
For a meeting, retain the conversation's sequence rather than cutting out the short pauses that help distinguish turns. For an interview, keep the question and response together when the task needs their relationship. Audio preparation should make the speech audible without removing information important to the speaker-labeled result.
This is a file-transcription workflow. Processing a completed recording and recognizing an audio stream that is still arriving are different tasks; the model's speaker labeling is not supported in Realtime transcription sessions.
The diarized_json result format returns segments with speaker identity labels and start and end timing. Each segment also contains its transcribed text. Keep those fields together so that the words can be connected to the relevant part of the recording.
For a useful meeting transcript, retain the segment sequence and display each speaker's words with their timing. A later task can use that transcript to prepare minutes or action items, but diarization itself does not decide what the meeting agreed or generate a verified summary.
Speaker labels describe the model's grouping of the speech. Inspect transitions where people interrupt each other, speak briefly or overlap. A well-structured result is helpful for navigation and review, while a particular attribution can still require listening to the original audio.
The documented workflow can accept up to four named speaker references. Each reference is a short audio clip of 2–10 seconds in a format supported by the main upload. The names and references are supplied together so that segments can be associated with known speakers.
Prepare a reference that clearly contains the intended speaker, and keep its name consistent with the transcript's intended labels. For an interview, a reference for the host can help organize the speaker-labeled result without turning every participant into an anonymous label. The reference is an input to attribution; it is not a general voice-cloning operation or proof of a person's identity.
Do not confuse naming a speaker with editing the words that were spoken. The useful output still needs to preserve the recording's content and the actual order of turns.
For audio longer than 30 seconds, the producer requires a chunking strategy, either automatic chunking or a voice-activity-detection configuration. That requirement is not a maximum recording duration. It describes how longer input is divided for processing.
The model card lists a 16,000-token context window and a maximum of 2,000 output tokens. These are model token limits, separate from the file workflow's 25 MB upload limit and the chunking threshold. They should not be converted into an invented number of minutes that applies to every recording.
Keep timing and segment identity when assembling or inspecting a longer transcript. If a recording has been split before submission, retain each part's relationship to the original audio so that a local timestamp is not confused with its position in the full conversation.
The file-transcription workflow can stream text while the recording is processed. With speaker-labeled streaming, completed segments produce segment events. Text deltas include a segment identifier, but they do not contain partial speaker assignments; a speaker is assigned when the segment is finalized.
This distinction matters for presentation. Show provisional text and a finalized speaker turn as different states rather than attaching an uncertain speaker label before the model has completed the segment. Preserve the completed result when the transcript is needed for later editing or analysis.
This profile is the diarization model, separate from ordinary GPT-4o transcription, Mini transcription, speech synthesis and live conversation models. It does not support transcription prompts; keep any terminology review or correction as a separate step checked against the original audio. Its producer interface is transcription of recorded audio into text. It does not generate an audio reply or translate a recording through the separate audio-translation workflow.
Use it for transcripts that need both content and speaker structure. Check names, technical terms, numbers, turn boundaries and attributions against the recording. Retain the audio, chosen result format, references and completed transcript so that a correction can address one concrete phrase or speaker assignment.
POST /v1/audio/transcriptionsaudiotranscription| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits openai/gpt-4o-transcribe-diarize | Default— |
Fieldfile | Typefile | RequirementRequired | Values & limits Maximum bytes: 26,214,400 MIME types: audio/mpeg File extension: .mp3 Maximum duration, seconds: 30 | Default— |
Fieldresponse_format | Typestring | RequirementRequired | Values & limits diarized_json | Default— |
diarized_transcription
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractmultipart/form-data |
Parameterrequired | Contractmodel, file, response_format |
Parameterfile_formats | Contractmp3 |
Parametermax_audio_seconds | Contract30 |
Parametermax_bytes | Contract26214400 |
Parameterresponse_format | Contractdiarized_json |
Parameterother_options | Contractfalse |
Parametermaterial_types | Contractaudio |
Parameteradditional_properties | Contractfalse |
Parameterform_string_maximum_bytes | Contract256 |
Method aliases: /audio/transcriptions
Lifecycle: synchronous_result_then_owned_library
GET /v1/media/tasks/{task_id} · actual returned task_id or media library record
GET /v1/media/assets/{asset_id}/content
GET /v1/media/assets
GET /v1/media/assets/{asset_id}
Use actual recording and matching format.
Preserve full transcript, segments, speaker IDs and timing.
Tariff references do not add request options. Supported parameters are listed for the selected method.
Match each charge to the conditions shown. Use one rate for each set of alternative configurations.
| Configuration | Rate schedule | Billing unit | Charge |
|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Billing unit— | Charge Input · Input tokens — / 1K tokens Output · Output tokens — / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| ConfigurationUltra | Rate schedule— | Billing unit/ 1K audio tokens | Charge Input · audio input token $0.012 / 1K audio tokens |
| ConfigurationUltra | Rate schedule— | Billing unit/ 1K audio tokens | Charge Output · audio output token $0.02 / 1K audio tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_AUDIO_FILE:?Set the path to your actual MP3 recording}"\nexport AILOOT_AUDIO_FILE\npython3 - <<'PY_REQUEST'\nimport os\nfrom pathlib import Path\np=Path(os.environ["AILOOT_AUDIO_FILE"])\nif not p.is_file() or p.suffix.lower()!=".mp3":raise SystemExit("Choose an existing MP3 recording")\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/audio/transcriptions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" \\\n --form-string model=openai/gpt-4o-transcribe-diarize -F "file=@$AILOOT_AUDIO_FILE" --form-string response_format=diarized_json \\\n -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path("result.json").read_text())))\nPY_RESULT\njson
GET /v1/media/tasks/{task_id}GET /v1/media/assets/{asset_id}/contentGET /v1/media/assetsGET /v1/media/assets/{asset_id}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nexport AILOOT_API_KEY\npython3 - <<'PY_ASSETS'\nimport json,os,subprocess\nfrom pathlib import Path\nfrom urllib.parse import urljoin,urlsplit\nr=json.loads(Path('result.json').read_text())\nurls=[]\nif isinstance(r.get('asset_url'),str) and r['asset_url']:urls.append(('transcript',r['asset_url']))\nfor label,path in urls:\n u=urljoin('https://api.ailoot.ai',path);z=urlsplit(u)\n if z.scheme!='https' or z.netloc!='api.ailoot.ai' or z.username or z.password:raise SystemExit('Use the actual returned Ailoot owned content URL')\n target=Path('owned-'+label+'.bin')\n subprocess.run(['curl','--fail-with-body','--silent','--show-error',u,'-H','Authorization: Bearer '+os.environ['AILOOT_API_KEY'],'-D',str(target)+'.headers','-o',str(target)],check=True)\nprint('All returned owned URLs saved; complete metadata, timing and usage remain in the JSON.')\nPY_ASSETS\nset -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/media/assets \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -o media-assets.json\nset -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_MEDIA_TASK_ID:?Set the actual ID returned by the response or media-library metadata}"\nexport AILOOT_MEDIA_TASK_ID\nresource_id=$(python3 -c 'import os,urllib.parse;print(urllib.parse.quote(os.environ["AILOOT_MEDIA_TASK_ID"],safe=""))')\ncurl --fail-with-body --silent --show-error "https://api.ailoot.ai/v1/media/tasks/$resource_id" \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -o media-task.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path("media-task.json").read_text())))\nPY_RESULT\nset -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_ASSET_ID:?Set the actual ID returned by the response or media-library metadata}"\nexport AILOOT_ASSET_ID\nresource_id=$(python3 -c 'import os,urllib.parse;print(urllib.parse.quote(os.environ["AILOOT_ASSET_ID"],safe=""))')\ncurl --fail-with-body --silent --show-error "https://api.ailoot.ai/v1/media/assets/$resource_id" \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -o media-asset.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path("media-asset.json").read_text())))\nPY_RESULT\nKeep every complete returned response, file and content part.
Retain complete JSON, not only text; preserve every available segment/speaker/timestamp and actual task/asset identity.
Retain original operation_id/X-Client-Request-ID for reconciliation without resubmission; no dedicated audio poll route.
| Field | Type |
|---|---|
Fieldtext | Typestring |
Fieldsegments[] | Typeobject |
Fieldtask_id | Typestring |
Fieldasset_url | Typestring |
Fieldusage | Typeobject |
Fieldsegments[].speaker | Typestring |
Fieldsegments[].start | Typenumber |
Fieldsegments[].end | Typenumber |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Responseserver_error | ConditionThe returned response says the operation or result requires a check | Next stepKeep the original returned operation/task ID, request headers and response; continue supported reads of that original operation. Do not resubmit the creation request. |
Ailoot Ultra openai/gpt-4o-transcribe-diarize
/audio/transcriptions