Antigravity: Gemini 3.1 Pro (high) fails with "Generation error" / "Request contains an invalid argument"

[gildeshiro]

Description

When using the Antigravity provider, Gemini 3.1 Pro (high) — which is offered as a default model in the Piebald model selector — fails immediately on the first message with a "Generation error". The backend log shows:

ERROR backend::services::title_generation: Auto title generation failed for chat 104:
Failed to generate title with LLM: Request contains an invalid argument.

Steps to reproduce

1. Sign in to Antigravity provider in Piebald
2. Select Gemini 3.1 Pro (high) from the model dropdown (it's offered by default)
3. Send any message (e.g. "hello")
4. Observe "Generation error" in the chat

Expected behavior

The model should respond normally, as it does in the Antigravity IDE itself.

What works / what doesn't

Model	Status
Gemini 3 Flash	✅ Works
Gemini 3.1 Pro (low)	✅ Works
Gemini 3.1 Pro (high)	❌ Fails — "Request contains an invalid argument"

Hypothesis

Since Gemini 3.1 Pro (low) works fine but (high) does not, the issue may be:

• A model ID mismatch in the Antigravity API mapping (e.g. the model ID sent for "high" doesn't match what the current Antigravity API expects)
• Different API parameter requirements between the (high) and (low) variants (thinking config, safety settings, etc.)

Environment

• Piebald v0.3.2 (Windows 11)
• Antigravity provider (Google account OAuth)

[bl-ue]

Hi @gildeshiro, what is the exact generation error message you see? Do you mind sending a screenshot?

[gildeshiro]

Hey @bl-ue 👋 — sorry for the slow follow-up. I dug into this at the HTTP-traffic / app.db level and have a fairly complete answer, including the exact error and a controlled comparison that isolates the cause.

Exact error (HTTP response body)

The request goes to the Cloud Code (Antigravity) endpoint:

POST https://daily-cloudcode-pa.sandbox.googleapis.com/v1internal:streamGenerateContent?alt=sse

and comes back HTTP 400:

{ "error": { "code": 400, "message": "Request contains an invalid argument.", "status": "INVALID_ARGUMENT" } }

(This is also what blows up auto-title-generation — same request, same 400.)

Key finding: -low and -high send an identical payload — only the model id differs

I captured the outgoing request bodies for both variants (same trivial prompt, same default profile):

model	result	generationConfig	tool functionDeclarations
gemini-3.1-pro-low	✅ 200	{ temperature: 0.8, maxOutputTokens: 16384, thinkingConfig: { thinkingBudget: -1, includeThoughts: true } }	22
gemini-3.1-pro-high	❌ 400	identical to the above	22
gemini-3-flash	✅ 200	(no thinkingConfig)	22

The request shape is byte-for-byte the same between -low (works) and -high (fails), apart from the "model" string. That rules out thinkingConfig / tool declarations / safety settings as the cause — it's the -high model id itself being rejected server-side.

Ruled out

• Not account-specific — reproduced on two separate Antigravity Google accounts.
• Not a thinking-budget issue — changing the profile didn't help, and FWIW the profile's google_thinking_budget never even reached the request (thinkingBudget stayed -1 regardless of the selected profile).
• Not the client config — -low accepts the exact same payload and returns 200.

Hypothesis

Since the same payload with model: "gemini-3.1-pro-low" is accepted but model: "gemini-3.1-pro-high" is rejected with INVALID_ARGUMENT, it looks like gemini-3.1-pro-high isn't a valid model string for the current v1internal API. The -high/-low suffix split probably needs to map to a base model id + an explicit reasoning/thinking level, rather than being sent as a literal model id. The Antigravity IDE serves "high" fine, so the IDE is likely sending a different model id (or a level parameter) than Piebald's literal gemini-3.1-pro-high.

Happy to share the full captured request/response bodies if that's useful. Thanks for the great work on Piebald! 🙏