Why build here
One model, not a relay. Realtime is genuinely speech-to-speech — audio in, audio out. No transcribe-then-think-then-speak round trip, and barge-in, end-of-turn detection and cancellation are handled rather than left to you. Transcription that knows the room. Not just words: who spoke, when, and whether they were on mic, off mic, or too faint to trust. That last part is what separates a bad recording from a bad transcript. Voices that hold. Every voice — cloned or built-in — resolves to a stored reference clip, so a long piece never drifts between speakers. Clone once and it works everywhere: speech, realtime, interpretation, a phone call. Interpretation as its own session type. Not a translation prompt bolted onto a chat model. You speak, the room hears you a beat later in another language — in your own cloned voice, if you want. A phone call is a realtime session. The carrier’s audio is already the codec the model server decodes, so a phone leg is not a pipeline that transcodes between the two — it is the same session with a different socket on the near side. See Telephony. Yours to run, and not a lock-in. The API speaks the OpenAI wire protocol, so existing clients work by changing a base URL — while inference runs on your hardware.Capabilities
The whole platform on one page — every capability, the model behind it, and
the endpoint you call.
Speech
Text to speech
Synthesize speech in a built-in or cloned voice.
POST /v1/audio/speech.Speech to text
Transcribe audio with word timings.
POST /v1/audio/transcriptions.Voices
Clone a voice from a few seconds of audio, or use the built-in library.
Audio intelligence
Diarized transcripts — who spoke, and when.
Realtime
Realtime
Speech-to-speech over a WebSocket.
/v1/realtime.Translation
Live interpretation as its own session type.
Duet
Two sessions cross-piped, holding a live conversation with each other.
Sessions
Transcripts, recordings and reply latency for every conversation.
On the phone
Telephony
One carrier, Telnyx, relayed into an ordinary realtime session.
EESI Care
A companion that calls on a schedule, remembers, and escalates.
Pick your path
Call the API
Get a key and make your first request in under a minute.
Quickstart
Synthesize, transcribe, then hold a live conversation.
Use an SDK
Typed Python and TypeScript clients for the platform surfaces.
Move an OpenAI integration
A base URL and a key; the official SDKs work unchanged.
What you can build
A speech API. Use EESI purely as infrastructure:/v1/audio/speech,
/v1/audio/transcriptions, /v1/realtime and /v1/chat/completions all speak
the OpenAI wire protocol, so existing clients work unchanged while the compute
runs on your hardware.
Live conversation, in a browser or a native app. One WebSocket against
/v1/realtime, with barge-in and end-of-turn detection handled server-side and
transcripts of both sides arriving on the same socket as the audio.
Phone calls. Point a Telnyx number at the platform and an inbound call
becomes a realtime session; outbound is the same session, dialled. The model
does not know or care which side started it.
Scheduled companion calls. Care is that stack as a
product: a call on a schedule, a persona that remembers, and post-call
observations and alerts a caregiver acts on.
Session-to-session conversations. Two realtime sessions can be cross-piped
so they talk to each other, which is how EESI runs adversarial evaluation and
load testing before anything meets a customer.
Two things worth knowing early
They explain most of the API surface.- Every voice is a reference clip. Cloned or built-in, a voice always resolves to stored reference audio. Without that, the model samples a new voice per generation and a call drifts between speakers. See Voices.
- There is one realtime architecture. A phone call, a browser session and an interpretation session are the same session type with different sockets and different instructions — same admission control, same transcript, same billing. See Architecture.