Edits beat markers: cut to the beat with Sume Timeline start times

Edits has beat markers that "auto-detect where the beats land in your audio" (Instagram creators, read 2026-10-03). Sume documents no beat detection, so it cannot tell you where a beat falls in an arbitrary track. If you know the tempo, though, cut points are arithmetic: at 120 BPM a beat is 0.5 seconds, and Timeline 1.0 lets you declare each video[].start on the spine. That makes cut-to-the-beat a calculation you do before you render, not a feature you wait for.

Get a tempo you can trust

The Music Router takes a text prompt with no duration or seed field and steers length and structure in the words, for example a 30-second track at a stated BPM. The docs say a tempo in the prompt is a creative direction, not a guaranteed output setting, so verify the result by ear or with your own tooling before locking cut times. For a licensed track you already own, use its published BPM and a quick check of the first downbeat.

Build the slots

Timeline needs video[0].start to be 0, later starts to increase, and each slot's duration to be at least 0.2 seconds. Coverage may trail the spine by at most 0.5 seconds. Cutting every two beats at 120 BPM gives a 1.0 second slot; the script below builds slots across a 12-second spine, cycles through your clips, and asks the unbilled plan endpoint to compile it first.

import json, os, urllib.request

API = "https://api.sume.com/v1"

def post(path, body, key):
    req = urllib.request.Request(
        f"{API}{path}",
        data=json.dumps(body).encode(),
        headers={
            "Authorization": f"Bearer {os.environ['SUME_API_KEY']}",
            "Content-Type": "application/json",
            "Idempotency-Key": key,
        },
        method="POST",
    )
    with urllib.request.urlopen(req) as res:
        return json.load(res)

BPM = 120
BEATS_PER_CUT = 2
SPINE_SECONDS = 12
clips = os.environ["SUME_CLIP_URLS"].split(",")

step = 60 / BPM * BEATS_PER_CUT
count = int(SPINE_SECONDS / step)
video = [
    {
        "source_url": clips[i % len(clips)],
        "start": round(i * step, 3),
        "duration": step,
    }
    for i in range(count)
]
plan = post(
    "/timeline-1.0/plan",
    {
        "audio": {"url": os.environ["SUME_SPINE_URL"], "duration_seconds": SPINE_SECONDS},
        "video": video,
    },
    "beat-plan-001",
)
print(count, plan["segment_count"], plan["estimated_cost_usd_micros"])

Limits worth planning around

A render with more than 12 slots chunks automatically on render.strategy: auto, and single is refused above 12. Starts are authoritative, so Sume compensates for transitions rather than shifting your cuts. Hard cuts avoid the question entirely; transitions on a beat-synced edit are capped at 1 second and half the shorter neighbour, and more than 8 adjacent fades is refused (too_many_chained_transitions).

The table shows how tempo maps to slot lengths in a 12-second spine.

When to just use Edits

If you have a finished track with no known tempo and you want markers you can nudge by hand, the Edits beat detection is the right tool. If you are assembling many clips on a schedule to a track whose tempo you control, the arithmetic route is repeatable and costs $0.10 per ceiling output minute for the render.

Checking your cuts landed

After rendering, extract a few stills at the planned cut times with video frames, which takes an at list of up to 24 timestamps and returns durable images at source size. Compare the stills just after each cut time with the clip you expected, and you have a cheap visual check that the arithmetic matched the render. A frame_time_out_of_range error names the probed duration if you ask past the end.

Drift is the usual failure on long spines. A tempo that is really 119.8 BPM will slip a frame every few bars, so for anything past a few seconds recompute the grid from the actual track rather than trusting a rounded number. For short Reels, a 12 to 30 second spine is short enough that rounding rarely shows.

Why not auto-detect

If you only need markers, Edits already has them. The reason to script the cut grid is repeatability: the same BPM and clips give the same edit every time, which suits batch work and testing, while detection is better for one-off hand edits.