Video inspect transcript for an 8-minute clip: $0.08 plus compute

Setting transcribe: true on video inspect adds Sume STT at $0.01 per audio minute. An 8-minute clip is 8 x $0.01 = $0.08, on top of the probe and stills, which Sume bills by Modal compute. Send duration_seconds: 480 so the reserve matches the clip.

What the hold looks like

Without duration_seconds Sume reserves 1 minute for the transcript. The hint maximum is 600 seconds. The capture never exceeds the hold, per the docs read 2026-10-09.

Request

language_code is an STT hint such as en or ko. segmentation.mode: "sentence" also returns sentence segments without gaps, with an optional silence_split_seconds from 0.2 to 3. These fields without transcribe: true return 400 video_inspect_transcribe_required.

curl -X POST https://api.sume.com/v1/video-inspect \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: inspect-stt-001" \
  -d '{"video_url":"https://media.sume.com/artifacts/artf_demo/talk.mp4","frames":false,"transcribe":true,"duration_seconds":480,"language_code":"en","segmentation":{"mode":"sentence"}}'

Longer than 10 minutes

The inspect source limit is 1,800 s, but the hint caps at 600. For a 25-minute recording, detach the audio in ranges with audio detach (each range up to 900 s) and transcribe those files with the STT endpoint, or run inspect and check the live reserve in the catalog.

Silent clips

A clip with no audio track returns inspect_source_has_no_audio. Run a frames: false inspect first and read probe.has_audio. Inspect returns facts, stills and text. For semantic questions about what happens in the video, the docs point to separate tools that are not on every environment.

Budget

For 100 clips of 8 minutes the STT part is 100 x $0.08 = $8.00, plus compute for each inspect. If you only need the transcript, send frames: false so the job does not spend time on stills. Keep transcripts for later queries; the result includes text, words[] and optional sentence segments[]. Every media job follows the same lifecycle: submit with an Idempotency-Key, receive a job, poll GET /v1/jobs/:id/status until it is ready, then read GET /v1/jobs/:id/result. A retry with the same key does not queue a second job, so a network error during submit never doubles a charge.