ENGINEERING VERSION LOG · 2026.08

Why stop-time ASR did not grow linearly in the current sample

In a recent set of real records, recordings from 17.6 to 67.8 seconds needed roughly 0.42–0.47 seconds of final ASR after stop. The model did not decode the whole recording instantly. Stable speech had already been recognized while recording, leaving only the unstable tail when the user pressed Option again.

InkTyper Engineering2026.08.07

0.42–0.47sFinal ASR after stop in recent samples

17.6–67.8sReal recording lengths in this set

1.99–3.22sPost-stop AI editing in the same set

Tail-boundedRecording length no longer linearly sets ASR tail latency

ScopeControlled production observationA larger sample is still required

EvidenceFive real History recordsObserved results, targets, and estimates are kept separate.

StatusActive in the current pathThis log records a dated engineering state, not an evergreen promise.

01 · THE CHANGE

Stop no longer means “start recognizing now”

In toggle mode, the first Option press starts recording and the second stops it. The old path uploaded the complete file after stop and then waited for ASR, AI, and paste. The current session sends audio during recording. Pause-aware SenseVoice segments produce candidates, and stable prefixes are merged and retained before stop.

Record + upload→Segmented SenseVoice→Stable prefix→Finalize only the tail

02 · BOUNDED TAIL

Final ASR work is set by the tail, not the complete recording

Once earlier segments are recognized, stopping does not require decoding the full one-minute, three-minute, or longer recording again. Final ASR mainly closes the last mutable speech segment and joins it to the frozen prefix.

Under a healthy session this turns stop-time ASR into a bounded tail rather than a duration-linear wait.

03 · REAL RECORDS

Recent real records show ASR is no longer the main wait

17.6s recording: about 416ms final ASR and 2.26s AI.
22.8s recording: about 424ms final ASR and 2.42s AI.
29.2s recording: about 436ms final ASR and 1.99s AI.
58.6s recording: about 444ms final ASR and 3.22s AI.
67.8s recording: about 467ms final ASR and 2.19s AI.

04 · THE NEW BOTTLENECK

The bottleneck moved from ASR to final AI editing

Across this sample, post-stop AI represented roughly 82%–88% of combined ASR and AI time. Final ASR is near half a second, while correction, punctuation, formatting, and intent constraints still need roughly two seconds to just over three. The next optimization is to reuse rolling AI output and process only the unfrozen tail instead of editing the entire transcript again.

05 · WHAT THIS DOES NOT MEAN

Long recordings are not free

Network traffic, reconnect recovery, and deduplication still grow with time.
Stable-prefix merging must prevent omissions, repetition, and language flips.
Long-context AI cost and output length still increase.
Ten-to-twenty-minute meetings need a separate chunked job, speaker, and summary workflow.
These figures are a small set of real History records, not a complete p50/p95/p99 production promise.

06 · NEXT

AI needs the same bounded-tail property

Stable clauses should be edited and frozen during recording. At stop, only the unstable semantic tail and a short immutable context should reach AI. Reliable ASR must ship first when AI times out or fails. Once that is proven, total stop-time latency will become much less sensitive to recording length.

EVIDENCE · DIAGNOSIS

What the evidence establishes—and what it does not

This change addresses stop-time tail latency; it does not claim that long recordings are free. The evidence joins recording duration, final-ASR time, and AI time from the same client records instead of substituting an isolated GPU benchmark for the end-to-end path.

Reading ruleProduction observations describe the observed path. Controlled benchmarks isolate a component. Targets remain targets until a sustained distribution proves them.

OPERATIONS · OPEN WORK

Failure behavior and the next verification gate

Validation still needs multi-region networks, reconnect recovery, concurrent sessions, recordings beyond ten minutes, and p50/p95/p99 distributions. If a real-time session cannot finalize within its deadline, the client must explicitly fall back to complete batch transcription and record the fallback reason rather than silently dropping the stable prefix.

Failure visibility: Every fallback needs a reason code and stage timing. A successful final transcript must not erase evidence that real-time, AI, or paste failed first.
Release evidence: Keep request ID, actual model, node, queue, upload, ASR, AI, and delivery timing together so a regression can be reconstructed end to end.