Speed up a Reel? Sume has no speed field, so shorten the cut

Short answer: Sume does not retime a clip

If you are searching for a way to speed a finished Reel up to 1.25x or 2x through an API, Sume does not ship that. None of the three surfaces that touch an existing clip documents a speed or tempo field: video trim cuts a range, video filter applies a dim or crop, and Timeline 1.0 assembles clips against an audio spine. We are not going to tell you a workaround exists when the docs say otherwise.

What you usually want when you ask for speed is a shorter clip that still lands its point. That is something Sume does ship, in three ways: cut the range you keep, tighten the length of what you generate, or drop slots from the timeline. The rest of this page is how each one works and where the limits are.

Why the filter surface will not do it for you

It is reasonable to guess that the video filter's free-form graph can change speed. The docs close that door on purpose. The graph is a filters-only allowlist, and the docs name what is not on it: trim and setpts are excluded (use video trim), as are drawtext, subtitles, movie, lut3d and any filter that reads a file or a socket.

Sume also refuses raw encoder control. A request that carries vf, filter, ffmpeg, cmd, codec or crf fields returns ffmpeg_fields_rejected. The server compiles ffmpeg itself, so there is no side door. A request with an unknown filter name returns invalid_filtergraph with the allowlist, which is a quick way to confirm this against your own account without paying for anything: the unbilled POST /v1/video-filter/check returns diagnostics instead of creating a job.

What to do instead, by goal

Pick the row that matches why you wanted the speed-up. Every figure in the table is a documented limit or default, not a measurement.

Hit a length target with trim

Trim takes start plus exactly one of end or duration. If end is past the source it clamps and the result carries the warning trim_clamped_to_source. The default precision is exact, a frame-accurate re-encode; keyframe is a stream copy that can start up to a GOP early, so read actual_start_seconds back and re-base your times against it. The clip must already live on media.sume.com, so import it first. Public rate is $0.02 per job, and the live number is always in GET /v1/catalog.

The call below keeps seconds 4 to 34 of an imported clip, a 30-second cut from a longer take.

curl -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: reel-cut-001" \
  -d '{"video_url": "https://media.sume.com/artifacts/artf_demo/take.mp4",
       "start": 4, "duration": 30, "precision": "exact"}'

Cut, then plan, then render

For a multi-clip Reel, trim each piece, then send the trimmed files as video[] slots with source_in 0. Run the same body through POST /v1/timeline-1.0/plan first. It is unbilled, creates no job, and returns duration_seconds, segment_count and billable_minutes, so you know the length before you pay for the render. Remember the render price is $0.10 per whole output minute, which is why a 61-second Short costs two minutes; see how Shorts length bills.

For the platform side, YouTube's own page says Shorts creation tools make videos up to 3 minutes long and that uploads top out at 1080p. Instagram and TikTok length rules change often and we did not get a readable vendor page for them this week, so check those in the apps before you lock a length.

What we are not claiming

We are not claiming Sume speeds video up, ramps speed, or retimes audio. If speed is the real requirement, do it in the editing tool where you finish the Reel, then bring the result back to Sume for captions, trims and a timeline render. The pieces Sume does ship are documented, priced and testable before you spend: a free filter check, a free timeline plan, and a $0.02 trim.