Hume Audio Decision API: Ask Any Question About a Call, Get a Probability Back

Hume has launched an API that answers questions about audio instead of transcribing it. The company's launch post for the Audio Decision API, published November 2, 2026, says you write a question and its possible answers, send raw audio, and get back probabilities. Hume calls it "the first audio-native model that answers questions about speech and sound." Access is through a waitlist.

This post explains how it works, what Hume has and has not shown, and what to check before you point it at real calls. All performance claims below are Hume's own.

What Hume announced

Hume's pitch starts with a gap in call analytics. Contact centers score each call against a rubric, and changing the rubric is a project: a new pipeline, new evaluations and days or weeks before the first answer. Worse, the transcript those pipelines read holds only the words. In Hume's phrasing, it misses "the pause, the sigh, the two people talking over each other."

The Audio Decision API tries to fix that with a different architecture. Raw audio goes in. An answer with a confidence score comes out, structured so code or an agent can act on it. You choose the questions and the allowed answers, anything from "is this voice AI-generated" to "is the caller frustrated" to "is there a siren in the background."

The four question types

Hume lists these answer formats:

Adding a question is, in Hume's words, "a line of JSON," with no labels and no retraining. You can ask several questions of the same recording at once, such as background sound, language, accent and emotional expression, set confidence thresholds that map to business rules, and add context to each request to improve performance.

Hume groups possible questions into ten areas: speech and languages, speakers and voices, emotion and expression, acoustic environment, non-speech events, conversation dynamics, communication quality, intent and outcomes, social and behavioural signals, and temporal and contextual signals. The company points to a docs guide with example questions per industry.

The claims, sorted

Product posts mix facts, claims and plans. Here is how we sort Hume's.

Stated as available or planned, checkable now

• A playground for real-time and file-upload tests, where you can add your own questions.
• A waitlist for API access. We found no public pricing, rate limits or SLA in the launch post.
• Documentation covering supported questions and "experimental features."

Vendor claims we could not verify

• "The first audio-native model that answers questions about speech and sound." "First" claims are hard to confirm. Audio-language models that accept a question about a clip already exist from several labs, and we have not tested Hume's against them.
• 70.7% agreement with a human panel's average judgment, versus 56.5% for an individual-rater baseline. The post gives no dataset size, question mix, language coverage or confidence interval. Agreement with the panel average is a reasonable target for subjective questions, but a single percentage across all questions can hide big differences between easy ones (counting speakers) and hard ones (is the caller empathetic).
• Outperforms existing methods on "accuracy, speed and cost." The post names no baselines and shows no table.
• Archives of 40,000 recordings made searchable "in minutes." This is a stated capability with no published hardware, audio length or cost behind it.

Stated as a longer-term goal

• Live and ambient applications "remain a longer-term opportunity as real-time capabilities develop." That qualifier matters: the headline use today is analysis of recordings and use inside a cascaded voice agent, not a model that listens continuously.

None of this means the product is weak. It means the evidence is a launch post, not an evaluation you can reproduce. Ask for the evaluation set and per-question results during the waitlist conversation.

Why a "decision" API, and why now

The design echoes a broader shift toward models that return a typed, structured choice instead of free text. When an application only needs a judgment, generating a paragraph adds latency and cost, and you then need to parse it. Hume makes this point itself: "Generative models are useful for open-ended explanations, but generating text adds unnecessary work when all an application needs is a structured answer. Fixed classifiers tend to be limited to predefined tasks."

We have followed the same pattern in text and vision. See our coverage of GLiNER 2.5 Decide, the Liquid AI D1 vision decision model, the LFM3 family with decision models, and our guide to top uses of typed decisions. Hume's contribution is to apply the same idea to audio, where the signal that matters (tone, timing, overlap) never appears in a transcript.

For teams building voice agents, the practical comparison is with the speech-to-speech and live APIs from the big labs, such as OpenAI's GPT-Live-1. Those models talk. Hume's API judges. The two can be combined: Hume's own example pairs the audio judgments with a transcript and passes both to an LLM so it can decide whether to wait, clarify or escalate.

What you could build

Hume lists three directions. We add what to test for each.

1. Evaluate and improve voice models. Ask whether generated speech sounds natural, conveys the intended emotion or fits the situation, and compare checkpoints. Hume notes these judgments can guide data selection and RL feedback, and adds that teams "should validate their evaluations against representative human ratings." Do that. A learned judge can be gamed by a generator that optimizes against it.
2. Build more perceptive voice agents. A caller may say "I'm fine" while sounding frustrated, or pause because they are thinking. Feed the judgment to the agent next to the transcript. Test false positives carefully, because an agent that escalates on every sigh annoys people.
3. Analyze and search audio at scale. Find every call where the customer sounded frustrated, track expression over a call, jump to where a sound occurs. Spot-check the top and bottom of any ranking by listening.

Risks to check before you use it

Emotion inference from voice is sensitive, and the launch post says little about it.

• Consent and disclosure. Many places require notice or consent to record calls. Scoring emotion is an extra processing purpose on top of recording, and it may need its own legal basis and disclosure.
• Workplace limits. Some jurisdictions restrict emotion recognition of employees. The EU AI Act, for example, bans inferring emotions of people in the workplace and in education, with narrow exceptions, so scoring call-center agents' emotional state in the EU needs a legal review. We covered a related US debate in California's push against AI emotion tracking by robo-bosses.
• Perception is not truth. Hume trains on human judgments of how a voice sounds. A score for "sounds frustrated" is a prediction of what a listener would say, not a measurement of how the speaker feels. Accents, speech differences, disability and cultural norms can all shift the answer.
• Bias testing. Run your own audit across accents, languages and speaker groups before you use scores in any decision about a person.
• Security. Call audio holds personal data and sometimes card details or health information. Ask where audio is processed, how long it is retained and whether it is used for training. If you let AI agents act on these scores, put guardrails on the actions they can take. AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions.

How to get started

1. Join the waitlist from the launch post, and ask about pricing, latency and data retention up front.
2. Use the playground with 20 to 50 recordings you already understand. Write your questions as plain sentences with a small set of answers.
3. Have two or three people label the same clips. Compare the API's answers with their average, which mirrors Hume's own method, and with each individual.
4. Look at the cases where it disagrees, and decide where you need a human check.
5. Only then wire it into a workflow, with confidence thresholds and a path for appeals.

If you are new to the voice side of this stack, our report on the open speech model Audio8-TTS-Realistic-Air covers how open speech models compare, and Hume's own Expression APIs announcement from October 6 gives the earlier research background.

Bottom line

The idea is sound: ask a question of audio and get a calibrated answer, without building a pipeline per question. The evidence so far is one vendor number, 70.7% agreement with a human panel, and a waitlist. If you run a contact center or build voice agents, join the waitlist and test it on your own recordings. If you need to make decisions about people from these scores, wait for independent results and get legal advice first. We will update this post when Hume publishes an evaluation set, pricing or third-party tests.