Paid Tier 1: gemini-3.7-flash failing across Standard, Flex, Batch & Background — Priority downgraded to Standard

Gemini API
1

We are evaluating gemini-3.7-flash for a production football-intelligence application and are experiencing persistent failures with the same representative production workload across multiple Gemini API execution routes.Important: We have confirmed the API key used by the application belongs to this exact paid Tier 1 project, so this is not a free-project/key mismatch.

Account/project

  • Google AI Studio
  • Paid Tier 1 · Prepay
  • Project: Default Gemini Project
  • Project ID: gen-lang-client-0379859785
  • Billing is active and funded.
  • We have verified locally that the API key used by the application is the same key shown against this paid project in AI Studio.

Workload

  • Model: gemini-3.7-flash
  • thinkingLevel: "high"
  • maxOutputTokens: 8192
  • Structured JSON response
  • Large factual football-data payload plus a substantial system instruction
  • No tools
  • One fixture/request during diagnostics

We deliberately tested only one representative fixture and avoided repeated resubmission.

Observed failures

1. Standard

The synchronous request failed to return successfully and timed out.

2. Flex

Request failed with HTTP 503 / capacity unavailable.

3. Batch

Submission was accepted successfully and progressed from PENDING to RUNNING.

Batch job:
batches/da1pz62xs93q7w2t4qwbeqswzz5gslrptajb

The batch ran for approximately 2h17m. The overall batch eventually reported BATCH_STATE_SUCCEEDED, but its single inference request failed with:

code 4: "Deadline expired before operation could complete"

No usable model output was returned.

4. Interactions API / Background Execution

After correcting an initial request-schema error, Background Execution successfully accepted the same HIGH-thinking workload and returned status: "in_progress".

Interaction:
v1_ChZNZ3lOYXNtcE1OR29rZFVQbF9lbGVREhZNZ3lOYXNtcE1OR29rZFVQbF9lbGVR

Subsequent GET retrieval attempts, including attempts approximately eight hours apart, returned HTTP 500:

"The model is currently experiencing high demand, spikes in demand are usually temporary. Please try again later."

This prevented us from determining the terminal state of the interaction.

5. Priority Background diagnostic

A subsequent corrected Background request explicitly requested Priority service.

Interaction:
v1_ChdPSHVOYXJxVEI5UGxuc0VQcjltTHNBaxIXT0h1TmFycVRCOVBsbnNFUHI5bUxzQWs

It was accepted with HTTP 200 and status: "in_progress".

However, although we requested Priority, the creation response echoed:

"service_tier": "standard"

We have deliberately stopped further experimentation rather than repeatedly consuming API capacity without understanding the cause.

What we need help establishing

  1. Why is gemini-3.7-flash failing for this workload across Standard, Flex and Batch, while Background Execution is accepted but retrieval returns high-demand HTTP 500 errors?
  2. Is there a known capacity/reliability issue affecting gemini-3.7-flash HIGH-thinking workloads?
  3. Why does a Background Interaction submitted with service_tier: "priority" return "service_tier": "standard"?
  4. Is this documented Priority→Standard congestion fallback, an account/tier restriction, or something else?
  5. Is Priority inference available to a Tier 1 Prepay Gemini Developer API project for this model?
  6. What execution route does Google recommend for production workloads consisting of a large structured factual payload + HIGH thinking + structured JSON output where generation can exceed normal synchronous HTTP durations?
  7. Should this workload remain on the Gemini Developer API using Background Execution, or should production use Vertex AI instead?
  8. If Vertex AI is recommended, would standard PayGo materially improve capacity/reliability, or would Provisioned Throughput be required?
  9. Can Google inspect the Batch job and Interaction IDs above to determine the actual server-side cause of these failures?

We are not looking to reduce reasoning quality unless technically necessary. gemini-3.7-flash produced sufficiently strong football intelligence in our evaluation that we would like to use it in production if a reliable supported execution route exists.

Any guidance from the Gemini API team on the correct production architecture for this workload would be greatly appreciated.

2

Hi

Thank you for reaching out

Could share the following with me via DM

  1. The project ID/Billing ID you are used for these request
  2. Approximate input token count or sample payload
  3. Do you have any configured client timeout for synchronous requests.