VOICE AI · FIELD NOTES
What OpenAI’s GPT-Live store option is really for, and what we learned testing it on real phone calls.
September 2026 · Notes from building a multi-industry voice agent platform
The phone rings. Someone answers. The conversation is already underway. Then the call drops.
The customer calls back.
What should happen next?
A conventional voice bot usually starts over. The customer has to explain the problem again, repeat details, and reconstruct the state of the interaction.
OpenAI’s GPT-Live API has a feature that changes what is possible here: store: true.
But the interesting part is not simply that the call can be recorded. With storage enabled, the completed Live session can be stored and later forked into a new session that starts from the stored conversation state.
That distinction matters. A recording tells you what happened. A stored session can give your application a way to do something with that conversation later.
This article is based on tests we ran against the API using a real phone-call flow.
When store: true is enabled, OpenAI stores the completed Live session for a limited period. The stored session can be downloaded or used as the source for a fork. The original session is not reopened: a fork creates a new session with a new ID and starts from the stored state.
That makes the feature more interesting than ordinary call recording. The stored state includes the conversation and relevant session configuration, which can be carried into the new Live session.
The practical mental model:
The original session is never reopened. The fork is a new session that starts from the stored state.
We tested this behavior against the API using a dental-clinic booking agent. The calls used store: true, and the resulting sessions produced stereo 24 kHz recordings covering practically the whole call.
Our stack closes the connection without a graceful session.close when a call ends. Those sessions could still be forked: the fork succeeded and started as a new session with the previous conversation available.
In our test, the fork also inherited the session configuration we had established for the call, including the model, voice, instructions, backend model, and all six of our configured backend tools: availability, booking, SMS, WhatsApp, transfer, and hang-up.
That last point is worth phrasing carefully: these were the tools configured in our test. They are not a universal list of tools that every GPT-Live fork automatically has.
One integration note. Our open-source framework has no fork support: its session start sends a model parameter, which the fork endpoint rejects. The API reference lists only audio, client, delegation and store as overrides for a fork. The underlying API behavior worked; the integration needs to be adapted.
After the call had ended normally, we forked its stored session and asked the agent to resume. It responded:
“Hi! This is Lia from the front desk. Just to pick up where we left off: we spoke a moment ago and your evaluation is booked for tomorrow at 11.”
— Translated from Portuguese. The agent was asked to resume the previous conversation.
The important part was not the wording. It was that the new session had the conversation context needed to continue from where the previous session stopped.
Dropped calls happen. Networks fail. Mobile coverage changes. Customers hang up accidentally. SIP paths can fail. A caller may simply call back a few seconds later.
The customer experience problem is straightforward: the second call may look like a completely new interaction even though, from the customer’s perspective, it is a continuation.
Neither figure measures dropped calls or AI voice agents specifically. They describe the broader contact-center experience, but they illustrate the cost of context loss: preserving conversation context is useful only when the receiving side can actually use it.
There is an important boundary here.
GPT-Live does not automatically know that a new incoming phone call belongs to the same person or should continue a previous conversation. Your application has to establish that relationship.
A production implementation would typically need to:
A phone number by itself should not be treated as proof of identity.
This distinction is critical for production systems.
The fork can preserve the conversation, but your own system remains the source of truth for business actions.
Imagine the first call ended while booking an appointment. Before retrying the action, the application should read its own system of record and determine whether the appointment was already created. Otherwise, the recovery flow could turn a dropped call into a duplicate booking.
The same principle applies to tickets, payments, transfers, orders, reservations, and other side effects.
Not “fork and continue blindly”. Verify application state, then continue from the stored conversation when appropriate.
There is another subtle issue: the conversation may contain time-sensitive assumptions.
In our test, the agent talked about an evaluation being booked for “tomorrow at 11.” That may be correct during the original call and incorrect when the customer returns a day later.
It goes beyond the conversation. If your instructions embed the current date, as ours do, the fork inherits that too: it starts out believing “today” is the day of the original call.
A fork preserves the previous moment. It does not make that moment current again. For a safe recovery flow, the application should provide the current date and time and revalidate time-sensitive information before taking action.
There is another use case that may be even more interesting for engineering teams: turning real production conversations into repeatable tests.
Suppose a caller reaches an unexpected point in a production conversation. Instead of trying to reproduce the entire phone call manually, you can use the stored session as a reference point and fork it.
The new session can then be used to test the next turn repeatedly, without placing another phone call.
This fits naturally into an evaluation workflow, and OpenAI’s own GPT-Live evaluation guide describes the same loop: review production conversations, add representative failures to your evaluation set, and rerun them as things change. A production failure becomes a reproducible scenario that can be tested against appended instructions, backend settings, or tool handling.
One reference conversation can therefore become a small regression test for the voice agent.
A fork inherits the source session’s original instructions and voice, along with the prior conversation. You cannot replace the original instructions with a completely different startup prompt inside the fork.
You can, however, append new instructions and override supported backend delegation settings. If the goal is to test a fundamentally different main prompt, the cleaner approach is to start a new session.
This makes a fork particularly useful for testing what happens next from a known state, rather than for comparing completely unrelated agent configurations.
Stored GPT-Live sessions are retained by OpenAI for 30 days. Storage is not enabled by default, and the project must allow it. With Zero Data Retention, store is treated as false and forking is unavailable.
The stored session should therefore be treated as a deliberate data-retention decision, not as an invisible implementation detail.
GPT-Live 1 voice sessions are currently priced at US$0.05 per minute, billed by the second. A fork creates a new session, so the new session’s usage is billed separately. Backend model and tool usage is charged separately.
OpenAI’s current pricing page does not list a separate storage charge for GPT-Live. The cost to account for in a forked flow is the usage of the new session and any backend model and tool calls.
If we were implementing this pattern in a production voice platform, we would start small: The key is to treat the stored session as conversation state, not as the database for the business process.
The interesting part of store: true is not that OpenAI can keep an audio recording for a while. It is that a completed Live interaction can become a reusable state from which another Live session can start.
That changes how we can think about dropped calls, debugging, evaluation, regression testing, and recovery flows for voice agents.
The recording tells you what happened. The stored session lets you do something about it.
Test observations come from our own API testing, September 2026.