Keyframe or exact video trim for pause cuts: read actual_start_seconds

Use exact for a cut inside speech and keyframe for a cut you can afford to be loose about. Sume video-trim takes a precision field. Exact is the default and cuts at the instant you give. Keyframe is a stream copy that can start a GOP early, and the job reports actual_start_seconds so you can see where it really began (Sume docs: Video trim, read 2026-10-06).

When the cut point is the end of a pause, a few hundred milliseconds decides whether the cut starts on the first word or carries a trace of what came before.

Where keyframe goes wrong

Keyframe precision is a stream copy, and the docs say the cut can start a GOP early. So the reported start lands at or before the start you sent, never after it. That means a keyframe cut does not clip the first word; the risk runs the other way: it can pull in the tail of the previous sentence or a stretch of pause you meant to remove. On a pause cut, that shows up as a leftover breath or half a word from the speaker before.

The report is the check: compare actual_start_seconds with the start you sent. The docs tell you to re-base your times against that field, which matters if you cut a second piece out of the same output, because every later timestamp moves by the difference. If the gap is larger than the lead-in you can tolerate, rerun the cut with exact.

A check you can run

The helper below takes the requested start and the reported start and says whether the keyframe cut kept more lead-in than you can tolerate. The tolerance is yours; 0.15 seconds is a starting point, not a Sume number.

def keyframe_ok(requested, actual, tolerance=0.15):
    lead = requested - actual
    if lead < 0:
        return False, "starts %.2fs late, unexpected for keyframe" % -lead
    if lead > tolerance:
        return False, "starts %.2fs early, extra lead-in kept" % lead
    return True, "within tolerance"

for req, act in [(12.40, 12.40), (12.40, 11.20), (12.40, 12.30)]:
    ok, why = keyframe_ok(req, act)
    print(req, act, ok, why)

Which to choose

If you are producing many pause cuts, exact is the default for a reason: the cost is the same flat $0.02 per job, and exactness avoids the retry, and only exact can also conform output (width and height 256 to 2160, fps 24, 25, 30 or 60), so a cut that also needs resizing must be exact. Use keyframe when you are trimming a rough section, such as removing a dead opening of several seconds, where a half-second of slack is fine.

Audio is separate. The audio field keeps or drops the track, and keeping it is what you want for a speech cut.

Listen before you scale

Cut three clips both ways and listen to the first word of each. The difference is easiest to hear on a word that begins with a plosive. Ten minutes of listening will settle the choice for your footage better than any rule.

Batch behavior

When you cut many pauses from one clip, each cut is its own job at $0.02. Ten pauses is twenty cents, and the price is the same for keyframe and exact, so the saving from keyframe is speed alone. Spend the care on precision where speech is involved.

Give every cut its own Idempotency-Key built from the clip id and the start and end times, so a retried batch replays the finished cuts and only does the missing ones.