Feature: expose Antigravity Gemini 3.5 Flash like Google API (gemini-3.5-flash + thinking_level)

[alejandroiglesias]

Summary

When routing through CLIProxyAPI to Antigravity, /v1/models exposes tier-specific IDs such as gemini-3.5-flash-low, but not the Google API-style surface:

• Base model: gemini-3.5-flash (or gateway equivalent)
• Effort control via thinking_level: minimal | low | medium | high

In Google Antigravity CLI, users can pick Gemini 3.5 Flash (Low / Medium / High) as separate product tiers. Through CLIProxyAPI (OpenAI-compatible), we only see gemini-3.5-flash-low routable; gemini-3.5-flash-medium, gemini-3.5-flash-high, and gemini-3.5-flash return 502 unknown provider for model.

We would like parity with the public Gemini API pattern documented at https://ai.google.dev/gemini-api/docs/whats-new-gemini-3.5 — one stable model ID plus generationConfig.thinkingConfig.thinking_level, instead of requiring separate hard-coded model names per tier when possible.

Environment

• CLIProxyAPI: v7.1.30 (Homebrew, built 2026-05-29)
• Provider: Antigravity OAuth (owned_by: antigravity)
• Endpoint: POST http://127.0.0.1:8317/v1/chat/completions (default local port)
• Client: OpenAI-compatible HTTP client via @ai-sdk/openai-compatible (model: openai/gemini-3.5-flash-low)

Current behavior

/v1/models (Gemini-related excerpt)

Only one 3.5 Flash tier appears:

• gemini-3.5-flash-low ✅

Missing from list / routing:

• gemini-3.5-flash-medium ❌
• gemini-3.5-flash-high ❌
• gemini-3.5-flash ❌

Direct routing test

# Works
curl -sS -H "Authorization: Bearer $KEY" \
  -d '{"model":"gemini-3.5-flash-low","messages":[{"role":"user","content":"hi"}],"stream":false}' \
  http://127.0.0.1:8317/v1/chat/completions

# Fails (same for gemini-3.5-flash-high and gemini-3.5-flash)
curl -sS -H "Authorization: Bearer $KEY" \
  -d '{"model":"gemini-3.5-flash-medium","messages":[{"role":"user","content":"hi"}],"stream":false}' \
  http://127.0.0.1:8317/v1/chat/completions
# → {"error":{"message":"unknown provider for model gemini-3.5-flash-medium",...}}

Expected behavior

One or more of the following (happy to follow project conventions):

1. Register gemini-3.5-flash for Antigravity OpenAI-compatible routing and honor thinking_level from the request (OpenAI reasoning_effort mapping or generationConfig.thinkingConfig.thinkingLevel passthrough).
2. Expose all Antigravity tiers (gemini-3.5-flash-low|medium|high) in /v1/models when the OAuth catalog provides them.
3. Document recommended mapping in oauth-model-alias if separate tier IDs must remain upstream names.

Questions for maintainers

1. Is gemini-3.5-flash-low intended to be a fixed Low SKU, or should clients override effort via thinking_level on a single gemini-3.5-flash ID?
2. If Medium/High exist in Antigravity CLI but not in /v1/models, is that a discovery gap, version gap, or intentional until a newer release?
3. Is there a supported way today to request thinking_level=medium|high while using model gemini-3.5-flash-low through the OpenAI chat-completions translator?

References

• Google Gemini 3.5 Flash docs (single model + thinking_level): https://ai.google.dev/gemini-api/docs/models/gemini-3.5-flash
• Related closed issue: 支持反重力中的Gemini 3.5 Flash Medium和High吗 还有反重力cli？ #3547 (Antigravity Gemini 3.5 Flash Medium/High)
• CLIProxyAPI config: oauth-model-alias / oauth-excluded-models — https://help.router-for.me/configuration/basic

Thanks!

[pidgeon777]

@luispater

I was curious about this as well. Is there any reason why only the gemini-3.5-flash model was added, and not the other two gemini-3.5-flash-medium and gemini-3.5-flash-high?

Also, I see that the following models are available:

• gemini-3-flash
• gemini-3-flash-agent

I was wondering: what are the differences? Which model points to the 3.5 version eventually?

[tiwersun-ui]

I meet same question

[luispater]

Thanks for the detailed report. I reviewed the current registry and routing path.

Antigravity's Gemini 3.5 Flash surface is currently exposed as gemini-3-flash-agent, and gemini-3.5-flash-low is also present as a tier-specific ID. The IDs gemini-3.5-flash, gemini-3.5-flash-medium, and gemini-3.5-flash-high are not registered today, so unknown provider for model ... is expected for those exact names.

For the Google-style stable ID, the supported workaround is to use oauth-model-alias, for example mapping gemini-3-flash-agent to gemini-3.5-flash. The OpenAI-compatible chat-completions path already maps reasoning_effort to Antigravity request.generationConfig.thinkingConfig.thinkingLevel, so clients can request low, medium, or high through that field.

Since this can be handled with the existing alias mechanism and current model surface, I'm closing this as not planned.