Unit-test your Omni price math before Oct 22: Python asserts for Sume

Put the price of a Sume Omni clip under test before you change a model id: write the rate table once with Decimal, reject lengths the model does not accept, and compare each real usage.cost with your own figure to within one cent. The script below does all three in plain Python and prints ok when it passes. It uses the rates Sume's docs imply, the provider list of $0.03, $0.10, $0.15 and $0.30 times 1.25.

The test file

The tests use asserts, so they run under pytest or with plain python. Use Decimal and strings, not floats, because $0.0375 a second does not survive float arithmetic cleanly in a total over many jobs. The one-cent tolerance exists because a billed amount may be rounded to cents, so the test should not fail on a fraction of a cent.

from decimal import Decimal as D

RATE = {"360p": D("0.0375"), "720p": D("0.125"), "1080p": D("0.1875"), "4K": D("0.375")}

def omni_cost(seconds, resolution):
    if int(seconds) != seconds or not 3 <= seconds <= 10:
        raise ValueError("Omni takes whole seconds from 3 to 10")
    return RATE[resolution] * seconds

def close(a, b):
    return abs(D(str(a)) - D(str(b))) < D("0.01")

def test_known_prices():
    assert omni_cost(8, "720p") == D("1.00")
    assert omni_cost(8, "1080p") == D("1.50")
    assert omni_cost(10, "4K") == D("3.75")
    assert omni_cost(10, "360p") == D("0.375")

def test_rejects_bad_lengths():
    for bad in (2, 11, 7.5):
        try:
            omni_cost(bad, "720p")
        except ValueError:
            continue
        raise AssertionError(bad)

def test_poll_cost_matches(poll):
    assert close(poll["usage"]["cost"], omni_cost(8, "720p"))

test_known_prices()
test_rejects_bad_lengths()
test_poll_cost_matches({"usage": {"cost": 1.0}})
print("ok")

What each test protects

The first test pins four prices that appear in this post series, so a rate change shows up as a failing test instead of a surprise on the invoice. The second encodes the 3 to 10 second window in the Sume docs; a caller that passes 11 seconds, 2 seconds or 7.5 seconds is wrong before the request leaves your machine. The third is the check you run on real data: after a job completes, compare usage.cost with the figure your code predicted.

When the test should fail

It should fail when Sume changes a rate, and that is the point: update the table only after you have read the new price from the catalog or from a completed job. It should also fail when a caller asks for a length Omni does not take, and then the fix is a clamp or a split, not a looser test. Run the file in CI on every deploy until Google's October 22 shutdown has passed and your migration is complete.

Extending it

Add one row per model you use. The Wan 3.0 rate is $0.0625, $0.125 and $0.25 a second at 480p, 720p and 1080p, and it accepts 2 to 30 seconds, so a new function with a different window is a copy of the first. Keep one function per model so that a model swap is a diff in one place.