Inworld AI

Products, Models And Latency

Voice Infrastructure, Summarised

• Inworld AI is an inference provider selling realtime voice infrastructure — text-to-speech, speech-to-text, model routing and compute — as building blocks rather than as a finished product.
• Latency is the headline claim: inworld-tts-2 at 100ms P90 time-to-first-byte, and the flash variant at 20ms, both measured server-side.
• TTS covers 200+ languages with cross-lingual voice identity, so one voice can speak across languages.
• A router gives access to 220+ language models, spanning external providers and Inworld's own inference, from one integration.
• Charging is usage-based, with enterprise VPC deployment available — you pay for what you generate, not for seats.

Latency Terms That Decide Everything Here

Four terms you need in order to read any voice infrastructure claim properly.

Time to first byte

How long before the first audio arrives after a request. In voice, this matters far more than total generation time, because playback starts as soon as the stream does.

P90 and P99

The 90th and 99th percentile. P90 latency means one call in ten is slower than the stated figure — and the tail is what users actually notice in a long conversation.

Turn-taking

Detecting when a speaker has finished so the agent can respond. Getting this wrong makes an agent interrupt or leave dead air, both of which read as broken.

Cross-lingual voice identity

The same synthetic voice speaking different languages while remaining recognisably the same person. Hard, and valuable for multilingual products.

From Game Characters To Voice Plumbing

Inworld built its early reputation on AI characters for games — non-player characters you could actually talk to, with personalities, memories and goals. That was the story, and it attracted a great deal of coverage in games media.

The company now describes itself as a research lab and inference provider, and its product list is infrastructure: TTS, STT, an API, inference, a router, compute. No game engine integrations appear in the current material.

That is a significant change and it is worth understanding rather than glossing. The character-platform pitch asked developers to build inside someone else's framework. The infrastructure pitch sells components that go into whatever you are already building.

The strategic logic is sound. A character platform competes with every game studio's own preference for building its own systems, and it is a narrow market. Realtime voice infrastructure serves companions, support agents, phone systems, language learning and games alike — a much larger surface with a clearer buyer.

It also plays to what was genuinely hard about the original problem. Making a character feel alive was always mostly a latency problem, and latency engineering transfers to every voice application.

The practical implication: if you arrived here from an article about AI NPCs, evaluate this as a voice infrastructure vendor. The building blocks are there; the framework around them is now yours to write.

Making a game character feel alive was always a latency problem wearing a costume. Selling the latency directly reaches a far bigger market.

Why 20 Milliseconds Is The Whole Product

The latency figures are the centre of the offering and they deserve to be understood rather than admired.

Human conversation runs on roughly 200 milliseconds between turns. That gap is remarkably consistent across languages and cultures, and we are exquisitely sensitive to deviation from it. A pause noticeably longer than that reads as hesitation, confusion, or a bad line — before a single word arrives.

That 200ms is the entire budget for a voice agent, and it has to cover everything: detecting that the user stopped speaking, transcribing, sending to a language model, generating a response, synthesising speech, and network round trips in both directions.

Voice quality itself is largely solved — ElevenLabs settled that argument years ago. Time-to-first-byte for speech synthesis is one slice of that budget. At 20ms P90, the flash model consumes a tenth of it, which leaves genuine room for the model call — which is where the unavoidable time actually goes.

That is why an infrastructure company optimising this specific number matters. Every millisecond saved in synthesis is a millisecond available for thinking, and thinking is what makes the answer good.

Two caveats on reading these numbers honestly. They are server-side, so your users' network latency sits on top and can dwarf them. And P90 means one call in ten is slower — in a conversation of thirty turns, that is three noticeable pauses. Ask about P99 if you are building something that must feel consistently natural.

The Router Is A Bet Against Model Lock-In

Realtime Router — access to 220+ models across third-party providers and Inworld's own inference — is the most strategically interesting product in the set.

The premise is that model choice should not be an architectural commitment. Models are released constantly, prices move, and the best option for a given task changes on a timescale much shorter than the life of an application.

Routing through one integration means switching is a configuration change rather than a rewrite. It also enables the pattern that actually saves money in production: sending routine turns to a cheap fast model and difficult ones to an expensive capable one, rather than paying frontier rates for every hello.

The first-party and third-party split is worth noticing. Offering both its own inference and external providers means Inworld is positioning as a neutral layer rather than only selling its own capacity — which is more credible than it would be otherwise.

The dependency to think about is the ordinary one for any abstraction layer: you are adding a hop between your application and the model provider, which introduces both a latency cost and a point of failure. In a product where latency is the selling point, that trade-off deserves measuring rather than assuming.

A specialist recogniser like Speechmatics is the alternative if transcription is your only need. Offering established third-party STT models alongside its own — Whisper via Groq, AssemblyAI, Soniox — follows the same neutral-layer logic and is a reasonable signal of confidence.

1. Measure end-to-end latency from a real user's network, not server-side figures.
2. Ask for P99 as well as P90 — the tail is what users remember from a conversation.
3. Test the router's added hop against calling a provider directly, and quantify the difference.
4. Try cross-lingual voice identity on your actual target languages before believing the count.
5. Run a full thirty-turn conversation rather than judging on single utterances.

Metered By Usage

This site does not publish plan prices. Inworld's structure is usage-based, which is the correct model for infrastructure and has consequences worth planning for.

You pay for what you generate — audio synthesised, audio transcribed, tokens routed — rather than for seats or a subscription. That means cost scales directly with success, which is either reassuring or alarming depending on your product.

The specific risk in voice applications is that usage is not proportional to value. A companion app user who talks for three hours generates the same synthesis cost whether they subscribed or are on a free tier. Consumer voice products can be structurally difficult to make profitable for exactly this reason, and modelling cost per active user is more important here than in most categories.

Two things worth establishing early. First, whether the flash and standard TTS models are priced differently, since the latency premium usually is. Second, how the router prices — whether there is a margin over the underlying provider's rate, and whether first-party inference is cheaper than routing out.

VPC deployment is offered for enterprise, which changes the economics and the data posture together. For anyone in a regulated environment, or handling voice data with residency requirements, that is the conversation to start with rather than the public API.

One point specific to voice: recorded speech is biometric data under several privacy regimes, and the obligations that attach to it are stricter than for text. Settle where audio is processed and how long it is retained before you build on any voice API.

The Boundary Of What You Are Buying

Being clear about the boundary saves the wrong buyer a wasted week.

A deployed agent such as Phonely is what a finished product looks like at this layer. It is not a finished product. There is no interface to log into and configure an agent. These are APIs and models, and you need engineers to assemble them into something. If you want a working phone agent rather than the parts of one, this is the wrong layer.

It is not a game character platform any more, whatever the historical coverage says. No engine integrations appear in the current material, and building an NPC on this means writing the character logic yourself on top of the voice layer.

It is not the reasoning. The router gives access to models; the quality of what your agent actually says is a function of the model you choose and the prompting you write, not of the infrastructure.

What it genuinely is: a specialised, latency-obsessed voice layer for people building conversational products, with the neutrality to avoid tying you to one model provider. For that buyer it is a strong offering, and the named customers — a companion app, a religious chat product, a language learning tool — fit that shape precisely.

• APIs and models, not an interface you configure an agent in
• No game engine integrations in the current product set
• Voice quality and latency, not the reasoning your agent performs
• Requires engineering to become anything a user can touch
• Best suited to teams already building a conversational product