Hume ships Audio Decision API: one-call audio judgments, pitched as re

@hume_ai posted at 2026-11-02 16:00 UTC (2026-11-03 00:00 Beijing): the Hume Audio Decision API is live—questions like “How many speakers?”, “Is anyone laughing?”, “Is the caller frustrated?” collapse into one call that returns thresholdable probabilities, not a transcript or a prose explanation. The announce sat around 310 likes / 298 bookmarks and ~125k impressions on drop; the technical blog is dated November 2, 2026, and the same calendar day shipped the product page, developer docs, and Python package hume-audio-decisions 0.1.0 (PyPI upload 2026-11-02 14:13 UTC).

Two misreads to kill early. First, this is not a rebadged emotion classifier or another Expression API surface—the docs are blunt: the model takes raw audio plus plain-language questions and returns structured probabilities; no transcript, no reply, no explanation. Your code does the reasoning. Second, do not conflate it with the micro-engagement indie “audio decision” posts that floated in the same window: this piece tracks Hume’s official product line—Decision Model API on the marketing page, Audio Decisions in the docs/SDK, Hume Audio Decision API on the X announce.

The architecture line is the marketing knife: “What used to take 10+ models is now one call.” The product page’s before/after is the same claim in UI form—LID / speaker / affect / noise orchestration versus one Audio Decision Model answering in context. Official training stats: 10M+ human judgments across Hume’s work, and a 1B hours client-processing figure on the product page. The sharper number is panel alignment: Hume says the model agrees with a human panel’s average judgment 70.7% of the time, against a 56.5% individual-rater baseline—closer to “how a crowd hears it” than “how one labeler hears it.”

The benchmark card is checkable on their page. Official claim: average 0.82 across 10 leading benchmarks (MMAU, ParaPair, EmphAssess, and peers named in copy), 0.23s median latency per screen, with the same table listing Gemini 3.8 Flash at 78%, Qwen3.8-Omni-Flash at 76%, Inkling-Small at 67%; the accuracy-vs-speed scatter also marks gpt-audio-1.5, Gemini 3.5 Flash Lite, and Nemotron 3 Nano Omni. Read those as vendor-reported.

For people who will actually call it. Canonical path: POST https://api.cloud.hume.ai/v0/decisions/file, header X-Hume-Api-Key, multipart/form-data with request (JSON: optional context + questions) then file (MP3 or WAV). Four mixable primitives:

noul: is something true → probability of yes
choice: which option → per-option probabilities + most likely
score: ordered scale → per-level probabilities + probability-weighted mean
span: when an event occurs → time intervals

Hard limits from the Limits page: audio 5 seconds to 5 minutes, combined payload ≤25MB, up to 20 noul/choice/score plus 5 span (≤25 questions total), context ≤1,000 characters, 60 requests/minute per organization. Longer than five minutes means split and send one request per part; the SDKs ship helpers for that. “Realtime” is not a separate named WebSocket product in the docs—it is the “Answering live audio” cookbook: poll ≥5-second windows. One window every five seconds is ~12 rpm; five parallel streams saturate the org limit.

Billing is not the old TTS/EVI subscription model: you pay received.input_tokens (audio duration dominates; questions and context add a little; answers are free), with POST /v0/decisions/file/input_tokens to estimate first. Doc examples: ~1k tokens for a 10s TTS naturalness check; ~26.4k for a 5-minute support call with six questions; ~6.4k per minute to watch a live call. Dollar rates are not in the public docs—they live on the Platform Plan page; missing payment method yields 402 payment_required. The marketing page also shows an api.hume.ai curl; treat api.cloud.hume.ai as the documented implementation host.

How to read the numbers is harsher than the launch thread: a noul near 0.5 is not “the model is unsure”—it means human raters would split on that clip. You set thresholds; the API does not hand you a black-box confidence story. The blog’s three landings are concrete: score TTS/voice-model naturalness and brief-fit; give a cascaded voice agent a perceptual decision layer beside the transcript (wait / clarify / escalate); and turn “find every call that sounds frustrated” into bulk search without a bespoke classifier farm.

For people who live in voice-agent stacks, the signal is not “another emotion score.” It is shipping a decision model—many structured questions in parallel, probabilities aligned to human listening—as a callable side-car next to STT+LLM+TTS. The blog still says “join the waitlist” for access, while the docs, OpenAPI, Python/TS SDKs, and playground copy are already public; whether your org can bill a run is a Platform permission question. To pressure-test the “10+ models → one call” line: drop a support recording, pack speaker count, talk-over, caller frustration, and noise intrusiveness into one request, and see whether the probabilities are crisp enough to drive your own business rules.