Is a 540x960 preview render cheaper? Not on Sume Timeline

No: the docs price minutes, not pixels

If you plan to render a small 540 by 960 proof of each Short before the real 1080 by 1920 export, expecting the proof to cost less, the published Sume pricing does not say that. The Timeline 1.0 page states the public rate as $0.10 per whole output minute, reserved as ceil(audio.duration_seconds / 60) minutes, and the pricing sentence has no width, height or fps term. A 58-second proof and a 58-second final are both one minute, so a proof is a second charge, not a discount.

We say it this way because a low-resolution preview is a habit from image and avatar tools where size drives cost. Here, what drives cost is the length you declare. That changes where to spend your checking effort: the unbilled plan, not a cheaper render.

What the plan gives you for free

POST /v1/timeline-1.0/plan runs the schema, the Sume-host URL checks and the same compiler the render uses. It returns object: timeline_plan with duration_seconds, segment_count, billable_minutes, estimated_cost_usd_micros and a filtergraph_summary. It creates no job, reserves no credits, downloads no media and does not need an Idempotency-Key. It will catch overlapping slots, a first slot that does not start at 0, transitions longer than their neighbors, and bad output sizes before you pay.

What it cannot catch is a short source that must be padded or looped, because the plan does not download media. That warning appears only on the real result. So a proof render is justified for one case: you want to see the pad or loop with your eyes before publishing, and you are willing to pay a minute to do it.

Cost of proofing every Short in a season

The figures below use the documented $0.10 rate and assume each episode is under 60 seconds. Check the live number in the catalog.

The one body, two calls

Keep a single request body and change only what you are testing. The shell sketch below plans at 540 by 960 to show the compiler accepts the body at a small size, then renders the real file at 1080 by 1920 with its own idempotency key. The output dimensions must be even integers between 256 and 2160, which both of these are.

# 1. Free plan at the small size: no job, no credits, no Idempotency-Key
curl -s -X POST https://api.sume.com/v1/timeline-1.0/plan \
  -H "Authorization: Bearer $SUME_API_KEY" -H "Content-Type: application/json" \
  -d '{"audio": {"url": "https://media.sume.com/artifacts/artf_demo/voice.wav",
                "duration_seconds": 58},
       "video": [{"source_url": "https://media.sume.com/artifacts/artf_demo/a.mp4",
                  "start": 0, "duration": 58}],
       "output": {"width": 540, "height": 960, "fps": 30}}'

# 2. The billed render: the same body at full size, with its own key
curl -s -X POST https://api.sume.com/v1/timeline-1.0/render \
  -H "Authorization: Bearer $SUME_API_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: ep05-final-001" \
  -d '{"audio": {"url": "https://media.sume.com/artifacts/artf_demo/voice.wav",
                "duration_seconds": 58},
       "video": [{"source_url": "https://media.sume.com/artifacts/artf_demo/a.mp4",
                  "start": 0, "duration": 58}],
       "output": {"width": 1080, "height": 1920, "fps": 30}}'

Where YouTube's own numbers come in

YouTube's upload help says Shorts can be up to 3 minutes long with a maximum resolution of 1080p, so 1080 by 1920 is already the ceiling for that platform. Rendering above it only adds file size; you can set output.width and output.height up to 2160 for other uses, but for Shorts the default 1080 by 1920 is the right target. The October platform roundup puts the new Shorts series feature, seasons, episodes and custom thumbnails, in rollout from 23 September, which is why season-sized budgets matter now.

When a smaller render is still worth it

Smaller output can matter for your own pipeline: a smaller file uploads and previews faster in your review tool. That is a workflow reason, not a Sume price reason, and the docs do not promise faster rendering at lower resolution, so we do not either. If your approval step needs a quick look, the cheaper path is a few stills: video inspect can pull up to 24 frames per call from a clip you already rendered, and Sume bills the probe and stills by their Modal compute, which is small next to a render.

A related trap is retrying. A proof and a final share a body apart from the size, so they must not share an idempotency key. The key identifies one operation and one payload; reusing it for a different body is refused as a conflict, and reusing it for the same body returns the original job instead of billing twice. That is the behavior you want for a retry after a dropped connection and the opposite of what you want for a deliberate second render. Give every intentional render its own key, such as an episode number plus a version suffix.

If you are budgeting a whole season, the order of operations is simple. Plan every episode first and read billable_minutes. Fix anything the plan refuses. Render once per episode. Then sample the finished files with a few stills. That sequence spends the minimum the documented rate allows, and it keeps the number you quoted to your team equal to the number you were billed.