Most of what gets written about voice AI economics comes from people who read the pricing page once and did the arithmetic. We don't have that luxury. Dissolve Labs builds voice AI products for clients, and Luqas, a voice AI product we designed and built, sits in our own portfolio: real architecture decisions, real vendor evaluations, real bills to reconcile. When the invoice doesn't match the mental model you built from a rate card, you don't get to write a blog post about it. You have to go fix it.
This post is about that process, kept general on purpose: this isn't a teardown of the product, a vendor scorecard, or a tour of our internal stack. It's proof that the pattern is real, because we lived it.
The assumption we started with
When native speech-to-speech (S2S) models arrived (architectures where a single model handles listening, reasoning, and speaking in one continuous realtime session), the appeal was obvious: one model, one session, less orchestration than stitching together separate transcription, language, and voice-synthesis stages. We expected the simpler architecture to also be the cheaper one, or at least cost-comparable once you accounted for the reduced engineering overhead. That assumption is where the lessons started.
Lesson one: the caching discount you're used to isn't there
In a traditional cascaded pipeline, a text-based LLM call typically benefits from prompt caching, the parts of a growing conversation that haven't changed get billed at a steep discount on repeat calls. It's one of the more reliable cost levers in LLM applications, and most cost modeling assumes it's there.
Native S2S models, structurally, don't get to use it the same way. Because the entire conversation lives inside one continuous realtime audio session, every turn re-sends and re-bills the growing history from scratch, at full price, with no discount for content that hasn't changed. We confirmed this across more than one S2S vendor's realtime/live model line during evaluation, not a one-vendor quirk, but a structural property of the architecture itself.
One vendor advertises a "context caching" feature prominently in its documentation, and on paper it reads like it should solve exactly this problem. In practice, that caching feature does not apply to that vendor's realtime/live model, it's scoped to other model types. Price a project against that advertised feature without checking which models it actually covers, and you'll build a cost model that's wrong before you write a line of code.
Lesson two: the invisible reasoning tax
The second discovery was subtler and more consequential. At least one major realtime voice model we evaluated carries what we've come to think of as an invisible reasoning tax: a meaningful share of what you're billed for as "output" is internal reasoning or "thinking" content the model generates before producing the audio a user hears, and that reasoning is never surfaced to the end user at all.
We confirmed this directly against that vendor's own documentation, not through guesswork. On the model tier in question, there was no setting to configure it down or switch it off, it's simply baked into how the model produces a response. If your cost estimate is built purely off "tokens per second of audio," you are almost certainly underestimating what a real conversation will cost, and by more than a rounding error.
This is easy to miss because it doesn't show up in a demo. A five-turn sales demo with short exchanges won't expose it. It shows up when you compare billed usage against actual conversation transcripts at meaningful volume, a comparison you can only really make once you've built and tested something for real, not evaluated it from a spec sheet.
Lesson three: the tier trap
The third lesson surprised us the most, because it wasn't about choosing between vendors at all. We found that picking the wrong pricing or model tier within a single vendor's own lineup created a bigger swing in cost than switching between entirely different vendors would have. In our case, the wrong tier choice more than doubled the cost of the same workload, before we ever touched a competing product.
Rate cards for realtime voice models often bury meaningful differences in footnotes: separate rates for audio input versus output, separate rates for text tokens in the same session, tier-gated features that silently change your effective price per minute. Skimming the top-line number on a pricing page isn't enough, and by the time it's obvious it isn't, it's usually already baked into a production build.
What changed, and what it got us
Once we'd identified all three issues, we rebuilt our approach to Luqas's voice AI cost estimation from the ground up. Against the same production workload, the corrected architecture landed at a ~74% reduction in per-call infrastructure cost, with turn latency cut to ~620ms including interruption handling. These are directional production benchmarks from our own build, not a vendor-comparison guarantee, but they are the actual numbers we measured once all three corrections were layered together.
Before the three corrections, and after
Directional production benchmarks from Luqas's own workload
Per-call infrastructure cost
↓ ~74% lower
Same workload, right architecture + tier + reasoning cost priced in
Turn latency
~620ms
Including interruption handling, measured in production
The general takeaway
The lesson isn't "pick vendor X" or "avoid architecture Y." It's that pricing at the token and architecture level has more traps in it than any rate card will ever admit to, and most of them only surface once you've built and tested something for real.
We learned all of this the way most real lessons get learned: by building Luqas, testing it against real usage, and reconciling the bill against our assumptions.