Search Every Conversation You Have with GPT Live

The Short Answer

Record the session, land the recording in a Mixpeek bucket, point a collection at that bucket with the multimodal extractor, and query a retriever in plain language. Three API calls, and the object accepts either a hosted URL or the recording bytes directly, so there is no separate hosting step once the call is captured.

Why a live voice conversation is harder to find than a generated clip

GPT-Live-1 is full-duplex: it listens and speaks at the same time, handles interruptions, and keeps a conversation going while a backend model works out what to say next. OpenAI reports an 86.2% Pass@1 score on Tau3's spoken customer-service benchmark, against 45.7% and 42.4% for the prior two Realtime generations, and a 30-point jump on turn-taking latency. At $0.05 a minute for the voice layer, that is priced for products that run this all day: support lines, voice agents, sales calls.

None of that generates a file the way an image or video model does. GPT-Live-1 is a real-time interface, not a batch job: there is no output URL to fetch when a session ends, because the session was never a single request with a single response. What exists afterward is whatever your own application recorded while the call was happening, and if nothing was recording, the conversation is gone the moment it ends. That is the same shape as Runway's live world sessions: the artifact is the recording you made, not something the API hands back.

Once a recording exists, it faces the ordinary generated-media problem at scale. A support team running hundreds of calls a day ends up with a folder of session ids and timestamps, and "what did the customer say about the refund" is not answerable by filename.

The three calls

# 1. bucket: land every session you record
POST /v1/buckets/{bucket_identifier}/objects
{"blobs":[{"property":"audio","type":"audio","data":"your_recording_url"}]}

# 2. collection: multimodal extraction runs on arrival
POST /v1/collections
{"collection_name":"sessions",
 "source":{"type":"bucket","bucket_ids":["{bucket_identifier}"]},
 "feature_extractor":{"feature_extractor_name":"multimodal_extractor","version":"v1"}}

# 3. retriever: search everything you generated
POST /v1/retrievers/{retriever_id}/execute
{"inputs":{"query":"the call where we settled on pricing"}}

What each call is doing

The bucket is the landing zone. property names the field in the bucket schema the blob belongs to, type is audio, and data accepts a hosted URL or the recording bytes directly as base64, covered below.

The collection declares extraction once. Point it at the bucket and every session that lands afterward runs through the multimodal extractor on the same terms, whether it came from a support line, a sales call, or a voice agent test run.

The retriever is the query contract: plain language in, matching documents with scores out. Extraction transcribes and segments the recording, so "the call where we settled on pricing" matches the moment in the conversation where that happened, not a session id or a call timestamp.

Capturing the session, since GPT Live has no output URL to fetch

A live, full-duplex API streams audio in both directions over the length of a call. Recording that stream, on your own infrastructure, is the step between the conversation happening and it becoming searchable. There is no GPT Live endpoint that hands you a finished file the way an image or video generation call does.

Once you have the recording, land it the same way as any other audio object:

# from a hosted URL, once your recording pipeline has written it somewhere
POST /v1/buckets/{bucket_identifier}/objects
{"blobs":[{"property":"audio","type":"audio","data":"https://your-storage/sessions/call-0417.wav"}]}

# from base64 bytes, if the recording is small enough to pass inline
POST /v1/buckets/{bucket_identifier}/objects
{"blobs":[{"property":"audio","type":"audio","data":"data:audio/wav;base64,UklGRi..."}]}

Mixpeek decodes a base64 payload itself, so a short recording can go straight into the data field with no intermediate host. Base64 blobs are capped by plan (5 MB free, 10 MB pro, 50 MB enterprise); anything longer than a few minutes of audio should be uploaded to storage you control first and passed as a URL instead.

Adding session metadata

The participants, the backend model GPT Live was paired with, and any session id from your own system are worth keeping even though none of them is what you search. Attach them as blob metadata and they come back as filterable fields beside the semantic match:

POST /v1/buckets/{bucket_identifier}/objects
{"blobs":[{"property":"audio","type":"audio",
           "data":"https://your-storage/sessions/call-0417.wav",
           "metadata":{"session_id":"call-0417",
                       "backend_model":"gpt-6-astra",
                       "channel":"support-line"}}]}

That combination is the useful one: find the moment by what was said, then filter by which backend model handled the reasoning or which channel the call came in on.

Frequently Asked Questions

Does GPT Live give me a transcript I can search directly?

The API can return one, but a transcript alone is a single block of text: searching it finds the whole call, not the moment inside it. Landing the recording and letting Mixpeek's multimodal extractor segment it is what makes a specific exchange, not just the session, come back as a result. See why episode-level search strands you inside the file for the same problem in a different medium.

What does the retriever actually search?

The features the multimodal extractor produced from the recording itself: speech content and timing, not the session id and not a transcript nobody attached. That is why "the call where we settled on pricing" matches a file named by a call id with no readable content in the name.

Is this different from logging call metadata in a CRM?

A CRM entry captures what someone typed about the call afterward. Extraction captures what was actually said, which is a different and usually more complete record, and it does not depend on someone remembering to write the summary. The two are complementary: keep the CRM entry, and let the recording answer questions the summary never anticipated.

Does this work for the mini variant, or other realtime voice models?

Yes. The three calls do not depend on which model produced the audio, only on getting a recording of the session into a bucket as an audio blob. The same pattern applies to GPT Live mini, to Realtime API sessions, or to any other full-duplex or streaming voice product.

Does this scale to a high call volume?

The pattern is identical for one session and for thousands a day: the collection processes whatever lands in the bucket, and extraction is paid once per object rather than per query. At $0.05 a minute for the voice layer alone, a support line running this continuously will generate a large volume of recordings fast, so plan the storage and extraction cost around call volume rather than treating it as an afterthought.

Related

Why does my podcast search find the right episode but not the moment? for the same segment-versus-file problem over recorded audio

Search every conversation you have with GPT Live for the same capture-then-index pattern applied to a live full-duplex voice session

Forced alignment for AI agents for word-level timestamps and diarization when segment-level precision is not enough

Search every world you generate with Runway for the same capture-the-session pattern applied to a live interactive world model

Search every image you generate with ChatGPT for the base64-or-URL ingestion pattern applied to a different modality

Buckets, objects and blobs for the full ingestion contract, including base64 and URL handling