Is a 4:5 render cheaper than 9:16 in Timeline? Same $0.10 a minute

No. A 1080x1350 (4:5) Timeline render costs the same as a 1080x1920 (9:16) render: $0.10 per output minute, rounded up to the next whole minute. The docs price by output length, and the reserve is ceil(audio.duration_seconds / 60) minutes, so width and height do not enter the price. A 50-second ad is one billable minute at either size, and a 61-second one is two.

What does change with the ratio is the crop of your footage and, roughly, the size of the finished file. This post covers the arithmetic and a way to confirm the price with the plan endpoint.

How the price is built

Timeline's price page entry reads $0.10 per output minute. The meter is ceil(duration): 1 to 60 seconds is one minute, 61 to 120 is two, and so on. The audio spine may run from 1 to 1,800 seconds, so the largest single render is 30 minutes, or $3.00.

Output size is bounded separately: output.width and output.height must be even integers from 256 to 2160. Any pair in that range is priced the same way.

What 4:5 does to the picture

A 4:5 frame is wider than 9:16: at 1080 pixels across it is 1350 tall instead of 1920. A clip shot at 9:16 and fitted with cover into 4:5 loses 570 rows of height, which is 29.7% of the frame. A 16:9 clip into 4:5 loses most of its width instead. With contain nothing is cropped but bars appear, and blur fills those with a blurred copy of the clip.

The Google Ads video page, read for another post, states that ratios between 16:9, 9:16 and 1:1 are accepted, and 4:5 sits in that range. Nothing on that page makes 4:5 cheaper for you; the price here comes only from Sume's meter.

File size, not price

You cannot set a bitrate in Timeline, since the server refuses codec and crf keys. At a given quality, fewer pixels generally mean a smaller file. The pixel counts are 1080 x 1920 = 2,073,600 and 1080 x 1350 = 1,458,000, so a 4:5 frame has about 70% as many pixels (1,458,000 / 2,073,600 = 0.703). Use that as a rough guide; the actual size depends on the content.

YouTube's upload page recommends 8 Mbps video for 1080p at standard frame rates. That is a guideline for uploads there, not a limit, and it is not a figure Sume applies.

Confirming with the plan call

Send the same body to /v1/timeline-1.0/plan with each size. The response includes billable_minutes and estimated_cost_usd_micros; for a 50-second spine both calls should show 1 and 100000. The plan call needs no idempotency key and creates no job, so you can run it as often as you like.

If the numbers ever differ between sizes, treat that as a reason to read the response and your request again, because the docs give no price dependence on pixels.

for size in '1080,1920' '1080,1350'; do
  w=${size%,*}; h=${size#*,}
  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\": 50},
      \"video\": [{\"source_url\": \"https://media.sume.com/artifacts/artf_demo/scene.mp4\", \"start\": 0, \"duration\": 50}],
      \"output\": {\"width\": $w, \"height\": $h}
    }"
  echo
done

A worked example

Take a 52-second spoken ad delivered at 9:16 and 4:5. Both requests set audio.duration_seconds to 52, so each reserves ceil(52 / 60) = 1 minute and costs $0.10. Ten such ads in both ratios is 20 renders, 20 x $0.10 = $2.00. If a revision pushes the script to 64 seconds, every render moves to two minutes, so the same twenty renders cost 20 x $0.20 = $4.00. The length crosses the 60-second line; the size never does.

The reserve and the final bill use the same rounding on the output minutes, so a plan result is a reliable estimate of the charge. Read the live rate in the catalog endpoint before you budget a large batch, since the docs tell you to confirm it there.