> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.vapi.ai/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.vapi.ai/_mcp/server. # Migrate to GPT-Live > Migrate a Vapi assistant or squad to GPT-Live. Check fit, convert a copy, split prompts between the speaker and reasoner, map squad members to reasoner skills, compare results, and roll back safely. This page has two complete paths. Follow [From a single assistant](#from-a-single-assistant) if you're moving one assistant, or [From a squad](#from-a-squad) if you're combining a squad into one GPT-Live assistant. Each path repeats what it needs, so you can follow one without reading the other. Both start from the same preparation. ## Before you start ### Check that your assistant can move Some features don't carry over. If your assistant depends on one of these, plan how to replace it before you begin: * **Voices** must be one of the [OpenAI voices GPT-Live supports](/gpt-live/configuration#voices). Other voice providers and custom or cloned voices aren't available. * **Squads and assistant handoffs** aren't supported. A squad becomes one assistant, as described [below](#from-a-squad). * **Model and voice fallbacks** must be removed. GPT-Live can't be a fallback model either. * **Exact or prerecorded speech** isn't available. GPT-Live generates all of its speech, including the greeting. * **Keypad input** from callers works on native Twilio and Vapi SIP calls, and isn't available on browser or WebSocket calls. * **Knowledge bases and the Query tool** aren't available. Use a function, API request, or MCP tool for retrieval. * **Transfers** are blind only, on native Twilio and Vapi SIP calls. **Native Telnyx and Vonage** numbers aren't supported. The full list is in [Settings and compatibility](/gpt-live/configuration#compatibility). ### Save representative calls Pick a handful of calls that represent what the assistant has to get right: a straightforward success, a caller who changes their mind, a failure your tools return, and anything specific to your business. For each, note the starting state, the expected tool actions, the expected outcome, and a recording from the current assistant. These are what you'll compare against. ### Keep the original running Leave your phone numbers on the original assistant or squad until the GPT-Live version has passed the same calls. Work on a copy, test it on its own, and switch traffic when you're ready. ## From a single assistant ### 1. Take inventory Write down what the assistant does and what it depends on: | Area | What to record | | --------------- | ----------------------------------------------------------------------------------- | | Caller's goal | What a successful call achieves | | Prompt | The system prompt, and which parts are about conversation and which are procedures | | Tools | Each tool, its type, and when it should be used | | Voice | The current provider and voice, and what matters about it | | Call connection | Browser, Twilio, SIP, WebSocket, or another provider | | Hooks | Idle messages and any other hooks | | Transfers | Destinations, and whether any are warm transfers | | Analysis | Structured outputs, scorecards, and anything that reads the transcript or recording | ### 2. Convert a copy Convert a copy, so the original keeps serving callers while you test: #### Duplicate the assistant In [Assistants](https://dashboard.vapi.ai/assistants), open the assistant's menu and select **Duplicate**. Don't attach a phone number to the copy. #### Switch the copy to GPT-Live Open the copy, select **Try GPT Live**, then confirm with **Switch to GPT Live**. #### Review the result Conversion publishes a new version of the copy straight away, with speaker and reasoner prompts written for you. Read both prompts and compare them with the split described in the next step. Because conversion publishes immediately, working on a duplicate is what keeps callers on the original until you're ready. To go back, select **Revert to Classic**. It restores the assistant's Classic configuration as a draft, and the published version stays GPT-Live until you select **Publish**. You can also migrate by hand through the API: create a new assistant with the GPT-Live configuration from the steps below. ### 3. Split the prompt A classic assistant has one prompt that covers both how to talk and how to do the work. GPT-Live has two. The speaker prompt shapes the conversation and says when to delegate. The reasoner prompt holds the procedures and tool rules. Neither sees the other, so rules that affect both belong in both, worded for each role. ![Prompt instructions separate into speaker and reasoner bundles. One shared rule branches into both.](/_fern-files/vapi.docs.buildwithfern.com/678a5f7ebacd38cc6e9ff7f9bdb676fc3bd4fa46a6fa7efafb7d09d418ed86be/static/images/gpt-live/split-prompt-light.svg)![Prompt instructions separate into speaker and reasoner bundles. One shared rule branches into both.](/_fern-files/vapi.docs.buildwithfern.com/df967181a80705f8271bc5eccc7710124cff7cfd8e4e039f261f65da47d31aeb/static/images/gpt-live/split-prompt-dark.svg)![Prompt instructions separate into speaker and reasoner bundles. One shared rule branches into both.](/_fern-files/vapi.docs.buildwithfern.com/5a30a3f5cf174d6cb4b387d1796ac60f1848dfc65fa18e6cca389acece2bcc10/static/images/gpt-live/split-prompt-light-compact.svg)![Prompt instructions separate into speaker and reasoner bundles. One shared rule branches into both.](/_fern-files/vapi.docs.buildwithfern.com/beace13fb2560bea64fd1c859cba51d6c118d07af212563c9e43fae86ba0b64f/static/images/gpt-live/split-prompt-dark-compact.svg) For example, a classic prompt for an appointment assistant at Example Service Studio, a fictional business, might read: **`Before: one classic system prompt`** ```text title="Before: one classic system prompt" You are the booking assistant for Example Service Studio. Be friendly and brief. Ask for the service, location, and date. Use lookupAvailability to find open times and read them to the caller. When they choose one, ask for their name, confirm the details, and call bookAppointment. Never say a booking is done until bookAppointment succeeds. If the caller wants to change a booking, cancel it with cancelAppointment first. Answer questions about services with getServiceInfo. ``` Split it by who does what: **`After: speaker instructions`** ```text title="After: speaker instructions" You are the booking assistant for Example Service Studio. Speak warmly and briefly, one question at a time. Use details the caller has already given. Delegation policy: Backend tools: - Appointments: check open times, book a time, and cancel a booking. - Service information: services, what to bring, locations, hours, policies. - Ending the call. Delegate to the backend when: - You know the service, location, and date. Ask for availability right away. - The caller has clearly said yes to booking after you read back the day, time, location, and name. - The caller changes the request, or asks to cancel or move a booking. - The caller asks about services, what to bring, locations, hours, or policies. - The backend asked for a detail and the caller has now given it. - The caller asks to end the call or says goodbye. Always delegate this. While work is running, ask for the name for the booking if you don't have it. If the caller asks something you can answer from what you already know, answer it. Otherwise acknowledge the wait once and give the caller room. Say a time is booked only after the backend reports that it is booked. When the caller chooses a time, that's a choice, not agreement to book. Read back the day, time, location, and name, and ask whether to book it. Delegate the booking only after the caller clearly says yes. ``` **`After: reasoner instructions`** ```text title="After: reasoner instructions" Work from the latest request in the conversation transcript. Call lookupAvailability when you have the service, location, and date. A caller choosing a time isn't agreement to book. Call bookAppointment only for a time from the latest lookup, and only when the transcript shows the assistant read back the day, time, location, and name and the caller then clearly said yes. Otherwise, return those details for the assistant to read back and confirm. To move a booking, look up the new time and confirm it with the caller first, then cancel the existing booking with cancelAppointment and book the new time. If the new booking fails after the cancellation, say so. Use getServiceInfo for service questions. Return short, plain facts. Never report an action a tool did not confirm. Call endCall when the caller asks to end the call. ``` Three things changed besides the split: * **Explicit delegation triggers.** The speaker only starts work when it delegates, so every kind of task, including ending the call, is listed. * **Waiting is designed.** In the classic flow, the assistant read times out after a lookup and then asked for the name. The speaker now asks for the name while the lookup runs. * **Results are for speaking.** The reasoner returns short facts that the speaker can use directly. If the reasoner prompt grows to cover several distinct procedures, group them into [reasoner skills](/gpt-live/skills). ### 4. Map the settings | Classic setting | With GPT-Live | | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | System prompt | Conversation guidance goes in `model.speaker.instructions`, procedures in `model.reasoner.instructions`. If speaker instructions are set, they take precedence over the classic system prompt | | Model | `model.model` is `gpt-live-1`. The reasoner model is set separately and defaults to `gpt-5.6-terra` | | Transcriber | Not used. GPT-Live hears the caller directly | | Voice | An OpenAI voice from the [supported list](/gpt-live/configuration#voices) | | Model or voice fallbacks | Remove them | | Function, API request, and MCP tools | Keep them. Move their usage rules into the reasoner prompt | | `endCall`, `transferCall`, `dtmf` | Keep them, and check [transfer and keypad support](/gpt-live/configuration#transfers-and-keypad-input) for your connection | | Other tool types | Not supported. Replace them with a function, API request, or MCP tool | | Tool messages, such as request-start messages | Not spoken. Guide what the assistant says while work runs in the speaker prompt | | Idle-message hooks with `say.prompt` | Keep them. See [When the caller goes quiet](/gpt-live/design#when-the-caller-goes-quiet) | | Idle-message hooks with `say.exact` | Accepted, but the text is spoken as generated speech, so the words may vary and verbatim playback isn't guaranteed. Rewrite them with `say.prompt` | | Greeting | A text `firstMessage` works and is spoken as generated speech. Audio greetings and generated first-message mode aren't supported | | Keypad input plan | Supported on native Twilio and Vapi SIP. Not available on browser or WebSocket calls | | Start and stop speaking plans, `temperature`, `maxTokens` | No effect | | Structured outputs, call analysis, scorecards | Keep them. See [Test and improve](/gpt-live/testing#watch-production-calls) | ### 5. Redesign the waits Look at the places where your current flow waits for a tool before it moves on. With GPT-Live, the conversation can keep going during that time, so decide what it should cover. Start work as soon as its inputs are known, then ask for something the next step will need: > **Caller:** A consultation downtown on Friday. > > **Assistant:** I'll check Friday downtown. Who should I put the appointment under? > > **Caller:** Sam Lee. > > **Assistant:** Thanks, Sam. Friday I have 10:30, 2:30, or 4. When the next step is blocked, the conversation can still help. Here the booking is running, and the caller asks about something the assistant already knows: > **Assistant:** That's Friday at 2:30, downtown, under Sam Lee. Shall I book it? > > **Caller:** Yes. Do I need to bring anything? > > **Assistant:** Nothing's required for a consultation. Bring any questions you'd like to cover, and it helps to arrive five minutes early. > > **Assistant:** You're booked: Friday at 2:30 downtown, under Sam Lee. The preparation answer doesn't depend on the booking, so it can come while the booking runs. "You're booked" waits for the result. For the speaker to answer like this, give it a few stable facts in its prompt, such as arrival and preparation guidance. When there's nothing useful to say, one acknowledgment and a pause is better than filler. [Design conversations](/gpt-live/design#while-work-is-running) covers these choices in depth. ### 6. Compare with the original Run your saved calls against the copy. For each one, check: * **The outcome.** Your service's state shows the same result as before, with no duplicate or missing actions. * **The tool calls.** The call's messages show the expected tool calls and arguments. * **The conversation.** The recording shows the assistant reached the goal without making the caller repeat themselves, and that waits sounded reasonable. Record differences you intended, such as a shorter call, separately from regressions. [Test and improve](/gpt-live/testing) describes how to repeat these calls with Voice Simulations. ### 7. Roll out and roll back When the copy passes, assign your phone number to it. Keep the original assistant, unchanged, until you're confident in the new one. If you need to take a converted assistant back to Classic, select **Revert to Classic**, then **Publish**. Until you publish, callers still reach the GPT-Live version. ## From a squad A squad splits a conversation across assistants and hands the caller between them. GPT-Live keeps one voice for the whole call, and its reasoner can switch between procedures without a handoff. Migrating a squad means mapping what each member was responsible for onto one assistant. **Switch to GPT Live** converts a single assistant. It doesn't convert a squad, so this path is done by hand. ### How the pieces map Take a squad with a front-desk assistant that greets callers and routes them, a scheduling assistant, and a service-information assistant: ![A squad becomes one GPT-Live assistant: front-desk greeting and routing move into the speaker prompt, specialists become reasoner skills, and shared tools remain base tools.](/_fern-files/vapi.docs.buildwithfern.com/8859407b56926eb48ed086e89a86309e10b3a620e6f97169be056262ef1a9b17/static/images/gpt-live/squad-to-skills-light.svg)![A squad becomes one GPT-Live assistant: front-desk greeting and routing move into the speaker prompt, specialists become reasoner skills, and shared tools remain base tools.](/_fern-files/vapi.docs.buildwithfern.com/dd68a0b8a5b275f9f695749f322506ca7ad11d697560fc8046797bd2e2d47d26/static/images/gpt-live/squad-to-skills-dark.svg)![A squad becomes one GPT-Live assistant: front-desk greeting and routing move into the speaker prompt, specialists become reasoner skills, and shared tools remain base tools.](/_fern-files/vapi.docs.buildwithfern.com/e972286d269bf17707f6ddf5941d6cdb34ddca4def6be3ec9cb26272b9a451fb/static/images/gpt-live/squad-to-skills-light-compact.svg)![A squad becomes one GPT-Live assistant: front-desk greeting and routing move into the speaker prompt, specialists become reasoner skills, and shared tools remain base tools.](/_fern-files/vapi.docs.buildwithfern.com/0902dae7dfa81d05512441f34c06ee11d06716302ed22346ac151da2b09e684e/static/images/gpt-live/squad-to-skills-dark-compact.svg) | In the squad | In one GPT-Live assistant | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Front-desk greeting, intake, and routing | Shared speaker behavior, assistant-wide reasoner rules, and delegation triggers | | Scheduling assistant | A `schedule-appointment` skill with its procedure and booking tools | | Service-information assistant | An `answer-service-questions` skill with its guidance; shared `getServiceInfo` stays a base tool | | Handoff conditions | Skill descriptions and the speaker's delegation triggers | | Values passed between assistants | What the caller said is in the shared conversation. Values an earlier assistant or tool produced come from your services | | Protected actions | Checks in your services: prerequisites, confirmation, duplicate handling | | Transfer to a person | A `transferCall` tool, kept as a base tool | ### 1. Map each member's responsibility For each assistant in the squad, write down what it's responsible for and why it was separate. Common reasons are a long procedure, a different set of tools, or a different tone. Then decide where each responsibility goes: * A procedure with its own rules and tools becomes a **skill**. * Rules every part of the call follows, like "never report an action a tool didn't confirm", go in the **reasoner prompt**. * Conversation guidance, like tone and pacing, goes in the **speaker prompt**. You don't need one skill per old assistant. A front-desk assistant that only greeted and routed usually doesn't need a skill at all: its job becomes the speaker's greeting and delegation triggers. Two specialists with closely related work may be clearer as one skill. ### 2. Keep one voice and shared conversation rules Write one speaker prompt for the whole call. Take the greeting and tone from the assistant callers heard first, and add anything the specialists did differently that callers relied on, such as a slower pace for explaining policies. Remove handoff announcements like "Let me transfer you to our scheduling team." The caller stays with the same assistant, so they aren't needed. One of the goals of the migration is that the caller no longer repeats details at each handoff. Check that on real calls: it depends on your prompts and on the reasoner using the earlier conversation. A handoff was also a point where the conversation paused. Now the speaker can keep going while the reasoner works. When the caller moves from a question to booking, the speaker can start the lookup and ask for the name in the same breath: > **Caller:** Thanks. Can I book a consultation downtown on Friday? > > **Assistant:** Sure, I'll check Friday downtown. Who should I put it under? Give the speaker the same waiting guidance as a single assistant: ask what the next step needs, answer what it already knows, and acknowledge a blocked wait once instead of filling it. See [Redesign the waits](#5-redesign-the-waits) above. ### 3. Build the skills Each specialist's procedure becomes a skill's `content`, and its tools become the skill's tools. A minimal version for the scheduling and service-information specialists: **`model.reasoner (excerpt)`** ```json title="model.reasoner (excerpt)" { "instructions": "Work from the latest request in the conversation transcript. Load the skill that fits the request. Return short, plain facts the assistant can say. Never report an action a tool did not confirm. Call endCall when the caller asks to end the call.", "skills": [ { "name": "schedule-appointment", "description": "Check open times, book a time, or cancel or move a booking made on this call.", "content": "Call lookupAvailability when you have the service, location, and date. A caller choosing a time isn't agreement to book. Call bookAppointment only for a time from the latest lookup, and only when the transcript shows the assistant read back the day, time, location, and name and the caller then clearly said yes. Otherwise, return those details for the assistant to read back and confirm. To move a booking, look up the new time and confirm it with the caller first, then cancel the existing booking with cancelAppointment and book the new time. If the new booking fails after the cancellation, say so.", "toolIds": ["LOOKUP_TOOL_ID", "BOOK_TOOL_ID", "CANCEL_TOOL_ID"] }, { "name": "answer-service-questions", "description": "Answer questions about services, how long they take, what to bring, locations, hours, and the change policy.", "content": "Use getServiceInfo and answer only from its result. If the caller was in the middle of booking, say so in your result so the assistant can return to it." } ] } ``` The `toolIds` are the IDs of the saved tools the scheduling assistant used. Tools that several skills need, or that must always be available, go in the assistant's base tools instead. Here `getServiceInfo`, `endCall`, and any transfer to a person are base tools. See [Reasoner skills](/gpt-live/skills#example-scheduling-and-service-questions) for the full procedure and tool placement. ### 4. Turn handoff conditions into descriptions and triggers In the squad, handoff conditions decided which assistant took over. Now they do two jobs: * **Skill descriptions** tell the reasoner which procedure a request needs. Write them in terms of the caller's request, and make sure two skills don't claim the same requests. * **Delegation triggers** in the speaker prompt tell the speaker when to send work to the reasoner at all. A condition like "hand off to scheduling when the caller wants to book, move, or cancel" becomes the scheduling skill's description and a line in the speaker's triggers. Write the speaker's triggers in terms of the caller's need. The speaker delegates the work; the reasoner chooses which skills to load. ### 5. Plan for what doesn't carry over * **Different voices or models per member.** One assistant has one voice and one reasoner model. Skills don't change either. * **Separate context per member.** In one assistant, the whole call's conversation is shared, and skills don't isolate it. If a member was separate to keep information apart, enforce that in your services or keep that flow outside this assistant. * **Handoff tools.** Remove them, since handoffs aren't supported. * **Values passed at handoff.** Inventory each one before removing it. Details the caller said are in the shared conversation. Values an earlier assistant or tool produced, such as an account ID or a lookup result, may not be. Make those available from your services, for example through a tool the reasoner can call, and keep authoritative state there. * **Member-specific hooks or settings.** Combine them into the one assistant's configuration, and check each against [Settings and compatibility](/gpt-live/configuration#compatibility). ### 6. Test the switches between procedures The old handoff boundaries are the places to test most carefully, because that's where the combined assistant switches between procedures. Test: * **A switch** from scheduling to a service question and back, without repeating details. * **A return** to an unfinished booking after the detour. * **A correction** during a lookup. * **An already-completed action.** After a booking, return to the topic and check the assistant doesn't book again. * **A failure** from a tool, and the recovery. For each, check the call's messages for the skill loads and tool calls, your service's state for the outcome, and the recording for how it sounded. The reasoner uses the conversation and earlier results to continue, which works well when results are clear about status. Skills don't track workflow state for you, so your services must still reject duplicates and out-of-order actions. ### 7. Roll out and keep the squad Move traffic to the new assistant when it passes your saved calls. Keep the original squad and its configuration unchanged as your fallback. Revert to Classic works on converted single assistants and doesn't recreate a squad, so the squad itself is your way back.