Past the cap the system may truncate, chunk, or refuse

What it is

Once audio hits a duration or token cap, three dispositions are common: truncate (recognize only the prefix, drop the rest), chunk (cut into several requests and stitch), or refuse (the whole turn fails, no usable text). The three look completely different to people and often end on the same spinner. Going over the cap is not one error; it is a protocol choice.

Why it happens

Truncation is cheapest: the timer seals, like a forced endpoint, and the tail lives in no buffer. Chunking slices a long stream into windows, decodes each, and concatenates at text level, which can keep content and invent its own errors at window edges. Refusal protects the service and pushes responsibility back; in dictation it hurts most: two minutes of speech for a failure. Different layers inside a product may each pick one—on-device truncate, cloud refuse—and the user sees randomness. Compared with premature endpoint cutoff, this cut is triggered by capacity, even if the user never stops and acoustics contain no silence.

Studying it

Send over-cap audio, classify actual behaviour, and ask what people thought happened. Measure WER of stitched chunks against an offline whole-clip decode. Log whether an error code or prompt appeared. Make the three dispositions experimental conditions and compare task completion. Do not assume “supports long audio” in a doc means no chunking.

Where it stops holding

Live captions must chunk; refusal is not an option. If a command exceeds the cap, refuse is safer than truncate, so a half sentence is not executed. Forensic recordings have a duty to keep the whole file; a recognition cap is not a deletion excuse. A user-initiated stop is voluntary truncation, not the over-cap protocol.

Applying it

• Pick one disposition and say it in the UI: truncation must mark “only the first N seconds were recognized,” chunking must let people see the seams, refusal must offer a shorter retry.
• Prefer refuse (or confirm a half sentence) on the command path; prefer chunking on dictation.
• Accept over-cap samples; forbid “success that silently lacks the second half.”

Related

• Same group: C7.15.1 A single recognition request usually has a duration or token cap · C7.15.3 Chunking long speech can cut a semantically complete sentence at a boundary · C7.15.4 Length caps directly constrain dictation usefulness
• Adjacent: C7.02 Endpoint Detection · C7.10 Live Partial Results
• Search: truncation · chunked ASR · request rejection