Gemini 3.1 Models Return 400 INVALID_ARGUMENT

[pidevxplay]

Gemini 3.1 Models Return 400 INVALID_ARGUMENT

Date: 2026-05-15
Upstream repo: https://github.com/ink1ing/anti-api
Affected models: gemini-3.1-pro-high, gemini-3.1-pro-low, gemini-3.1-flash

Problem

The upstream model list endpoint (v1internal:fetchAvailableModels) now returns gemini-3.1 model names instead of the old gemini-3 names. When sending a chat request with the new names to v1internal:streamGenerateContent, Google returns:

400 INVALID_ARGUMENT - "Request contains an invalid argument."

Google does not specify which argument is invalid. The error body is:

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

Reproduction

1. Start anti-api
2. curl -s http://localhost:8964/v1/models shows gemini-3.1-pro-high etc.
3. Send: curl http://localhost:8964/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"gemini-3.1-pro-high","messages":[{"role":"user","content":"hi"}]}'
4. Result: 400 INVALID_ARGUMENT

Root Cause

The codebase has hardcoded model names and enum values for gemini-3 only, not gemini-3.1.

In src/services/antigravity/chat.ts, MODEL_MAPPING only has:

• gemini-3-pro-high
• gemini-3-pro-low
• gemini-3-flash

In src/proto/encoder.ts, getModelEnumValue() checks for "gemini_3_pro" but not "gemini_3_1_pro".

Suspected Invalid Field

The request sent to Google includes fields that Gemini 3.1 models may reject:

• stopSequences with Anthropic-specific Claude strings
• safetySettings with threshold "OFF" (newer Gemini may reject this)
• systemInstruction format
• maxOutputTokens: 64000 exceeding model limits

Google does not reveal which field is the problem. Systematic field-by-field testing against the upstream API is needed to identify the exact invalid field.