A 3-second Omni 360p clip costs 12 cents on Sume, not 11

A 3-second Gemini Omni Flash 1.1 clip at 360p bills $0.12 on Sume. The provider list price is $0.03 per second, so 3 seconds is $0.09; Sume bills list times 1.25, which is $0.1125, and rounds each job up to the next cent, so $0.12 (Video Router doc, read 2026-10-06). If your estimate sheet says 11 cents, it rounds to nearest and under-reports every short clip.

This matters now because the OpenAI Sora API ended on 2026-09-24, and short stingers, bumpers and loop tiles are the clips teams re-render first. Three seconds is Omni's minimum duration, so these are the smallest jobs you can submit to it.

The rule in the docs

The Video Router billing section says the billable amount is list times 1.25, ceiled to cents, on each row. The per-row billable_formula in the catalog is the truth for any given model. At submit Sume reserves the billable amount, and the finished job's usage.cost shows what it captured (Sume video docs, read 2026-10-06).

Rounding per job, not per second, is why short clips look expensive relative to the per-second rate: the maximum rounding error is under one cent, which is large next to a $0.09 clip and negligible next to a $3.75 one.

Three seconds at every Omni tier

What this changes for a batch

A hundred 3-second 360p clips cost $12.00, not $11.25, and the 75 cents of difference is real money on a batch. Plan with the per-job figure. If the same ten stingers can be one 10-second clip cut into pieces instead, the arithmetic changes: 10 seconds at 360p is $0.38, against $1.20 for ten separate 3-second jobs. That trade is only worth it if one prompt can produce all ten beats, so test a sample first.

A 4K 3-second clip costs $1.13. If a draft only needs to prove composition, 360p at $0.12 is a tenth of that. Render drafts low, then re-submit the winners at the final tier.

Compute it without float surprises

Binary floats cannot hold most decimal prices exactly, so a ceiling applied to a float product can land a cent off. Work in integer micro-dollars, as the catalog's list micros do, and ceil once.

def billed_cents(list_per_second_micros: int, seconds: int) -> int:
    list_micros = list_per_second_micros * seconds
    billable_micros = list_micros * 125 // 100 + (1 if list_micros * 125 % 100 else 0)
    return -(-billable_micros // 10_000)


# Omni list rates in micro-dollars per second
for tier, micros in [("360p", 30_000), ("720p", 100_000),
                     ("1080p", 150_000), ("4K", 300_000)]:
    print(tier, billed_cents(micros, 3) / 100)

The output is 0.12, 0.38, 0.57 and 1.13, matching the table. The second line of the function sums an extra micro-dollar when the multiple does not divide evenly, and the third line ceils to a whole cent.

Keep one more thing in mind when you port budget code: the figure above is the billable amount. The reservation at submit can differ from the captured amount for edit jobs, where the source clip sets the output length and a duration field is only a reserve hint (default 8 seconds). For ordinary text-to-video and image-to-video jobs on Omni, duration is the one you send. See the short-clip uses post for what 3 seconds is good for.

When the rounding matters and when it does not

The ceiling adds at most one cent per job. On a single clip that is noise. On a loop that submits a clip per row of a catalog, it is a systematic bias, always upward, so a forecast built on exact products is always a little low. A forecast built on the per-job figure is right to the cent.

The effect shrinks as the clip gets longer. Compare the three-second 360p clip with a ten-second 4K clip from the same table family: the first has its price moved by about 6.7 percent by the ceiling ($0.1125 up to $0.12), and a $3.75 clip has no rounding at all because the product is already whole cents. Short and cheap is where the ceiling is largest as a share, so that is where to compute carefully.

• Store money in integer cents or micro-dollars, never in floats.
• Compute the billable amount once per job and sum those, instead of summing seconds first.
• Check the finished job's usage.cost against your own number for the first few jobs; a mismatch means the catalog row changed or your formula is stale.
• Treat the catalog's billable_formula as the source of truth when it disagrees with a blog table, including this one.