TL;DR
Hume’s Audio Decision API accepts audio and developer-defined questions, returning probabilities rather than a transcript or generated explanation. It could complement speech recognition in voice agents, but vendor-reported accuracy and latency do not replace task-specific human validation.
Introduction
A voice agent can transcribe every word correctly and still mishandle a conversation. Interruptions, background noise, hesitation or vocal delivery may matter to the next action even when the words alone look unremarkable. Turning those signals into operational decisions, however, is not the same as reliably reading a person’s feelings.
Hume’s Audio Decision API proposes a separate layer: send audio with questions and possible answers, then use the returned probabilities in application code. The launch describes questions about sound, speech and conversation, while the documentation makes clear that the model does not generate a transcript, conversational response or explanation. (Source : Hume — Audio Decisions overview)
A structured answer instead of a generated paragraph
The API supports questions such as yes/no classification, multiple choice, ratings and time spans. A support workflow might ask whether multiple people are speaking or where an interruption occurred, then pass those signals alongside a transcript to another component. That division is useful: transcription identifies words; a separate classifier can assess other properties of a recording. (Source : Hume — Introducing the Audio Decision API)
There is a cost to this simplicity. A probability does not explain why the system chose it. For review, engineers should record the question wording, model version where available and downstream rule, and retain audio only when permitted and necessary. They should also treat emotionally loaded labels as descriptions of perceived expression, not as clinical facts about a speaker’s internal state.
Hume’s documentation says probabilities estimate how people would answer a question. A result near one half can therefore reflect disagreement between human listeners rather than just uncertainty in the model. Changing the question or its answer options can change what the number means. (Source : Hume — Interpreting answers)
What the published numbers do and do not show
Hume reports 70.7% agreement with the average judgment of a human panel in an initial evaluation, compared with 56.5% for an individual-rater baseline. Its product page reports a 0.82 aggregate across ten benchmarks and a median 0.23 seconds per screen. These are company-reported results; the public descriptions consulted do not establish an independent replication or provide enough detail to transfer those figures to every use case. (Source : Hume — Launch evaluation) (Source : Hume — Decision model product page)
The comparison with a single rater is particularly easy to misread. Agreement with a panel average depends on the panel, questions, recordings and metric. A system can match that average without being right for an individual caller or a new language, microphone or acoustic environment. A benchmark headline is a starting point for evaluation, not a calibration certificate.
Likewise, a model latency number is not the full latency a caller experiences. Recording enough audio, uploading it, network travel, queueing, subsequent reasoning and any speech synthesis add to the delay. Teams building an interactive agent should measure end-to-end timing at the percentile relevant to their service, not substitute a median for the entire pipeline.
Boundaries that affect architecture
The published limits for file requests specify MP3 or WAV recordings between one second and five minutes, with a 25,000,000-byte limit for the entire request, including audio and metadata. Hume recommends at least five seconds for most questions. The documentation also describes limits on questions and request rate. Those constraints affect buffering and segmentation: a long call may require multiple windows, and a short urgent sound may need different handling from a retrospective quality review. (Source : Hume — API limits)
The launch describes live use, but file-size and duration limits should not be assumed to describe every streaming mode. Confirm the available interface and its current limits before designing a real-time product. Hume’s launch post directs readers to request access through a waitlist; availability and terms should be verified at deployment time. (Source : Hume — Launch announcement)
Cost needs similar care. Hume publishes input-token pricing and says audio, questions and context contribute to usage. The cost of a five-minute recording is not obvious from a per-million-token price alone; test representative clips, question counts and retry behavior. (Source : Hume — Billing)
A practical evaluation loop
Start with a narrowly defined decision that can be checked: for example, whether a second speaker interrupted the first. Collect representative recordings with consent, have multiple reviewers label them, and reserve a held-out set for testing. Then compare model output with both the reviewers’ agreement and the operational consequence of false positives and false negatives.
Do not use a single emotion label as an automatic basis for denying service, disciplining an employee or making another consequential decision. Route ambiguous cases to people, check performance across accents and recording conditions, and document retention and access controls for audio. Hume itself recommends validating evaluations against representative human ratings. (Source : Hume — Launch guidance)
The interesting shift is architectural: voice systems can separate generation from structured acoustic decisions. Whether that produces better agents depends on the evaluation and governance around the numbers, not merely on the API returning them quickly.
FAQ
Does the API transcribe calls?
No. The documented decision model returns structured probabilities, not a transcript.
Are its probabilities definitive measures of emotion?
No. They are model estimates related to human judgments, which can disagree and depend on the question.
Can it be used for live voice agents?
Hume describes live use, but builders should verify the interface, access and end-to-end latency for their own workflow.
Are the benchmark results independently confirmed?
The figures cited here are reported by Hume; independent replication was not established in the sources consulted.
Further Reading
— The Agent Report