Skip to content
OTFotf
All posts

GPT-Live 1 on AI Gateway: own delegation-created and the billing hop

D
DaveAuthor
6 min read
GPT-Live 1 on AI Gateway: own delegation-created and the billing hop

GPT-Live 1 full-duplex voice with AI Gateway delegation

GPT Live 1 is available on Vercel AI Gateway. That is a routing fact, not a product that decides who may do what inside your app. The live session is a voice hop that stays open. When it emits a delegation, your server is the thing that accepts or refuses the work, then calls a pinned text model on the gateway for the part that should be text. Two hops, two bills, one permission boundary that never leaves your process.

This is not a visual-grounding writeup. Live voice plus a camera, or live voice plus a screenshot, is a different shape: the model is looking at pixels while it talks. Delegation is the opposite pressure. The voice model is asking your app to go do something else, often with a stronger text model, and then come back into the same conversation. If you blur those two posts together you will wire the wrong events and you will mis-attribute the invoice.

The app owns permissions

A delegation is a request, not a grant. The live model can propose that some piece of work should be handed off. Your application decides whether that handoff is legal for this user, this session, and this tenant.

That decision has to sit in code you deploy, not in a prompt you hope the model obeys. Prompts are instructions. Permissions are checks. A check looks at the authenticated user, the session you already opened, and an allowlist you wrote. If the check fails, you do not call the text model, and you do not tell the voice side that the work succeeded.

Own the list explicitly. Typical entries are narrow: summarize this thread, draft a reply from records this user can already read, classify an intent, extract fields from text the user just spoke. They are not "do anything the model names." If a delegation asks for a tool you did not register, drop it. If it asks for a resource id that is not in the user's scope, drop it. Log the refusal with the session id so you can see what the model keeps asking for. That log is how you tighten the allowlist later, not how you expand it by default.

Handle delegation-created, then call text

The event you care about is the one that says a delegation was created. That is the moment the live session has a concrete handoff, not a vague hint in the transcript. Your handler should be boring.

Read the delegation. Map it to one of your allowlisted jobs or reject it. If you accept it, call the pinned text model on AI Gateway with only the context that job needs. Do not forward the whole live session state, tool list, or unrelated user data just because it is sitting in memory. The text model is a function with inputs you chose. When it returns, write the result back into the live session in whatever form that session accepts for a tool or delegation result, and let the voice side continue.

While that text call is in flight, the voice session stays up. That is the point of the split. You are not tearing down realtime audio, buffering a new socket, and hoping the user waits through a reconnect. The user can still be in the call. Your job is to keep the live socket healthy and to finish the text hop before the conversation goes stale. If the text hop is slow, say so inside the session with a short status you control, not with a second model improvising an apology. Silence plus a hung delegation feels like a dead call. A held session with a known in-progress job feels like a product.

Same component. Web and mobile. One codebase.

The free, open-source SDK gives you components that work the same on web and mobile — one codebase. github.com/otf-kit/sdk

Get the free SDK

Pin the text model

"Pinned" means the text hop does not follow whatever the live model suggests as a target. You choose the model id on AI Gateway and you keep it stable for that job. A delegation payload might imply a capability ("use a stronger model", "use a coding model"). That is a hint at best. Your route table is the decision: this job name maps to this gateway model id, with this max output, with this timeout.

Pinning is what makes the feature debuggable. When a summary is wrong, you know which model wrote it. When a bill spikes, you know which route moved. If you let the live session pick the downstream model per turn, you cannot explain either failure to yourself a week later, and you cannot canary a replacement without also changing voice behavior.

Which hop bills

Two hops means two charges, even when the user experiences one conversation.

The live hop is the GPT Live 1 session on AI Gateway. You pay for that session because it is open and doing voice. Holding the socket while a delegation runs does not move that cost onto the text model. If your product leaves sessions open "just in case," that is a live-session cost, not a rounding error on the text bill.

The text hop is the separate call you make after delegation-created, to the pinned model, also through AI Gateway if that is where you pinned it. You pay for that call because you placed it. A refused delegation should not create this charge. A duplicate delivery should not create it twice. A timeout might still be billed for work the provider already did; design the client so a timeout does not immediately retry with a new delegation id and a wider prompt.

Failure modes worth naming

The live session drops while the text hop is still running. Decide in advance whether the text result is discarded or stored against the delegation id for a reconnect. If you store it, the reconnect path must replay the result instead of starting a new text call. If you discard it, do not let a client retry storm recreate the same job under a new id without the user asking again.

The model creates delegations you did not document. That will happen. Refusal is the correct response, with a short reason the voice model can speak. Expanding the allowlist in the handler because a demo failed is how permissions leak. Change the allowlist in review, ship it, and restart sessions so old calls do not keep the old list by accident only when you meant to freeze it. Be explicit: new sessions pick up the new allowlist; in-flight sessions keep the list they started with unless you have a real reason to hot-swap.

What to ship first

Ship one job. For example, "summarize what the user just asked, using only the last user turn and the allowlisted notes." Wire delegation-created to that job alone. Pin one text model on AI Gateway. Log both hop ids. Refuse everything else with a stable error the session can speak.

When that path is dull, add a second job with its own pin and its own input builder. Do not add a general "let the model decide" route to save time. The time you save in the first week comes back as an invoice and an incident review.

Keep this distinct from Gemini 3.8 Live on AI Gateway — different live surface, different buyer question. Host-boundary habits when agents sit behind subscriptions still apply: AI SDK harness auth on the host boundary. Text-hop timeouts and retries stay off the audio send path, same as API timeouts and retries for owned AI backends.

Sources

ai-toolsagentsvercel
OTF SDK + Kits

Buy once, own the code. Ship with the agent you already use.

  • Free, open-source SDK — same component, web and mobile
  • Paid kits include AI configs + 40+ tested prompts — your agent reads the whole project
  • $99/kit or $149 for everything. No subscription, no sandbox limit.