OpenAI Batch 200 MB input file vs Sume's 4 MiB body: size your items
OpenAI's Batch API takes a 200 MB JSONL file. A Sume create body is capped at 4 MiB and input at 2 MiB, so media goes by URL and bulk items stay small.

OpenAI's Batch API accepts an input file up to 200 MB and 50,000 requests per batch. Sume has no file upload for a bulk run: the whole create body is capped at 4 MiB (413 payload_too_large), input at 2 MiB and 64 top-level keys, and a queue holds at most 100 items. Send big media as URLs, and keep each item's JSON small.
OpenAI's limits are from its Batch API guide; Sume's are from Calling a Format and Bulk runs.
What are the size limits on each side?
OpenAI's guide also says only a 24h completion window is currently supported, output files are deleted 30 days after the batch completes, and each request needs a unique custom_id because results can arrive out of order.
| Limit | OpenAI Batch API | Sume Format run or bulk run |
|---|---|---|
| Whole payload | 200 MB input file | 4 MiB request body (413 payload_too_large) |
| Requests or items | 50,000 per batch | 1 to 100 per queue |
| Per-item data | Part of the request line | input: 2 MiB and 64 top-level keys |
| How data arrives | Upload a JSONL file | One JSON body per create |
| Item identity | Unique custom_id | Position index, plus your own keys |
What does Sume do with files and media?
Send media by URL. The docs say 413 payload_too_large fires over 4 MiB and the fix is to shrink input and send media by URL. Media URLs inside input share the run's attachment budget with attachments[], and a URL that cannot be fetched fails the create with 502 attachment_fetch_failed even though it is your input: its next_action is fix_input. Make the URL publicly reachable.
Because a bulk item is the same body as a single run, a 100-item queue could carry up to 100 inputs, but the 4 MiB cap applies to the whole create request. Do the arithmetic before you build a queue: 100 items at 2 MiB each would not fit in one body.
How do I check size before I submit?
Measure the compact serialization, which is how the docs count input.
import json
LIMIT_BODY = 4 * 1024 * 1024
LIMIT_INPUT = 2 * 1024 * 1024
def check(items: list[dict]) -> None:
body = json.dumps({"concurrency": 4, "items": items},
separators=(",", ":")).encode()
if len(body) > LIMIT_BODY:
raise SystemExit(f"body {len(body)} bytes: split the queue")
for i, it in enumerate(items):
inp = json.dumps(it.get("input", {}), separators=(",", ":"))
if len(inp.encode()) > LIMIT_INPUT or len(it.get("input", {})) > 64:
raise SystemExit(f"item {i}: input too large or over 64 keys")
check([{"instruction": "clip 1", "input": {"url": "https://example.com/1.jpg"}}])
print("ok")What if my job is bigger than 100 items?
Split it into several queues, each with its own Idempotency-Key, as in the bulk-run sizing post for OpenAI's 50,000-request limit. Sume does not offer a JSONL upload path in the docs, a queue-level webhook or a way to cancel a whole queue, so build those around stored queue ids.
Sources
Related posts
More in Comparisons
- OpenAI 2,000 batches an hour vs Sume's write budget per minute
OpenAI's Batch API allows 2,000 batch creations per hour. Sume budgets requests per minute by plan: 120 writes on Free to 1,200 on Scale.
- OpenAI custom voices: consent phrase, 30 s sample, 20 voice cap
OpenAI custom voices need a recorded consent phrase, a sample of 30 seconds or less and sales enablement. What that means next to cloning a voice in Sume.
- OpenRouter Auto Router vs sume/auto: who picks the model?
openrouter/auto classifies a text task and picks a model at no extra fee. sume/auto picks a video family and never discloses which. Pricing, control and replay.
- OpenRouter :free limits (20 a minute, 50 a day) vs the Sume Free plan
OpenRouter :free variants allow 20 requests a minute and 50 a day under $10 purchased. Sume has no free-model tier, only a Free plan. Compared.
Written by Sume