I am building a realtime voice app. You speak, the model answers out loud. Cost scales directly with call time — there is no economy of scale. One number, cost per minute, decides the whole business.
I measured it. $0.1885 per minute. After Apple's cut, net revenue was $0.1416 per minute. All three subscription tiers were underwater.
I moved fast. I cut the included minutes to a third (60/120/300 → 20/40/100), added consumable minute packs, shipped the server and the app together.
The next day I learned the cost was wrong.
There is a number like this behind your pricing too. How many events produced it?
The sample was two minutes long
I re-measured for an unrelated reason. I had no key with permission to read organisation usage, so until then I had been reconciling dashboard totals against my own database. Once I had a key with the right scope, I read the server's own numbers for the first time.
Split by day:
- Aug 22: 122 seconds of talk, $0.41 → $0.20/min
- Aug 25: 1,052 seconds, $4.28 → $0.25/min
- Aug 24: 1,300 seconds, $1.11 → $0.05/min
Same app, same model, a 5× spread. Aug 24 was easy to explain: 46 payment-test sessions that burned clock without conversation, inflating the denominator. A known trap, already written down in my notes.
The other end was the problem. Aug 22's 122 seconds were two calls of about a minute each.
Short calls are expensive per minute
Breaking usage down minute by minute showed why. In the 34-minute continuous conversation on Aug 25, of 499,252 input tokens, 373,632 were cached. Cached tokens bill at 1/80th of audio input.
The longer a conversation runs, the more of it sits in cache, and per-minute cost keeps falling. A two-minute call has almost no cache. The fixed cost of opening a session — sending the persona instructions — lands entirely on those two minutes.
The "measured cost" I had trusted was the most expensive slice of the range.
Recomputed against realistic samples, the cost is roughly $0.12 per minute. At current pricing, net revenue is $0.4246 per minute, so the margin is about 71%. Not "all tiers underwater" — a healthy structure.
Which number would you have trusted?
This is where it forks. The pricing change had already shipped. Roll it back, or keep it?
I kept it. Cutting the minutes was the right direction anyway — retail price per minute tripled — and reverting would break faith with anyone who bought under those terms. But I wrote down that the reasoning behind it was wrong. The next person to make a decision from that number should not repeat my mistake.
Three things to check
Before you act on a unit number — cost, conversion, anything per-something:
- How many events are in the denominator? Two is an anecdote, not a measurement.
- Is that sample typical of real use? Short developer test sessions have a different cost structure from real ones.
- Does cost change with scale? With caching or fixed overhead, short samples always look expensive.
The honest part
The lesson here is not "use a bigger sample." Everyone knows that. The real problem is that I had already acted on the wrong number — changed code, deployed a server, shipped a build — before learning it was wrong.
Would a day of delay have helped? Probably not. The sample would still have been two minutes long. What I needed was not time but the habit of asking how many events produced this number.
I have written before about a conclusion that flipped once the denominator showed up — My Gate Wasn't Killing the Games — It Was Killing One Impression.
Pick the single most important number on your dashboard right now and check how many events it came from. Skipping that cost me a day.