[02.a] dataset and task
What each system is asked to do
- The dataset is 300 human-recorded English WAV segments (5.587 hours, 85 anonymized speakers) across 8 workplace workflow domains - support callbacks, deployments, order handling, and similar.
- Each item carries three transcript layers:
template (script with entity placeholders), acoustic (what the speaker says aloud), and canonical(the written value a downstream application needs). “double dash dry dash run” maps to --dry-run; “all caps database underscore URL” maps to DATABASE_URL. - 1,482 audited target entities span 26 structured types: emails, phone numbers, URLs, IP addresses, ports, shell commands, CLI flags, file paths, environment variables, code symbols, versions, reference IDs, amounts, dates, times, spelled sequences, and more.
- The system's only input is the audio file. Its transcript is stored verbatim with run metadata (endpoint, evaluation date, inference settings).
[02.b] metric definitions
What each metric means
CTEM · Canonical Token/Entity Match. Correct target entities ÷ target entities. An entity is correct only when the exact canonical value is recoverable - formatting differences are fine, wrong or missing characters are not.TSR · Task Success Rate. Recordings with all target entities correct ÷ recordings. The strictest headline metric: one corrupted digit fails the whole recording.WER · format-invariant Word Error Rate. Every target entity span accepts either the documented acoustic rendering or the canonical rendering as reference, so 212-555-0100and “two one two five five five zero one zero zero” score identically. Non-entity words use ordinary word-level edit distance.per-entity CTEM · CTEM restricted to one of the 26entity types - the full matrix above, useful for per-entity risk analysis (e.g. “can I trust this system with spoken email addresses?”).
[02.c] protocol
Raw audio only - no hints, no cleanup
Every system is evaluated under a raw-audio-only protocol: it receives the audio file and nothing else. Benchmark-specific prompts, target entity lists, domain labels, custom vocabulary, grammar constraints, candidate values, and post-ASR correction are all excluded from the main setting. This measures what the model does on its own, not what a tuned integration could extract from it.
Batch systems receive each recording as a complete file at the provider's documented input format. Streaming systems receive headerless PCM paced in realtime (100 ms chunks) over the provider's websocket protocol, with VAD, turn detection, and vendor canonicalization disabled where the API allows. Batch and streaming endpoints of the same vendor are tracked as separate systems because their error profiles differ substantially.
[02.d] entity verification
How entity matches are judged
For each recording, every target entity is checked against the system transcript by a versioned LLM verifier: openai_gpt_5_6_sol_group10_sync_v1 (gpt-5.6-sol, 10 benchmark datapoints grouped per request, reasoning effort medium). The verifier sees the transcript plus each entity's acoustic and canonical forms, and marks an entity present only when enough evidence exists to recover the exact canonical value. Casing, punctuation, spacing, and formatting differences are acceptable only when the same value remains recoverable; wrong, missing, extra, or substituted characters that change the value are rejected.
The verifier's prompt, response schema, grouping, and inference settings are frozen into a config digest that ships with every entity-match artifact, and the same verifier scores every system. For present entities it must cite an exact transcript substring as evidence; for absent ones it records the closest corrupted substring and a reason - so every one of the 25,194 entity decisions behind this page can be audited in seconds.
[02.e] reproducibility
Verify any number end-to-end
Everything behind this table is released in openbenchmarks-labs/voice-code-bench: the audio (data/audio/*.wav), transcripts and entity annotations (data/metadata.jsonl), per-system transcripts plus entity-match decisions (baselines/predictions/*.json), the versioned verifier configs, and the scoring CLI. The dataset itself is authored by Besimple AI and also published on Hugging Face as besimple-ai/voice-code-bench (MIT).
The release script rescores the published artifacts and rewrites baselines/results.csv - the exact table rendered on this page - without any provider credentials. Re-running a system live (vcb-transcribe → vcb-extract-entities → vcb-score-entities) requires only that provider's API key plus an OpenAI key for the verifier.