Switch from OpenAI Realtime to PyAI Omni
Keep your agent logic. Adapt the realtime transport to Omni.
Omni uses a native binary kind-byte protocol rather than OpenAI Realtime JSON events. Keep your prompts, tools, and business logic, then adapt audio and control framing to /v1/omni. Add Trace, Recap, and Agents Live Beta as calls move into production.
Try the migration
A browser Omni voice agent in one <script> tag, scaffold the runnable example in one command, no clone:
npm create pyai-app@latest omni-browser-widgetWhy teams move from OpenAI Realtime
Flat minute pricing
Omni speech + brain is $0.05/min; managed telephony is a separate $0.01/min, so production phone calls are easy to model before they scale.
Built for telephony
Turn-taking, barge-in, and 8 kHz call audio are first-class instead of adapted from a general model API.
Production call layer
Trace, Recap, KB Context, and Agents Live Beta sit on the same account and billing model.
Before and after
const ws = new WebSocket(
"wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview",
["realtime", "openai-insecure-api-key." + openaiKey],
);const ws = new WebSocket(
"wss://api.pyai.com/v1/omni?session_label=front_desk&format=pcm16&rate=24000",
["pyai.v1", "pyai-key." + pyaiKey],
);
// Prefix PCM16 with 0x01; prefix configure JSON with 0x03.
ws.onmessage = (e) => handleOmniFrame(e.data);Migration checklist
Swap the connection
Change the base URL or WebSocket URL, pass a PyAI key, and keep the old client where the API shape is compatible.
Map models, voices, and formats
Use the table below to replace model ids, voice ids, response formats, sample rates, and auth headers without rewriting the product flow.
Replay customer traffic
Run real prompts, recordings, and phone-call samples through both systems. Compare latency, quality, completion rate, and all-in cost.
Launch with guardrails
Start on free credits or test keys, add usage alerts, then enable Trace, Recap, or the Agents feature when calls need production review.
If the system you are leaving already uses OpenAI-compatible transcription, speech, or realtime APIs, start with the smallest compatible swap: base URL, key, model, and voice. The real test is whether PyAI improves cost, latency, and caller outcomes on your own traffic.
What maps to what
| OpenAI Realtime | PyAI |
|---|---|
wss://api.openai.com/v1/realtime | wss://api.pyai.com/v1/omni?session_label=<label>&format=pcm16&rate=24000 |
Authorization: Bearer OPENAI_API_KEY | Subprotocols pyai.v1, pyai-key.<key> or Authorization: Bearer pyai_live_... |
Model-specific audio/token pricing | $0.05/min Omni speech + brain pricing |
session.update JSON events | 0x03-prefixed configure/control JSON; 0x01-prefixed PCM16 audio |
Good to know
- Use the native URL wss://api.pyai.com/v1/omni?session_label=<label>&format=pcm16&rate=24000.
- format and rate are load-bearing on the native Omni URL.
- Trace can scan production calls with per-call metering.
- Scaffold a working browser voice agent with npm create pyai-app@latest omni-browser-widget (github.com/atomsai/pyai-examples).
FAQ
Is the API identical?
No. OpenAI Realtime uses JSON events; Omni uses one-byte kind tags for audio and control frames. Keep your agent logic, but implement the documented transport adapter.
Why switch if I already use OpenAI?
PyAI is narrower: phone-agent latency, telephony audio, predictable per-minute pricing, and call compliance tooling.