Model a realtime voice agent and the back-of-envelope math almost always starts the same way: take the per-minute rate, multiply by expected call minutes, done. Buried in that math is a quiet assumption: roughly one exchange, one "turn," per minute of call time. It feels conservative. It isn't.
Against our own production traffic, real cadence ran several times faster than that. People interrupt, backtrack, ask follow-ups, and the agent responds in kind, all inside the same sixty seconds a naive model books as a single exchange. That alone means a "per-minute" estimate is quietly undercounting how many billable turns actually happen inside the minute it's pricing.
What a "per-minute" model assumes vs. what a call actually does
Indexed to the naive assumption
It gets worse before it gets better, because of how two of the major realtime voice models are actually built: they re-bill the entire growing conversation from scratch every turn, with no discount for content that hasn't changed. That turns a cadence-counting mistake into a curve that bends the wrong way: the error compounds the longer a real call runs, instead of staying a fixed percentage off.
There's a second gap that has nothing to do with counting turns at all. On at least one major realtime model, a meaningful share of what you're billed for as "output" is internal reasoning content generated before the reply a caller actually hears, never surfaced anywhere, billed at the full output rate, with no setting to turn it off. If your cost model only counts the words in the transcript, it's missing a real slice of the bill by design, not by oversight.
Not every vendor has the same weak spot, either. One of the three we've tested is architected differently enough that its cost curve should hold up better under exactly the conditions that hurt the other two, but whether that actually holds at volume is the kind of thing you only find out by testing against real traffic, not a spec sheet. Which is exactly why we don't publish a single "here's the formula" model for this: the real formula changes per vendor, per model tier, and per your own traffic pattern, and getting any one of those inputs wrong understates the bill in a way that only shows up once you're already committed to the architecture. The exact multiplier is model- and traffic-dependent, shown here as an illustrative index, not a number to copy into your own spreadsheet.
We build voice AI cost models against real call data, not rate cards, because that's the only way gaps like these ever surface before the invoice does.