[richiemcilroy]

A short transcript now completes in one workflow step instead of five, which should take about 3 seconds off every transcript up to 30 minutes long, from about 5.1 s to about 2.0 s for a short file. Billing, holds, limits and failure codes are unchanged.

#4134 (captions), #4143 (transcript abuse fixes) and #4150 (URL sources refused from their first bytes) have landed and main is merged in, so the diff is only this change: the workflow, one helper in lib/developer-transcript-run.ts and tests. The URL check from #4150 sits in the shared prepare body, so the fast step and the prepare step both run it.

Why it was slow

On production, a short transcript does about 1.4 s of work, spread over six steps. Each step waits about 0.6 s to be scheduled and queued, so most of the time to complete is overhead.

Production medians from 22 runs:

Step	Wait before it	Queue	Work
claim	363 ms	179 ms	86 ms
prepare	618 ms	181 ms	152 ms
extract	591 ms	166 ms	565 ms
transcribe	605 ms	168 ms	392 ms
settle	581 ms	174 ms	162 ms
cleanup, after complete	576 ms	172 ms	118 ms

The shape

One new step, runTranscriptFastPath, runs claim, prepare, extract, transcribe and settle back to back in one function. It passes the extracted audio straight to transcription instead of reading it back from storage. Cleanup and the caption write stay separate steps after complete is written.

The fast step stops and reports where it stopped whenever the normal path would do something other than move on:

• the hold has to wait for other transcripts, or the credit is short
• the audio is longer than the hold covers, so the hold has to be raised
• any stage fails or throws
• the audio is longer than 30 minutes, or the step has already spent 2 minutes, before extraction or before transcription

The workflow then carries on from that stage with the existing steps, unchanged: the same sleeps and waits, the same raises, the same retries and the same failure handling. A transcript that needs none of this completes in the one step.

I chose this over starting the work from the create request with after(), the way videos do:

• The overhead is per step. Folding five steps into one removes four waits and four queue delays, about 3.1 s.
• after() would save only the first wait, about 0.5 s more. In exchange it would run downloads and speech calls in the API request's function, outside the runId fencing, with the workflow as a watchdog that could run the same work again.
• Every stage folded in here was already safe to run again. Claim is fenced by runId, the hold is a no-op once held, extraction returns early when the audio exists, transcription reuses a stored result, and settle reports already settled. So if the runtime retries the whole fast step, nothing is charged, transcribed or written twice.

Step time limit

Workflow steps are deployed with the plan's maximum duration, 800 s on this plan.

• Inside the fast step, transcription only runs for audio up to 30 minutes, and only if the step has spent less than 2 minutes. On production a 30 minute file spends 4.2 s in extract.
• Extraction only runs in the fast step if getting the file took less than 2 minutes.
• So beyond what getting the file costs today, the fast step adds at most a couple of minutes of work. Longer files keep their transcription in its own step, as now.

Skipping extraction for audio the speech service accepts: not done

The speech service accepts most audio and video containers, but it reports the length it transcribed only after the work is done. So its duration cannot be what the hold is checked against before we pay for the call.

Today the hold is safe because of extraction itself. It re-encodes the audio at a fixed bitrate and caps it at what the hold covers, so what the speech service receives is bounded and measured by us.

Skipping it would mean trusting our reading of the original file. Local tests show that reading can be far from what a decoder plays:

File	Our MP3 frame count	Container header	Full decode	After extraction
MP3 with random bytes spliced between frames	60.11 s	60.30 s	60.08 s	not needed
MP3 followed by layer II frames	10.03 s	70.03 s	130.01 s	130.01 s

The second file would be held and charged for 10 seconds while the speech service transcribes 130. The best case saving was about 0.4 s of extract time on MP3 sources only, so the step stays.

Measured

In-process, on the scratch database, the local object store, local ffmpeg and a local stand-in for the speech service, with no step overhead, the work is the same in both versions. Median of 8 runs, 4 for 30 minutes:

Clip	Before	After
13 s	152 ms	138 ms
1 min	195 ms	182 ms
5 min	457 ms	447 ms
30 min	2,065 ms	2,050 ms

The small saving is the audio no longer being read back from storage. The win is the step overhead. Modelled with the production medians above, start to complete:

Length	Steps before complete	Modelled before	Modelled after
up to 30 min	5 to 1	5.1 s	2.0 s
over 30 min	5 to 3	measured 40.6 to 61.0 s for 2 h	about 1.6 s less

Applied to the production runs: 10 s files 3.5 to 5.3 s would become about 1.5 to 2.2 s, and 30 minutes 9.6 and 14.9 s about 6.5 and 11.8 s. The production matrix should be run again after merge.

Proof

What	Result
Fast path tests (new file, cannot load on the code before this change)	18 pass
Workflow, holds, no speech, download, video and settle tests through the new path, unchanged apart from two delete tests	all pass
Developer, infra and agent unit suites	2,251 pass
Real MySQL scratch database: transcripts suite and holds suite (the holds suite runs the workflow end to end)	46 of 46
Workflow bundle build	builds, runTranscriptFastPath is registered, and the transcribe module in the flow bundle has no database code
Typecheck and Biome	clean, apart from one known unrelated typecheck error

The fast path tests cover:

• A short file completes in one call of the fast step: claimed, held, extracted, transcribed and charged once, with no audio read back from storage.
• The whole workflow does nothing twice after the fast step: one speech call, one extraction, one write of the audio and of the result, one ledger row.
• Running the fast step again after it finished, or after its settle failed, does not transcribe, write or charge twice.
• A hold wait, a hold raise, audio over 30 minutes, and each 2 minute budget hand over at the right stage. The rest of the workflow finishes with the same charge.
• Failure codes and messages are unchanged for an unusable file and for a speech service that keeps failing.

The existing tests still show:

• The hold waits keep their exact sleep sequence.
• A delete during the speech call is still charged, and a delete before it is free.
• A video transcript still writes its captions.

Two delete tests changed. One triggered its delete on the audio read-back, which no longer happens, so it now triggers on the last storage call before the speech service. The other expected the workflow to throw when the speech call failed after a delete. Its transcription is now handed to the transcription step, which sees the delete and ends the transcript with nothing charged. That is what production already does once the runtime retries the step.

Not covered

• The real workflow runtime was not run, because that needs a dev server or a full build. Step boundaries are shown by calling the fast step directly and by the built manifest, and the overhead is modelled from production rather than measured.
• When a stage throws inside the fast step, the separate step tries it again with its own retries. So a speech service that keeps failing is called once more than before before the transcript fails.
• The 30 minute and 2 minute limits are conservative. Raising them would save about 1.6 s more on long files.
• Getting a file from a URL can take up to 15 minutes, which is longer than a step may run. That was already true of the prepare step before this change.

After review

• If the worker stopped after the fast step's settle was saved but before the step's own result was recorded, the step ran again, found the transcript no longer claimable and the workflow ended without cleanup or the caption write. A run that already finished its transcript now goes straight to cleanup and captions. A transcript its own settle ended for lack of credit is cleaned up as not completed, and one owned by another run is still left alone. A repeat delivery of the same run therefore reports completed and repeats only the cleanup, with no second charge or speech call.

• Two review threads asked for hosted player captions. Those belong to the playback work, not this PR, which only carries the captions diff of feat(infra): transcribe a stored video by id and write its captions #4134. The player claim in the docs has been reworded on feat(infra): transcribe a stored video by id and write its captions #4134 to what ships today.

• Whole web suite: 8,197 pass. The only failures are two files that fail on this machine and pass in CI. Real MySQL: 46 of 46.

• Merged main after feat(infra): transcribe a stored video by id and write its captions #4134, fix(infra): bind upload tokens to their key, cap part numbers, sniff past ID3 tags #4138, perf(web): cut Cap Infra billing reads on the console, usage API, ledger and storage cron #4142, fix(infra): charge transcripts deleted during speech and cap running transcripts per app #4143 and fix(infra): refuse a URL transcript source that is not media from its first bytes #4150 landed. Only the docs test conflicted; main's version is kept. Developer, infra and agent unit suites 2,555 pass, fast path tests 18 of 18, real MySQL 46 of 46. The workflow bundle builds, runTranscriptFastPath is registered and the transcribe module in the flow bundle has no database code.

• A retry of the whole fast step now resumes from what the earlier attempt saved, as the separate steps did. If the audio was already measured and saved, it skips the source-size hold and goes to transcription, so a retry never asks for more credit than extraction left held. A row this run owns that was deleted while processing is settled from its saved result (charged once, hold released) or, with no result, ended free. Only a row this run never claimed is left alone.

• So that a saved result survives until that retry, deleting a transcript that is still processing leaves its files to its run, which removes them when it ends. The 6 hour expiry removes them if the run never returns. Queued, uploading, complete and failed transcripts lose their files at once as before.

• Developer, infra and agent unit suites 2,561 pass, real MySQL 46 of 46, workflow bundle builds. The five new tests fail on 713b72f.

Confidence Score: 5/5

The PR appears safe to merge; no new actionable issue was established.

Summary

Short transcripts now claim, prepare, extract, transcribe, and settle in one workflow step. Longer work and interrupted stages continue through the existing separate steps.

• Short developer transcripts finish their main work in one workflow step.
• Deleting a transcript keeps its files available while its run is processing.

_{Reviews (7) · Last reviewed commit: "Merge branch 'main' into perf/infra-tran..." · Reviewed by Greptile}

[capy-ai]

Capy found 2 potential issues (2 medium).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
cap-status	Skipped		Nov 13, 2026 6:03am UTC

[capy-ai]

Capy found no issues.

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

View 1 other finding in Capy.

[sandchest-com]

Sandchest reviewed 0d9ea0e: nothing exploitable found in this change.

_{Sandchest reviews every change for vulnerabilities an attacker could use · 12 credits · Review details}

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

[capy-ai]

Capy found no issues.

[capy-ai]

Capy found no issues.

[capy-ai]

Capy found no issues.