Hume Audio Decision API: Pricing, Access and What It Actually Returns

Hume introduced its Audio Decision API on November 2, letting developers ask questions directly about recordings and receive structured probabilities. It costs $0.47 per million input tokens. For teams evaluating voice agents or reviewing calls, the appeal is a configurable way to inspect how conversations sound.

The launch announcement invites developers to request access. This is an announced API with documentation and an access process, rather than evidence that every developer can immediately use it.

What the Audio Decision API does

You send a recording, questions and optional context. A question can ask whether an agent interrupts a caller, which category best describes a sound, or where a voice falls on a naturalness scale. The model processes multiple questions in one inference.

There are four answer types: yes/no judgments, choices between supplied options, ordered scores and time spans. The API returns numbers rather than a transcript or an explanation. Your application decides what those numbers should trigger.

That distinction makes it useful alongside transcription. A transcript helps establish what was said. A judgment about overlapping speech or how an answer sounded addresses a different part of the interaction. A team could review whether its voice agent completed a task and separately check whether listeners would find the exchange awkward.

Hume Audio Decision API pricing

The billing documentation lists $0.47 per million input tokens, with no commitment. Audio, questions and context count toward input usage; output answers are not billed. Organizations receive a one-million-token trial credit after access is granted.

Audio duration accounts for most tokens, including silence. Adding several short questions costs relatively little compared with sending the recording again. Hume provides a token-estimation endpoint, so a team can price its actual questions and clip lengths before running a batch.

How recordings are split matters too. Overlapping windows repeatedly charge for the same audio. A cheap per-token price therefore does not make every monitoring design equally cheap. Start with the decision you need, then choose how frequently to inspect the conversation.

File limits and live audio

The documented limits are specific:

• One MP3 or WAV file per request, lasting 5 seconds to 5 minutes.
• A maximum request size of 25,000,000 bytes.
• Up to 20 yes/no, choice and score questions combined, plus up to five span questions.
• 60 requests per minute per organization, shared across API keys.

The current API uses HTTP file requests. Live audio must be sent as clips; it is not a persistent streaming endpoint. At one clip every five seconds, five simultaneous calls would consume the entire 60-request allowance before other API requests. That makes concurrency a practical constraint for a production pilot.

Hume’s integration guide also labels time-span detection experimental and most reliable for vocal bursts and sound events. A system that needs exact timestamps for every spoken event should validate that requirement separately.

A probability is a listener judgment

These probabilities estimate how human raters would answer. A yes/no result of 0.6 means an estimated 60% would choose yes. It does not establish a person’s internal emotional state, or mean that a caller is “60% frustrated.”

Hume reports 70.7% agreement with a human panel’s average judgment, compared with a 56.5% individual-rater baseline. That is a vendor-reported result on its evaluation. It does not establish the same performance on your callers, microphones or languages.

The answer-interpretation guide contains a more consequential implementation detail: answers can change when questions are added, removed or reordered. Thresholds should be checked again when the request, recording conditions or model changes.

This means the question set belongs in version control alongside application logic. Adding a useful new check is also a reason to rerun evaluation, even when the old question’s wording stays untouched.

Where this is useful first

A sensible first deployment is a review queue: flag recordings for a person to inspect, measure false positives and missed cases, then adjust thresholds against representative audio. Hume documents a review band for borderline answers rather than forcing every result into an automatic action.

The useful change is that teams can express more audio checks as questions. The work that remains is deciding which judgments deserve action. If changing a question is easy but validating its consequences is neglected, a simpler integration can still produce a less trustworthy product.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product launches and complex engineering work into clear stories developers actually read and share.

Book a 30-minute call.