Where The Filter Draws The Line

I spent $2.63 on twelve clips working out what this model refuses to make. I had it backwards.

I had assumed the filter would balk at danger. It didn't. A named five-year-old, alone in a clearing, waving his arms to pull a charging tyrannosaurus onto himself: generated first try. Same for the two of them breaking out of police custody with an office chair.

One prompt out of twelve came back blocked. It was two kids sitting still in the back of a police car, which is about the calmest thing I asked for all day.

What was blocking us in May

In May I evaluated mitte.ai and Google Flow on a whole scene. The clips held up. Three things about the tooling did not.

No API:

The tooling is a website. There's no API, so "rendering a scene" means me clicking through a browser, uploading the same reference images over and over, one shot at a time.

And, in the same post's closing assessment: "They still can't be scripted, everything is a person clicking."

The watermark:

The trade: the expensive Veo models stamp a "Veo" watermark into the corner of every frame. Omni Flash only leaves a small sparkle. Neither is something I want in a finished film.

And the kids:

They still flinch at the kids: Veo's safety filter rejected my first prompt outright for describing children too specifically, and I had to launder the language to get a frame out of it.

That last one is not a cosmetic problem. Veo 3.1 returned no_media_generated on prompts that described Mia and Leo as children, so I adopted a workaround: describe the environment, describe "figures" and "characters," and let the input image carry the fact that there are two kids on the couch. It works, in the sense that you get a frame out. It also means the prompt cannot say what the shot is about, which is a bad place to be when the film is largely about two kids.

Omni 1.1 Flash removes all three. The API is real, a single client.interactions.create call. There is no visible watermark: I cropped the bottom-right corner of all four frame grabs and upscaled 3×, and found no mark, logo or text overlay in any clip. (SynthID is imperceptible by design and would not show up this way; this finding is only about a visible mark.) And the third one turned out to be the interesting one.

Clips generated

12Across three probes, all 360p

Blocked

1Scenario A, child-explicit wording

Reference images

≥ 12Published sources say 3, 6 or 7

Total spend

$2.63Token-metered, ~$0.034/s at 360p

Everything is here. The clips are the real output and the prompts are what I actually sent. Turn the sound on. Every one of them was told "No dialogue. No music. Silent."

Same shot, different words

Each pair below is the same beat, same reference images, same camera direction. The one thing I changed is whether the prompt says these are children.

Does it work at all?

All of that came after a cheaper question. I ran four clips at 360p to see whether the model can do the things my pipeline needs.

What broke

Four things, one of which cost real money.

The $0.35 duration lesson

duration lives on response_format, as a string:

response_format={
    "type": "video",
    "aspect_ratio": "16:9",   # only "16:9" | "9:16"
    "resolution": "360p",     # "360p" | "720p" | "1080p" | "4k"
    "duration": "5s",         # STRING, 3s-10s, defaults to 10s if omitted
},
generation_config={"video_config": {"task": "image_to_video"}},

I went looking for the duration parameter by putting a speculative duration_seconds int under generation_config.video_config. Unknown keys in video_config do not raise. The API accepted it, silently ignored it, generated a full-length 10s clip, and billed for it. What I expected was a free 400. What I got was $0.3521 and a clip I never saw and never saved.

The wrong conclusion I drew from it

Worse than the money: from that silent ignore I concluded the model had no duration control, and that went into a status report before it got caught. It was wrong. Valid values work fine. The bounds are confirmed by the errors they produce. "999s" returns Requested video duration 999s 0ns exceeds the maximum allowed 10s 0ns, and "0.5s", "1s" and "2s" all return is less than the minimum allowed 3s 0ns. The range is continuous rather than an enum of 4/6/8/10. And end to end, duration="5s" produces a clip that ffprobe reports as 5.013s.

An API that silently ignores an unknown key looks identical to an API that lacks the feature. The only difference is the bill.

A probe that was never going to work

The plan for finding the reference-image cap was to send N corrupt images and read the rejection, on the theory that rejected requests are free. That does not work here. Sending N corrupt images returns Unable to process input image for every N up to 12, because image decode runs before any count validation. The decode error masks the count check permanently, at every N.

Which means establishing the real limit requires valid images, and a valid within-limit request generates video. That is where PROBE_12refs.mp4 came from, and it cost an unplanned $0.3808. The free-rejection technique is genuinely useful for enumerating accepted values, and most of the API surface in this run was mapped that way, because an invalid value makes the server echo the supported set back in the 400 message. It just cannot reach a check that sits behind a decode step.

The SDK trap

Before any of that, nothing worked at all. The repo pins google-genai==1.61.0, which sends the legacy Interactions wire format that the May 2026 breaking change retired. Every call fails with:

The legacy Interactions API schema is no longer supported.
Please upgrade your google-genai Python SDK to version >= 2.0.0

This run went against 2.20.0 in a throwaway venv, because bumping the pin repo-wide would touch every image-generation script in the project. That is a decision I still have to make: upgrade globally and regression-test the image scripts, or keep Omni on its own venv.

Two clips I did not mean to buy

Six clips generated, four planned. The duration probe and the twelve-reference probe were both unplanned, and together they are $0.7329 of a $1.8097 run, a bit over 40% of the spend. The original cap on this task was $1.50. At that cap those two clips would have squeezed out G4, which is the one that told me references carry identity but not wardrobe. The cap got raised to $2.50 mid-run instead.

What it cost

Billing runs on output tokens rather than seconds of video. At 360p a clip costs 1,931 video tokens per second, which measured out to about $0.034/s.

What this doesn't prove

Twelve clips is not a map of anything. The vehicle-versus-building line is what I measured on one afternoon, and Google can move it whenever they like without telling me. Scene 17 is the other car scene and I still haven't tested it. Whatever wording policy I settle on, the pipeline needs to catch a 400 and stop, rather than assume every shot comes back.

These are all 360p because 360p is cheap. They show the API doing what I need it to do. They are not what the film looks like.

And the audio problem is real. There is no parameter for it. Shots with people in them come back loud no matter what the prompt says, so everything gets an unconditional strip on the way in.