fal Recast defaults to 1080p, Sume to 768p: check your resolution

If you omit resolution, fal Recast renders at 1080p and Sume's h3-max-recast renders at 768p. The two defaults are different tiers with different prices, so a script ported from one to the other changes cost and sharpness without any error. Set resolution explicitly in both places and the difference disappears.

fal's API schema lists resolution as an enum of 768P or 1080P with 1080P as the default (read 2026-10-03). Sume's Video Router docs list h3-max-recast at 768p and 1080p with 768p as the default (Video Router docs, read 2026-10-03).

The two schemas side by side

The request bodies are close cousins, which makes the port feel trivial and hides the differences. fal calls the source video_url and the photos reference_image_urls; Sume's Video Router uses the same two names. The differences are in the defaults and in what each side accepts around them.

What an omitted resolution costs

On a 10-second source the gap is easy to see. At fal's list, the default 1080P clip is $4.50 and an explicit 768P clip is $3.00. Through Sume, the default 768p clip is $3.75 and an explicit 1080p clip is $5.63. A script that relied on fal's default and is pointed at Sume with no changes will therefore produce a lower-resolution, cheaper clip than it used to, which is the safer failure but still a silent one. The reverse port, from Sume to fal, will quietly upgrade every clip to the dearer tier.

Nothing in either API warns you, because both are behaving correctly. The fix is a one-line habit: always send the field you care about.

Why the default matters more for Recast than for most models

Resolution is the only price lever inside a Recast call: reference photos are free and the duration is fixed by the source. That makes the default the single biggest silent cost decision in an integration. A team that ports a fal script and keeps its volume the same sees the bill fall by roughly a third on list price before the multiplier, because 768p is $0.30 per second against $0.45 at 1080p. A team going the other way sees it rise by half.

There is also a quality angle. A 768p draft is fine for checking whether the casting reads well and whether the replaced person tracks across the cuts. A 1080p final is what you ship. Treat the explicit field as part of your review workflow: drafts say 768p in code, finals say 1080p, and neither relies on a default that a vendor can change.

A port that stays explicit

The request below pins everything that differs. It also sends an Idempotency-Key, which fal's schema has no equivalent for, and leaves seed out because Sume rejects it.

curl -X POST https://api.sume.com/v1/video-router/generate \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: recast-port-001" \
  -d '{
    "model": "h3-max-recast",
    "video_url": "https://example.com/source.mp4",
    "reference_image_urls": ["https://example.com/person-1.jpg"],
    "resolution": "1080p",
    "mode": "async"
  }'

Porting checklist

Before you switch an existing fal Recast integration, run through these items in order. They take minutes and each one maps to a documented difference.

• Search your code for any call that omits resolution; add it explicitly.
• Lowercase the resolution strings to match Sume's docs.
• Delete any seed argument; Sume's v1 video models do not accept it, so rerun the clip for another take instead.
• Add an Idempotency-Key to every submit.
• Swap fal's queue polling for Sume's GET /v1/jobs/{id}/status and /result, described in the Jobs and results guide.
• Re-quote your batch: the Sume price is the fal list times 1.25.