Media import allows about 2 GB, but trim and filter stop at 300 MiB

Two limits in Sume's media path do not match, and the gap catches people. The OpenAPI description of POST /v1/media-imports gives a practical size cap of about 2 GB. But the media tools that read the stored file, such as video trim and video filter, refuse a source larger than the timeline download budget with source_too_large. In the worker, DEFAULT_MAX_DOWNLOAD_BYTES is 300 MiB.

Both are read from the clone on 2026-10-05. The API returns the check early: a HEAD request reads Content-Length, and a larger file fails with 400, next_action: use_smaller_source, plus the content_length and max_bytes it compared.

What the import takes in

Media import fetches a public TikTok or Instagram video URL, mirrors the bytes into media.sume.com, and records a workspace asset. A fixed estimate of $0.15 applies to each accepted import. YouTube is rejected with unsupported_platform. The result includes size_bytes, so you can read the size right after import.

Plan around the gap

• Read size_bytes from the import result. If it is over 314,572,800 (300 MiB), do not send it to trim or filter.
• Re-export a smaller file at a lower bitrate in your editor, then bring that file into Sume.
• Remember the duration caps too: trim and detach accept sources up to 1800 seconds, and filter up to 300.

A guard

A tiny pre-check keeps a pipeline from creating failing jobs.

LIMIT = 300 * 1024 * 1024

def can_process(size_bytes):
    return size_bytes is not None and size_bytes <= LIMIT

print(can_process(250 * 1024 * 1024))
print(can_process(900 * 1024 * 1024))