The Real Unit Economics of Multimodal: Why a Second of Audio Isn't a Token

A text token, an audio-second, and an image tile are three different pricing meters with three different growth curves — treating them as interchangeable "AI usage" is how voice and vision features quietly post 10-100x the cost-per-user of a chat feature. The fix is a per-modality cost model built before launch, not after the invoice.

Quick answer: Model each modality on its native billing unit — tokens for text, seconds for audio, tiles/resolution for images — then multiply by realistic usage patterns per persona. Voice and vision inputs routinely cost far more per interaction than text, so cap duration/resolution and push processing on-device wherever you can before promising "unlimited" multimodal.

Why "it's all just AI cost" is the wrong mental model

Multimodal cost planning fails when PMs reuse a single "cost per request" number across text, voice, and vision. Each modality is billed on a structurally different unit, at a different rate, with different scaling behavior as usage grows — so one blended average hides where the money actually goes.

Text is billed in tokens — roughly 4 characters or ¾ of a word each. A typical chat turn might run 200-2,000 tokens combined (prompt + completion), and providers price input and output tokens separately, often at a 3-5x output premium.

Audio is billed by duration, not content. A minute of speech-to-text or a minute of a real-time voice API costs the same whether the speaker is silent half the time or speaking rapid-fire — you're paying for the clock, not the words.

Images are billed by resolution and tile count. Vision models chop an image into fixed-size tiles (commonly around 512x512px) and charge per tile, so a high-resolution screenshot can cost 5-10x what a compressed thumbnail costs for the same visual information.

Quick answer: These aren't just different prices — they're different shapes of cost curve, so a feature that looks cheap in a demo (one short clip, one small image) can look completely different at the usage patterns of your actual power users.

The core mistake: extrapolating from a demo

Most cost surprises trace to one root cause: someone modeled cost from a 10-second demo clip or a single low-res screenshot, then multiplied by expected daily active users without asking how long real sessions run. Demo economics and production economics are rarely the same distribution — production has a long tail of unusually long recordings, high-res uploads, and heavy users who dominate aggregate spend. This is the same "average user" fallacy MIT Sloan researchers have long warned distorts unit-economics models: means hide the tail, and the tail is where margin dies.

Building the per-modality cost model

A usable model answers one question per modality: cost = rate × unit-of-use × usage frequency, computed separately, then summed per active user. Skipping the "separately" step is the single most common modeling error.

Text: tokens in, tokens out

Text costs scale with two independent levers — context length and output length — and both grow with product decisions, not just user behavior.

1. Prompt tokens grow with system prompts, retrieved context, and conversation history you replay each turn.
2. Completion tokens grow with verbosity — a model instructed to "explain thoroughly" costs more than one told to answer in bullets.
3. Caching (prompt caching, where supported) can cut repeated-context cost by 50-90% for stable system prompts, per published provider pricing structures — this is the highest-leverage lever most teams under-use.

Audio: the meter runs on the clock

Speech-to-text and real-time voice APIs are priced per minute or per second of audio processed, independent of information density. This is the modality PMs most often underestimate, because a "quick voice note" framing hides that background silence, filler words, and re-recordings all bill the same as content.

• Batch transcription (upload-then-process) is typically the cheapest audio unit — you pay once for the clip length.
• Real-time streaming voice (bidirectional, low-latency) usually costs more per minute than batch transcription, because it reserves a live model session rather than a queued job — this is the economics behind the latency-budget tradeoffs discussed in the half-second voice latency budget.
• Text-to-speech output adds a second, separate meter — usually billed per character or per minute generated — that teams forget to model when a feature both listens and talks back.

A feature that says "just talk to it" is implicitly promising an unmetered clock. If your PRD doesn't cap session length, your finance team will eventually cap the feature for you.

Images: tiles, resolution, and count

Vision cost is driven by how many tiles a model needs to represent an image, which is a function of resolution and your compression choices — both are levers you control at upload time.

Most vision APIs expose a low/high "detail" parameter precisely so PMs can trade fidelity for cost — defaulting every upload to high detail is a common, avoidable overspend.

The worked example: cost per active user, three modalities

Consider a support-triage feature that lets a user type, speak, or screenshot an issue. Assume 1,000 monthly active users, each averaging 8 interactions/month, split evenly across modalities.

1. Text interactions (≈2.7 per user): ~1,500 tokens each, blended input/output rate — roughly $0.01-0.02 per interaction.
2. Voice interactions (≈2.7 per user): ~45 seconds average clip, real-time streaming — roughly $0.15-0.35 per interaction depending on provider tier.
3. Image interactions (≈2.7 per user): one screenshot at medium detail plus a short text response — roughly $0.03-0.08 per interaction.

Voice, at roughly a third of the interaction volume, drives over three-quarters of the cost. That's the 10-100x-per-interaction gap between modalities showing up as a lopsided cost-share even at equal usage frequency — and it's invisible in any model that tracks "AI interactions" as one undifferentiated metric.

Levers that actually move the number

Once the per-modality breakdown is visible, four levers do most of the work — and they map directly onto product decisions, not just vendor negotiation.

• Duration and resolution caps. Capping voice clips at 60-90 seconds and defaulting images to "low detail" mode removes tail-risk cost without most users noticing, because typical usage sits well under the cap.
• On-device processing. Running speech-to-text, wake-word detection, or basic image preprocessing in the browser or on-device shifts marginal cost to near-zero for the covered path, because there's no metered API call at all.
• Caching and reuse. Prompt caching for stable system context, and de-duplicating repeated image analysis (e.g., the same screenshot re-sent across turns), both cut real spend with no user-facing change.
• Tiered routing. Send short, simple voice clips to a cheaper batch-transcription path and reserve real-time streaming for cases that genuinely need sub-second turnaround — see the multimodal and voice complete guide for how routing decisions interact with UX quality.

Where the "unlimited" promise breaks

"Unlimited voice" is a marketing sentence sitting on top of a per-second meter — it works only if you've capped clip length, routed to the cheapest adequate tier, and built margin assumptions into pricing tiers before the promise ships, not after usage data arrives.

Quick answer: Treat "unlimited" as a UX word, not a billing word — cap the underlying meter, then let the UI feel unbounded within that cap.

Where Prodinja fits honestly

Prodinja's Journals feature includes browser-native dictation for capturing product notes and reflections by voice — a concrete example of the on-device lever in practice. Because the speech capture runs in the browser rather than round-tripping audio to a metered streaming API, the marginal cost of that voice input stays near zero regardless of how often a PM chooses to dictate instead of type. It's one narrow but honest illustration of the pattern this article argues for: match the processing location to the cost sensitivity of the modality, rather than routing every voice interaction through the most expensive real-time path by default. For teams building capture-first features, the case for voice dictation as a capture feature walks through the product reasoning further, and the correction-and-trust tradeoffs of voice input are covered in error correction in multimodal interfaces.

Key Takeaways

• Text, audio, and image inputs bill on different meters — tokens, duration, and tile/resolution respectively — so a blended "AI cost" average hides where money actually goes.
• Audio is billed by the clock, not the content, making duration caps and batch-vs-streaming routing among the highest-leverage cost decisions in a voice feature.
• Image cost scales with resolution and detail-mode settings, both of which are product-controllable inputs, not fixed vendor costs.
• Model cost per active user by modality separately, then sum — a worked example can show one modality driving 70%+ of spend despite lower usage share.
• On-device processing, caching, and tiered routing are the levers that preserve margin without visibly degrading the user experience.
• "Unlimited" should describe the UX, not the billing — cap the underlying meter first, and design the interface to feel unbounded within that cap.