Hume AI has introduced an Audio Decision API that answers questions about speech and sound with probabilities over developer-defined choices. The November 2 launch targets applications that need a structured judgment about a recording, rather than a transcript or a conversational response.
The announcement describes questions about speaker behavior, background sounds, conversational dynamics and perceived vocal expression. Developers can define yes-or-no questions, choices, rating scales or event spans. Hume says its model draws on human judgments about how speech and sound are perceived.
How the interface works
The documentation specifies a file-based request containing an MP3 or WAV recording, questions and optional context. Supported files run from five seconds to five minutes. The response returns structured values that an application can rank, combine or compare with a threshold.
An important distinction concerns interpretation: the documentation says a probability estimates the share of human raters who would give an answer. A value near one-half can therefore reflect divided listeners, rather than merely low model confidence. The launch invites developers to request API access through a waitlist.
Where the decision layer fits
Our analysis is that this interface can be useful when a voice workflow needs repeatable checks. A team evaluating a synthetic voice might ask about intelligibility, naturalness and interruptions separately. Keeping those questions distinct makes the resulting signal easier to inspect than a single broad assessment of whether a call went well.
It also creates a need for calibration on representative recordings. A threshold chosen from a clean demonstration may behave differently with accents, background noise or several people speaking. Teams should compare the model’s outputs with human judgments drawn from the population and conditions the product actually serves.
Perceptual judgments should remain attached to the recording and question used. A system that detects frustration is estimating how a voice sounds in context; it is not establishing a person’s internal emotional state. Product behavior should reflect that distinction, especially when an automated score could affect how someone is treated.
The most useful initial integration is a bounded review workflow. Collect outputs, inspect false positives and missed cases, and decide where human review adds value before connecting a score to consequential actions.
Hume’s release offers a specialized alternative to asking a general audio model for a written explanation. Its practical value will depend on whether the returned probabilities support reliable decisions in the developer’s own voice and audio workloads.