Subject: gemini-omni-flash-preview — all video-input (edit) requests fail with generic
400 invalid_request since 2026-07-28; image input still works
Hi,
Since the morning of 2026-07-28 (UTC+3), every Interactions API request to
gemini-omni-flash-preview that includes a VIDEO input fails with a generic 400.
The same pipeline had been working reliably for weeks and its last successful
runs were on 2026-07-27. Nothing changed on our side: no deploy, no dependency
update, no prompt change. The failure appeared simultaneously in two independent
environments (a production Kubernetes cluster and a local development machine),
which is what points us at a server-side change.
ERROR
Error code: 400 - {‘error’: {‘message’: ‘Request contains an invalid argument.’,
‘code’: ‘invalid_request’}}
Crucially, this response arrives 42-74 SECONDS after the request is sent.
Genuine argument-validation errors from this same endpoint come back in well
under a second and name the offending field precisely (examples we triggered
while investigating, see below). A slow, unnamed failure suggests our request
passes validation and something fails later, during processing.
ENVIRONMENT
Model: gemini-omni-flash-preview (version 001)
API: Interactions API, client.interactions.create
SDK: google-genai 2.10.0 (Python 3.11), pinned; also reproduced conceptually
against 2.14.0 type definitions — no relevant schema changes between them
Auth: Gemini API key (not Vertex)
Task: video-to-video edit — a source clip plus a text instruction, returning
an edited clip
MINIMAL REPRODUCTION
f = client.files.upload(file="clip.mp4") # 3s, H.264, state=ACTIVE
client.interactions.create(
model="gemini-omni-flash-preview",
input=[{"type": "document", "uri": f.uri},
{"type": "text", "text": "Add a subtle gold light sweep over the footage."}],
response_format={"type": "video", "aspect_ratio": "9:16"},
)
# -> 400 invalid_request after ~45s
WHAT WE HAVE ALREADY RULED OUT
We ran a systematic bisection. Results:
WORKING
• Text-only prompt → video output OK (40s)
• Image input (Files API uri) → text output OK (51s)
• Image input (Files API uri) → video output OK (42s)
• Image input INLINE base64 → video output OK (76s)
• The exact same uploaded video file read by gemini-3.5-flash
via generateContent — described correctly OK (3s)
(so the file itself is valid, ACTIVE and readable)
FAILING — every variation, identical generic 400
• Video as {“type”: “document”, “uri”: …} (as per the docs)
• Video as {“type”: “video”, “uri”: …}
• Video INLINE as base64, bypassing the Files API entirely
• With and without an audio track (-an)
• Durations 1s and 3s
• Resolutions 1080p and 480p
• With and without generation_config.video_config.task = “edit”
• Video alone, and video accompanied by image inputs
• Files uploaded fresh in every attempt, all reaching state=ACTIVE
In short: image input works, video output works, the Files API works, and the
uploaded video is readable by another model — but no combination of arguments
makes a video input succeed.
EVIDENCE THAT THE EDIT PATH CHANGED RECENTLY
While probing, the API returned these constraints instantly and explicitly:
“Aspect ratio cannot be set in response format for edit task.”
“Media resolution is not supported for model ‘gemini-omni-flash-preview’.”
“At least one image or audio must be provided for reference_to_video task.”
The first one is new to us: our production code has always sent
response_format.aspect_ratio = “9:16” together with a video input, and it was
accepted until 2026-07-27. This strongly suggests the edit task path was changed
on 2026-07-28. Removing aspect_ratio clears that specific message, but the
request then still fails with the same generic 400 after ~45s.
QUESTIONS
- Was video input (the “edit” task) for gemini-omni-flash-preview intentionally
changed, restricted or disabled on 2026-07-28? The failure is visible both
through the Interactions API and in Google Flow, so we assume it is a backend
regression rather than a client-side breaking change. - If this is an intentional change, what is the required request shape now?
We are happy to migrate immediately if you can point at the correct form. - If it is not intentional, could you investigate the backend failure? The
generic “Request contains an invalid argument” with no field name and a
~45 second latency makes it impossible to diagnose from the client side. - Independently of the above: could the error for this path be made specific,
the way the validation errors quoted above already are? That alone would
have saved a full day of bisection.
This blocks a production feature for us, so any guidance or an ETA would be
much appreciated. I can provide additional interaction IDs, timestamps or a
full request dump on request.
Thank you.