26,185 tokens for a 78-second phone call

We used to run our voice agents on a hosted platform. Before we moved them onto our own runtime, we pulled one invoice apart line by line — a single call, 78 seconds, $0.21.

We expected the platform fee to be the story. It wasn't.

The breakdown

A 78-second call is 1.3 minutes, so that's $0.16 a minute — considerably more than the ~$0.11/min the platform's own cost estimator had predicted for this stack. The estimator doesn't include the analysis pass.

Nearly half the invoice was spent after the caller had already hung up.

The part nobody talks about

The largest single line on that bill was not the conversation. It was the post-call analysis: a separate LLM pass over the full transcript to extract structured output.

At $0.10 for one 78-second call, that's $0.077 a minute for a step the caller never experiences. It happens after the call ends. It doesn't affect quality, latency, or whether the agent did its job. And it's the biggest thing you're paying for.

If you run 20,000 minutes a month, the analysis pass alone is about $1,500 a month. Most people we've spoken to have no idea this line exists, because it's aggregated away in the monthly total.

Where the tokens go

The invoice also breaks down the language model call:

Prompt tokens:      26,185
Cached tokens:      14,080   (54%)
Completion tokens:     257

26,185 prompt tokens for 78 seconds of conversation. That's roughly 20,000 prompt tokens per minute of speech, against 257 tokens of actual output.

That ratio tells you what's happening: the full context is being re-sent on nearly every turn, and only about half of it is hitting cache. On a ten-turn conversation with a system prompt, a tool schema and a growing transcript, you re-pay for the same tokens ten times over.

This is the thing that never shows up on a pricing page. Pricing pages show you rates. Your bill shows you the multiplier.

What we measured on our own runtime

We rebuilt the execution layer and moved the same agents onto it. Over 409 calls and 908 minutes of our own production traffic:

That $0.019 covers speech-to-text, the language model, speech synthesis and the same post-call analysis. All of it.

For comparison: the analysis pass alone on the hosted invoice was $0.077 a minute — four times our entire per-minute cost, analysis included.

The stack is not a budget configuration. It's Deepgram Nova-3 for speech in, GPT-5.4 and GPT-5.4 Mini for reasoning, Cartesia Sonic 3.5 and ElevenLabs Turbo v2.5 for speech out. Blended across those routes, $0.019.

Two things produce most of the gap, and neither is exotic:

• Don't re-send what you don't need to. Aggressive context reuse and cache discipline cut the prompt token count per turn substantially.
• Don't run a second full-transcript LLM pass at the end. The runtime already holds the structured state it needs during the call. Extracting it afterwards is cheap when you haven't thrown the state away.

The latency arithmetic almost everyone gets wrong

The same platform's configurator displayed this for our stack:

Speech-to-text     300 ms
Language model     860 ms
Speech synthesis   490 ms
─────────────────────────
                 1,650 ms

That number is the sum of the stages. It's what a turn costs if you run the three steps one after another and wait for each to finish.

Our runtime delivers first audio in 150 ms from end of speech, p50, on the same class of stack.

That is not a claim that we made GPT-5.4 eleven times faster. It's a different quantity, and the difference is the entire point: you never wait for all three stages. Speech-to-text streams and finalises early, the model starts emitting before it has finished thinking, and synthesis begins speaking on the first clause rather than the last. The caller stops waiting long before the turn is complete.

The corollary is the useful part: the slower your model, the more this is worth. A premium model with 860 ms of inference is exactly the case where streaming and segmentation pay for themselves. You can afford quality because the caller doesn't hear it.

The capacity surprise

We load-tested the runtime at 150 simultaneous voice calls on a 4-vCPU, 16 GB machine. We publish a recommended envelope of 50 to leave real operating headroom.

That surprises people, and it shouldn't. A voice runtime does almost no heavy computation — the models all live at the providers. What's left is orchestration: WebSocket connections, audio buffers, endpointing, stream muxing. That's I/O-bound, and audio at telephony sample rates is tiny.

Practically: a machine costing $13–29 a month handles more concurrent calls than most voice businesses ever run. Infrastructure is not the reason self-hosting is expensive. It mostly isn't expensive.

What this isn't

One invoice is one invoice. It's from our own former account, on our own agent, with our own call profile. Yours will differ — different prompt sizes, different call lengths, different tool usage, and possibly no structured output at all, in which case that 46% line doesn't exist for you.

Our own $0.019 is a blended average across the model routes above, valued at configured provider rate cards. It excludes carrier, infrastructure, storage and taxes.

The 1,650 ms figure is the platform's own estimator output for that configuration, not a measurement of their real-world perceived latency — they stream too. We compare our measured first-audio latency to the sum of published provider stage latencies, because that's the quantity a turn engine actually has to hide.

We're not claiming a controlled benchmark. We're showing you a bill and our own metering, and telling you how to read both.

What to do with this

Whatever you're running on, three things are worth checking on your own account this week:

1. Is there a post-call analysis line on your invoice, and how big is it? If you're not using the structured output, you may be paying for a pass you don't need.
2. What's your prompt-token count per minute of conversation, and your cache hit rate? That number is the difference between a rate card and a bill.
3. What are you actually paying for latency you never see? The sum of your provider stage latencies is not what your caller experiences — unless your runtime makes it so.