Hume AI has opened access to the Audio Decision API (Decision Model API) — an audio-native model that answers questions about speech and sound directly from raw recordings, bypassing transcription. Users provide the model with audio, a list of questions, and allowed answers, and receive a probability with a confidence score for each option. The company describes this interface as a decision layer over audio: claimed metrics are higher than those of several omni-models, but the model cannot yet be tested on proprietary data because access is only available via a waitlist application.

image
image

What happened

The launch was confirmed in the Hume API changelog on November 2, 2026. The input consists of an audio recording, a list of questions, and a set of allowed answers; the output is the model returning probabilities for each option along with a confidence score, without intermediate speech transcription. Four answer formats are supported: yes or no, selection from pre-defined options, rating on a scale, and specifying a time span within the recording, such as the moment when interlocutors laugh or sigh. According to the company, the model matched the average opinion of a group of listeners in 70.7% of cases, compared to 56.5% for an individual assessor, scored an average of 0.82 across 10 benchmarks, and showed a median latency of 0.23 seconds. The vendor also claims that the model outperforms Gemini 3.8 Flash, Qwen3.8-Omni-Flash, Inkling-Small, gpt-audio-1.5, Gemini 3.5 Flash Lite, and Nemotron 3 Nano Omni. Access is available via a waitlist application, with a starting price of 47 cents per million input tokens.

Context

Before the emergence of such interfaces, conversation analysis tasks were solved using a pipeline: first, an ASR system produced a transcription, then separate classifiers determined speakers, language, emotions, and non-speech events like laughter or background noise, with rules, post-processing, and manual annotation layered on top. Free-form questions about audio can already be asked of multimodal omni-models, so Hume's claim of the "first audio-native model" is better read as a vendor categorization: what is new here is likely the combination — a narrow list of questions, probabilistic output, confidence scoring, and spans instead of free text. This interface shifts audio understanding from text generation to calibrated classification, the output of which is suitable for automatic thresholds and business rules without post-processing. In Hume's publications, the launch is presented as the emergence of a decision layer between the recording and application logic.

Why this matters for the industry

For teams building contact centers and voice agents, the value lies in the fact that a single API call replaces a stack of ASR, diarization, emotion analytics, event detection, and manual annotation. Call quality control transforms from a separate project into a configuration: rubrics are described by lists of questions and allowed answers, confidence thresholds are tied to the client's business rules, and the set of questions can be changed without retraining the model. The low claimed latency opens up live scenarios: automatic scoring of each recording, live agent coaching, and auto-escalation for voice agents. While access is limited, realistic preparation for teams looks like this: describe exactly which stack is being replaced by a single call, assemble an evaluation set of labeled proprietary calls with noise and jargon, and record hypotheses for the pilot. If the metrics are confirmed in independent verification, the "decision layer over audio" pattern may become a standard block between the recording and business logic, and some specialized services — diarization, audio analytics, event detection — may be absorbed into it.

Why this matters for users

For readers, this promises tools that understand not only words in a recording but also intonation, pauses, laughter, background noise, and the number of speakers, and answer arbitrary questions about the content and "tone" of the conversation. A product cannot be built on this API right now, as access is granted via a waitlist application, so reasonable steps today are: submit an application, study the documentation at dev.hume.ai/audio-decisions and the Python/TypeScript SDK, and design lists of questions and answer formats for your own tasks — yes or no, options, scale, span. For those who host podcasts, record calls, or collect voice feedback, the interface promises automatic archiving tagging and event search by timecodes in the future, although this is currently more of a development direction than a ready-made scenario.

What is currently unknown / limitations

All key figures — 70.7%, 56.5%, 0.82, and 0.23 seconds — are currently vendor claims: there is no independently verified evidence, and the model is not available for testing on proprietary data. The comparison of 70.7% agreement with the average opinion of a group of listeners versus 56.5% for a single assessor is also methodologically opaque: it is unclear from open materials how the group was formed, what the question sample was, and whether the group average can be considered ground truth; formally, this is an agreement metric, not a confirmation of accuracy. The quality of the span format is not disclosed: sources contain neither a metric nor a tolerance in seconds for the boundaries of time segments, so building a ready-made interface or "semantic" indexing on spans is premature. Finally, the details of the economics beyond the input token price in the entire chain of converting audio to tokens and the timelines for expanding access are not described.

Sources

Author

Look at AI, editorial team