GitHub issue gravitee-io/issues#11964 records HTTP 400 from Vertex for gemini-4-argon when reasoning_effort is mapped to thinkingBudget, and when thinkingBudget is sent directly. The JSON message is the sentence above, then: See https://ai.google.dev/gemini-api/docs/thinking for details. A direct Vertex call with generationConfig.thinkingConfig.thinkingLevel set to LOW returned 200. The same issue says Google's own OpenAI-compatible endpoint accepted reasoning_effort for that model. Models that accepted reasoning_effort through that gateway were gemini-3.5-flash, gemini-3.6-flash, gemini-3.5-flash-lite, and gemini-3.8-flash. Issue can1357/oh-my-pi#16350 records the shorter sentence Google API error (400): Thinking budget is not supported for this model. for gemma-4-26b-a4b-it and gemma-4-31b-it. The maintainer comment says the catalog sent thinkingBudget, and that Gemma 4 docs describe thinking as on or off via thinkingLevel (high on, minimal off). Those two gemma ids are not in the SunsetDiff dataset, so they are not linked below. The thinking guide says you can control this behavior using the thinking_level parameter. Its sample uses gemini-3.8-flash. The guide's table lists low, medium, and high for gemini-4-argon. This page does not rewrite that sample's model id.
Source: Gemini API thinking guide, checked October 21, 2026.
Affected models
gemini-4-argon is in the SunsetDiff dataset. gemma-4-26b-a4b-it and gemma-4-31b-it are named in can1357/oh-my-pi#16350 and are not linked because SunsetDiff has no model record for them.
Issue gravitee-io/issues#11964 records HTTP 400 on Vertex when thinkingBudget is sent, including when a gateway maps reasoning_effort to thinkingBudget. thinkingLevel LOW returned 200 on a direct Vertex call.
Fix
Raw SDK
Send thinking_level instead of thinkingBudget. The sample below is copied from the thinking guide. It uses gemini-3.8-flash. The Vertex issue recorded thinkingConfig.thinkingLevel LOW returning 200 on gemini-4-argon. This page does not change the guide's model id.
Python
from google import genai
client = genai.Client()
interaction = client.interactions.create(
model="gemini-3.8-flash",
input="Provide a list of 3 famous physicists and their key contributions",
generation_config={
"thinking_level": "low"
}
)
print(interaction.output_text)
curl
curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
-H "x-goog-api-key: $GEMINI_API_KEY" \
-H 'Content-Type: application/json' \
-d '{
"model": "gemini-3.8-flash",
"input": "Provide a list of 3 famous physicists and their key contributions",
"generation_config": {
"thinking_level": "low"
}
}'
This page does not show a LiteLLM call. The recorded gateway is Gravitee's LLM proxy, which mapped reasoning_effort to thinkingBudget and received this 400. The issue says to send thinkingLevel instead.
The same issue says a native Gemini client (@ai-sdk/google 4.0.96) sent generationConfig.thinkingConfig.thinkingLevel, and the gateway rewrote it to thinkingBudget, which returned 400. Direct to Vertex, the same thinkingLevel body returned 200. This page does not add an AI SDK snippet beyond that report.
gravitee-io/issues#11964 records it for gemini-4-argon on Vertex. can1357/oh-my-pi#16350 records a shorter form of the sentence for gemma-4-26b-a4b-it and gemma-4-31b-it. Those gemma ids are not in the SunsetDiff dataset.
What should the request send instead of thinkingBudget?
thinkingLevel. The thinking guide calls the parameter thinking_level and links from the error message. The guide's sample is shown under Raw SDK and uses gemini-3.8-flash.
Do OpenAI-compatible gateways hit this error?
The Gravitee issue records a gateway that maps reasoning_effort to thinkingBudget. That mapping returned this 400 for gemini-4-argon. Google's own OpenAI-compatible endpoint accepted reasoning_effort for that model in the same report.