Build a two-stage audio pipeline: transcribe a spoken audio file to text, then summarize that transcript with a chat model. Speech in, summary out.
Most audio applications are really two steps glued together: a transcription model turns sound into text, and a language model does something useful with the text. Keeping them separate means you can swap the transcription model or the summarizer independently, and you can inspect the transcript when the summary looks wrong.
The transcript reflects the spoken words, and the summary condenses it.
The transcription model and the chat model do different jobs and are called independently, with the transcript as the hand-off between them. Opening the file in binary mode ("rb") is what the transcription API expects. Because the stages are decoupled, you can upgrade transcription accuracy or change the summary style without touching the other half, which is the practical reason to build audio features as a pipeline rather than one opaque call.
Summaries are useful, but structured output from audio is more so. Transcribe a meeting recording, then pull out the action items as a structured list instead of prose. This is the audio-to-data pipeline behind meeting assistants and call-center analytics.
action_items list.The transcript is turned into a clean, numbered list of action items.
Chaining transcription into a structured-extraction call turns speech directly into data your application can act on, not just a paragraph someone has to read. Requesting JSON with response_format makes the action items a list you can store as tasks or send to a tracker. The two stages stay independent, so you can improve transcription accuracy or change what you extract without touching the other. It needs a real audio file and a transcription-capable model.