Written by Oğuzhan Karahan
Last updated on Jul 17, 2026
●15 min read
Gemini 3.5 Flash Not Working? Fix 400, 429 and Empty Replies
A 400, 429, or blank reply rarely means the model is simply broken.
Most Gemini 3.5 Flash failures come from request structure, quota capacity, tool mismatches, or migration gaps.
Use this diagnostic map to isolate the real cause and apply the matching fix.
Your request should have worked.
Instead it returned a 400, a 429, RESOURCE_EXHAUSTED, or an empty reply.
The first instinct is that Gemini 3.5 Flash not working means the model itself is down.
Not quite.
Most production failures come from request structure, quota capacity, function-response mismatches, migration drift, or temporary platform pressure.
The real cost is wasted retries while the root cause stays hidden.
The better move:
Treat the failure as a diagnosis problem, not proof the model is broken.
By the end, the next fix should feel like a workflow decision, not a guess.
Map Gemini API 400 invalid request, Gemini API 429 error, and Gemini 3.5 Flash empty response before you rewrite prompts.
Then check tool-call failures and capacity pressure against the official model identity gemini-3.5-flash.
Keep every claim grounded in source-supported capability anchors only.
Classify the signal first. Apply the matching repair next.
Gemini 3.5 Flash Not Working: Symptom Triage First
Most Gemini 3.5 Flash not working cases resolve faster when you classify the symptom first. Separate a 400 invalid request, a 429 or RESOURCE_EXHAUSTED response, an empty reply, a tool failure, and temporary capacity pressure before you rewrite prompts at random.
Random prompt rewrites waste time when the failure class is already in the response.
Start with the status code, the full error payload, and the exact model string you sent.
Confirm the request uses gemini-3.5-flash, not a stale alias.
Then note whether the failure is immediate, intermittent, or only on tool-enabled calls.
Symptom | Likely cause class | First check |
|---|---|---|
Gemini API 400 invalid request | Structure, model ID, schema, or payload | Validate model string and payload shape |
Gemini API 429 error / RESOURCE_EXHAUSTED | Quota, rate limit, capacity, or tier mismatch | Read full 429 payload; try another model on the same key |
Gemini 3.5 Flash empty response | Finish path, parsing, or non-text parts | Log the full response object, not only text |
Tool-call or function-response failure | Tool contract mismatch | Retry once with tools disabled |
Capacity or temporary platform pressure | Allocation pressure | Retry later; test a minimal payload |
The practical result: classification picks the fix path in minutes.
Source-reported patterns show other models can succeed under the same key.
That is an isolation signal, not proof the model is broken.
If tools or structured outputs were enabled, mark that early.
Agent-only failures need a different path than plain text calls.
Use this map to pick the next path: rate limits, invalid requests, empty output, tools, or capacity.
Gemini API 429 Error: Quota, Rate Limits, and RESOURCE_EXHAUSTED
A Gemini API 429 error usually points to quota, rate limit, capacity allocation, tier or billing mismatch, or RESOURCE_EXHAUSTED pressure. It rarely means gemini-3.5-flash itself is broken. Read the full payload first, then match recovery to persistent quota exhaustion or temporary capacity pressure.
When a request fails with 429, capacity is the story, not model quality.
Official guidance treats 429 as request volume exceeding the capacity allocated to process requests.
That creates a trade-off:
You can keep retrying blindly, or you can classify whether Gemini 3.5 Flash quota pressure is persistent versus short-term capacity strain.
Source-reported developer threads sometimes show a Gemini API 429 error even with low visible usage.
Treat that as a pattern to investigate plan association, model-specific capacity, and billing language in the payload, not as proof the model is offline.
How to Read 429 and RESOURCE_EXHAUSTED Signals
Open the full error object, not only the status code.
Look for RESOURCE_EXHAUSTED wording and any plan or billing references in the message.
Confirm the failing model string is gemini-3.5-flash.
Then test whether another model succeeds under the same key or project.
If other models work, the issue may be model-specific capacity or Gemini 3.5 Flash quota allocation rather than a dead key.
If every model fails, inspect project association and usage monitoring next.
A free-tier style quota message on a billed project is a classification clue.
It does not by itself prove an outage or a broken model.
Practical Recovery Moves for Rate-Limit Pressure
When the Gemini API rate limit or capacity signal is clear, recover with controlled retries and lower burst traffic.
Use truncated exponential backoff instead of tight retry loops.
Smooth traffic so large request spikes shrink.
Prefer a global endpoint over a regional endpoint when your surface supports it.
Submit a Quota Increase Request when quotas apply, or consider Provisioned Throughput for reserved capacity as officially described.
Stop retrying requests that are also invalid.
Persistent quota exhaustion needs plan, usage, or throughput changes.
Temporary capacity pressure often improves after backoff and traffic smoothing without architecture rewrites.
Gemini API 400 Invalid Request: Structure, Schema, and Model ID
A Gemini API 400 invalid request almost always points to request structure, model ID, unsupported parameters, schema, payload shape, or modality limits rather than model downtime. Validate the model string, payload shape, and supported inputs for gemini-3.5-flash before you treat the failure as an outage.
A 400 is a construction problem, not proof the model is offline.
Your client sent a request the API cannot accept.
Fix the payload shape first, then retry with the same prompt logic.
Model ID, Payload Shape, and Unsupported Inputs
Start by verifying the exact stable model code.
Use gemini-3.5-flash unless you intentionally need a documented preview alias.
Wrong or deprecated model strings often trigger a Gemini API 400 invalid request.
gemini-3.5-flash accepts Text, Image, Video, Audio, and PDF inputs, and returns Text only.
Image generation, audio generation, and the Live API are not supported.
Stay inside the documented limits of 1,048,576 input tokens and 65,536 output tokens.
If you attach files, confirm MIME type and size against the limits for your API surface.
Confirm the model string is exact
Drop unsupported generation modes
Validate multimodal file type and size
Schema Mismatches and Invalid Generation Settings
Malformed structured-output schemas and broken function declarations often fail before generation starts.
Conflicting generation settings can reject the request as well.
Validate the request body against official schema expectations, then simplify.
Remove one field group at a time until the 400 disappears.
That isolates the bad field without a full rewrite.
Legacy sampling knobs can also break Gemini 3.x request construction.
Fix hard invalid fields first, then handle migration defaults later.
Gemini 3.5 Flash Empty Response: Why Output Goes Blank
A Gemini 3.5 Flash empty response can come from max-output constraints, finish reasons, thinking or tool side paths, safety or refusal paths, or client parsing that discards non-text parts. Log the full response object before you assume the model returned nothing.
Blank text is not always an empty API result. Many clients only print the first text field and ignore everything else.
Start with the complete response payload. Inspect candidates, content parts, and any finish path fields your SDK exposes. Do not stop at response.text if the object has more structure.
gemini-3.5-flash returns text only and supports an output limit of 65,536 tokens. Hitting a low max-output setting or stopping early can leave you with truncated or missing visible text.
Thinking is supported, and migration guidance sets default thinking effort to medium. Prefer thinking_level values such as minimal, low, medium, or high. Avoid legacy thinking_budget settings that no longer match Gemini 3.x guidance.
The practical result: tool and structured-output runs can look empty when the model returned a function call or non-text part. Your parser may be discarding the only useful content.
Also separate a true blank candidate from a refusal-style stop. Source-reported product threads sometimes show mid-task refusals that replace expected code or text. Treat those as side-path behavior, not proof of platform outage.
Quick differential only: a 400 is a rejected request, and a 429 is capacity pressure. A Gemini 3.5 Flash empty response usually means the call completed, but the visible text path is empty or unread.
Log the full response object and finish path
Check for function-call or structured parts before non-text discard
Confirm max-output and thinking_level settings
Retry once with a minimal text-only prompt
If the minimal prompt returns normal text, the original blank path is configuration or parsing, not a dead model.
Tool Calls, Function Responses, and Compatibility Breaks
Many agent failures labeled as a Gemini 3.5 Flash error are actually function-response mismatches, unsupported tool combinations, or preview tool assumptions rather than core model failure. Isolate tools first, then inspect the function-response contract before you rewrite prompts.
When a tool-enabled run fails, disable tools and retry a minimal text request under the same project and key.
If plain calls succeed and tool runs fail, treat the path as a compatibility or contract issue.
Official docs for gemini-3.5-flash list function calling, structured outputs, search grounding, maps grounding, file search, code execution, URL context, and caching as supported.
Combined tool use is documented for those built-ins.
Function-Response Mismatches That Stall Agents
Agent loops stall when the model emits a function call and the client returns a bad response.
Common breaks include missing required fields, wrong response shape, incomplete multi-turn tool history, or mishandled parallel tool calls.
That can surface as a Gemini 3.5 Flash error only on the agent path.
Log tool names exactly as emitted
Capture argument JSON before execution
Verify the response envelope returned to the model
Confirm every tool turn remains in history
Supported Tools vs Preview Assumptions
Function calling and structured outputs are stable anchors for gemini-3.5-flash.
Other built-ins such as search grounding, maps grounding, file search, code execution, URL context, and caching are also source-supported.
Computer use needs more caution.
Some official pages mark it as preview support, while other guidance conflicts.
Treat computer use as preview and surface-dependent.
Verify the current capability matrix for your API surface before you ship agent flows that rely on it.
When a Gemini 3.5 Flash error appears only on agent runs, isolate the failing tool path before you change model settings.
When Older Gemini Requests Fail on Gemini 3.5 Flash
Requests that worked on older Gemini models can fail on Gemini 3.5 Flash because of parameter and thinking default changes, not because the model is unavailable. Audit legacy generation_config, thinking settings, and sampling knobs before you treat the switch as an outage.
gemini-3.5-flash is generally available, stable, and ready for scaled use.
So a failure after a model swap is often config drift, not proof the endpoint is down.
The practical result: older generation settings can conflict with Gemini 3.x guidance even when the prompt text is unchanged.
Default thinking effort is now medium, changed from high in Gemini 3.
Prefer thinking_level with minimal, low, medium, or high. Replace legacy thinking_budget numeric settings.
For all Gemini 3.x models, temperature, top_p, and top_k are no longer recommended.
Reasoning is optimized for default settings, so remove those sampling parameters from requests.
If you need determinism, put explicit rules in a system instruction instead of sampling knobs.
gemini-3.5-flash still supports thinking, a 1M token context window, 65,536 max output tokens, and the same broad tool set as Gemini 3 Flash where documented.
Tool parity does not validate a legacy generation_config by itself.
For Gemini 3.5 Flash troubleshooting after an upgrade, clean the config first.
Confirm the model string is exactly
gemini-3.5-flashReplace
thinking_budgetwiththinking_levelRemove temperature, top_p, and top_k
Retest a minimal version of the old request
If the cleaned request succeeds, keep that baseline before you restore extra fields.
Capacity Pressure vs Client Misconfiguration
Temporary platform capacity issues can look identical to client misconfiguration. When Gemini 3.5 Flash not working symptoms continue, run a short differential test before you change production architecture. Isolate first, then decide if the fix is client-side or capacity-side.
A deterministic failure on the same minimal payload usually points to client misconfiguration.
Intermittent success after backoff, another model, removed tools, or a global endpoint points more toward capacity pressure.
Official 429 guidance frames the error as capacity allocation when requests exceed what the system can process. That can be temporary even when the payload looks correct.
Source-reported developer reports describe low-usage 429s and model-specific blocks while other models still work under the same key. Treat those as isolation cues, not confirmed outages.
Before you redesign production traffic, run these isolation checks:
Retest the same payload as a minimal text request with no tools.
Try an alternate model under the same project or key.
Prefer a global endpoint when your surface allows it.
Retry later with truncated exponential backoff and classify intermittent vs every-request failure.
If the minimal request still fails every time, focus on client configuration.
If isolation clears the error, treat temporary capacity pressure as the leading hypothesis.
Decision Checklist: Classify the Failure in Minutes
Use this decision checklist as a rapid classifier for Gemini 3.5 Flash troubleshooting. Map status code, payload behavior, and tool path in minutes, then take the matching next action for 400, 429, empty output, tool mismatch, migration drift, or temporary capacity.
Stop rewriting prompts at random.
Branch on the first hard signal.
Read the status and full error body. Confirm
gemini-3.5-flash.On 400: validate model ID, schema, modalities, and settings with a minimal payload.
On 429 or RESOURCE_EXHAUSTED: check usage, tier, and billing, then backoff and smooth bursts.
On empty output: log the full response, finish reason, and candidate parts.
On tool-only failure: disable tools, re-enable one at a time, fix function-response shape.
On legacy-config failure: drop sampling knobs and switch to
thinking_level.On intermittent or model-specific failure: isolate capacity before architecture changes.
When Gemini 3.5 Flash not working remains unclear, keep the isolation log and fix only the class that failed.
Frequently Asked Questions
Why does Gemini 3.5 Flash fail while other Gemini models work under the same API key?
That pattern often points to model-specific quota, capacity allocation, or request settings for gemini-3.5-flash rather than a fully dead key. Isolate with a minimal text call, compare another model on the same project, and only then change auth or architecture. Treat the contrast as a classification signal, not proof the model is broken.
Does a Gemini API 429 error mean my API key is broken?
Usually no. A Gemini API 429 error more often means request volume exceeded allocated capacity, quota pressure, or a related plan and billing constraint. Read the full payload for RESOURCE_EXHAUSTED and billing language, check project association and usage, then use truncated exponential backoff before rotating keys.
Why can Gemini 3.5 Flash return RESOURCE_EXHAUSTED on the first request or with low visible usage?
Source-reported developer reports describe immediate free-tier or low-usage blocks that are model-specific while other models still work. Treat that as a cue to inspect plan association, the exact model string, tools, and capacity isolation. It is not proof that Gemini 3.5 Flash quota is permanently gone or that the model is offline.
Should I use gemini-flash-latest if gemini-3.5-flash is not working?
Prefer the stable model code gemini-3.5-flash for production debugging unless you intentionally need a documented preview alias. Aliases can change routing and hide whether the failure is model-specific capacity or an outdated string. Confirm the exact model ID in both the request and the error payload.
What should I check if the HTTP call succeeds but Gemini 3.5 Flash text looks empty?
A Gemini 3.5 Flash empty response is not always empty at the API layer. Log the full response object, finish path, and candidate parts before assuming nothing returned. Tool calls, structured parts, low max-output settings, thinking-side paths, or parsers that only read text can hide useful content.
Can I keep temperature, top_p, and top_k after upgrading to Gemini 3.5 Flash?
For Gemini 3.x models those sampling parameters are no longer recommended because reasoning is optimized for defaults. Remove them, replace thinking_budget with thinking_level values such as minimal, low, medium, or high, and put determinism rules in a system instruction when needed. Clean the config before you treat Gemini 3.5 Flash troubleshooting as an outage.
Is computer use supported on Gemini 3.5 Flash?
Treat computer use as surface-dependent and preview-sensitive. Some official model and Cloud pages mark it as supported preview, while one migration snapshot says it is not supported. Verify the capability matrix for your exact API surface before enabling it in production agents.
