If you want a language model — Claude, GPT, Gemini, whichever — to reason about what was said in a call, the obvious route is handing it the whole transcript. It's also the expensive one, by a margin that surprises people.
Measured on a real 70-minute recording of varied prose, counted with the
o200k_base tokenizer:
| What you send the LLM | Words | Tokens |
|---|---|---|
| Full transcript | 10,429 | 15,410 |
| Structured summary | 294 – 422 | 484 – 673 |
Twenty to thirty times fewer input tokens.
The range isn't sloppiness: summarizing is not deterministic. The same recording, summarized twice, gave 484 and 673 tokens. Publishing only the good number would have looked better and been less true.
And the saving grows with duration. The transcript grows in a straight line with the minutes of audio; the summary doesn't. On a three-minute clip it makes no difference. On an archive of calls it's the difference between an invoice you can pay and one you can't.
This is where most articles about "token optimization" go quiet.
A summary is a deliberate loss of information. If your prompt depends on a literal quote, on the exact moment something was said, or on a detail that appears once and in passing — an order number, an amount, a surname — the summary may not carry it.
And on short recordings it saves nothing. On a 90-second clip, the same script that measures all of this reports 1.2×: the summary is almost as long as the transcript. Below about five minutes, it isn't worth it.
The practical rule we work with:
Summary for "what was this about and what needs doing?". Transcript for "what exactly did they say?".
/v1/summarize returns summary and transcript in the same response. You choose in
your code which of the two goes up to the LLM, and you don't pay twice for deciding.
If only the summary reaches that third party, the recording and the literal transcript never leave your voice provider. Less exposed surface, and one fewer international transfer to justify in your record of processing activities.
There's a detail in the example we publish that's worth copying even if you don't use our code: the payload it generates puts the summary in the user turn and warns, in the system turn, that this text is data, not instructions. Everything that comes out of a transcript came from audio you don't control. Someone may have said something shaped like a command out loud, on purpose.
The runnable example — summarize here, measure what you saved, and write out the exact payload you would send — is in uttera-examples/llm-tokens. It sends nothing to any third party: it lets you read what you're about to pay before you pay it.
Anything to add or correct? Write to support@uttera.ai. If you correct us, we edit the post and credit you.
Uttera