Gemini 3.7 and 3.8 Flash agentic video: repeated HTTP 500 high-demand failures

Gemini API
1

We have had repeated failures using agentic video understanding across two models.

On September 16, 2026 (US Eastern time), we made three inference attempts on an approximately 23-second MP4:

  • gemini-3.8-flash: two attempts, both failed.
  • gemini-3.7-flash: one attempt, also failed.
  • Endpoint: POST /v1beta/interactions on the Gemini Developer API.
  • Video input used a Files API URI, MIME type video/mp4, and processing set to “agentic”.
  • Authentication and video upload succeeded. Inference failed after several minutes with HTTP 500, and no usable analysis was returned.
  • The task was timestamped movement observations in a bull-riding clip.

The saved response from the 3.7 attempt was:

{"error":{"message":"gemini-3.7-flash is currently experiencing high demand, spikes in demand are usually temporary. Please try again later.","code":"api_error"}}

We found a similar agentic-video report affecting both models.

Is there a known capacity or reliability issue affecting agentic video on these models? Is there a recommended model, configuration, or retry strategy? Please let us know which diagnostic identifiers would help investigate this through a private support channel.

These are the failures we observed; we cannot determine whether all users are affected.

2

Also, yesterday I sent a video through the interface that normally costs 900,000 tokens, but with agentic video understanding it didn’t cost any tokens, of course. However, after a few minutes, it finished the analysis with a “Too many calls” error and didn’t print a response. This is another known issue. If the video to be analyzed is long and the agent is analyzing it in detail, it takes a long time to generate the response, which causes this error; the system does not generate a response.

3

Hello @andrewwingert , @Crownguard ,

Can you share your Project ID (or Request ID) and the prompt you used with us via direct message?

This will help us trace the request logs and reproduce the issue on our side.