feat: Gemini 3.5 Flash support and openid OAuth scope#586
Conversation
|
Caution Review failedPull request was closed or merged during review WalkthroughThis PR adds Gemini 3.5 Flash model support and implements transparent legacy model ID aliasing to migrate users from Gemini 3 to Gemini 3.1 models. The model catalog gains two new Gemini 3.5 Flash entries while removing the outdated Gemini 3 Pro definition. The model resolver distinguishes Gemini 3 from 3.5 variants via improved regex patterns, normalizes legacy model identifiers before routing decisions, and forces Gemini 3.5 Flash to resolve with Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR adds
Confidence Score: 3/5Safe to merge only after fixing the stale Gemini-3 check in resolveModelWithVariant; all other changes are well-scoped. The new 3.5-Flash exclusion guards are applied in resolveModelWithTier and resolveModelForHeaderStyle, but resolveModelWithVariant still uses the old includes("gemini-3") check. Any call that supplies a thinkingBudget for a Gemini 3.5 model will receive a spurious thinkingLevel on the returned object, which the 3.5 API rejects. No test exercises this path, so the bug would ship silently. src/plugin/transform/model-resolver.ts — the resolveModelWithVariant function needs the same GEMINI_3_NOT_35_REGEX guard applied to its isGemini3 check. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Incoming model ID] --> B[normalizeLegacyModel]
B -->|match in LEGACY_MODEL_ALIASES| C[Canonical model ID]
B -->|no match| C
C --> D{Has antigravity- prefix?}
D -->|yes| E{Gemini 3.x family?}
D -->|no| F[resolveModelWithTier — gemini-cli / default path]
E -->|GEMINI_3_PRO_REGEX| G[Append -low if no tier]
E -->|GEMINI_3_FLASH_REGEX| H[Strip tier, keep bare name]
E -->|GEMINI_35_FLASH_REGEX| I[Force -low suffix]
E -->|other| J[Pass through]
G --> K[actualModel]
H --> K
I --> K
J --> K
F --> K
K --> L{Variant config thinkingBudget?}
L -->|yes + GEMINI_3_NOT_35_REGEX needed| M[Map budget to thinkingLevel]
L -->|yes + OLD includes check| N[Gemini 3.5 incorrectly gets thinkingLevel]
L -->|no| O[Return ResolvedModel]
M --> O
N --> O
|
| export const ANTIGRAVITY_ENDPOINT_DAILY = "https://daily-cloudcode-pa.sandbox.googleapis.com"; | ||
| export const ANTIGRAVITY_ENDPOINT_AUTOPUSH = "https://autopush-cloudcode-pa.sandbox.googleapis.com"; |
There was a problem hiding this comment.
Deprecated sandbox exports lack
@deprecated JSDoc
ANTIGRAVITY_ENDPOINT_DAILY and ANTIGRAVITY_ENDPOINT_AUTOPUSH are now excluded from all fallback chains, and the comment explicitly says the sandbox endpoint has been deprecated. Without a @deprecated tag, tooling and future contributors won't get any signal that these exports should not be used in new code — especially since ANTIGRAVITY_ENDPOINT_DAILY has the same "daily" naming as the new ANTIGRAVITY_ENDPOINT_DAILY_NONSANDBOX, making them easy to confuse.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/constants.ts
Line: 34-35
Comment:
**Deprecated sandbox exports lack `@deprecated` JSDoc**
`ANTIGRAVITY_ENDPOINT_DAILY` and `ANTIGRAVITY_ENDPOINT_AUTOPUSH` are now excluded from all fallback chains, and the comment explicitly says the sandbox endpoint has been deprecated. Without a `@deprecated` tag, tooling and future contributors won't get any signal that these exports should not be used in new code — especially since `ANTIGRAVITY_ENDPOINT_DAILY` has the same "daily" naming as the new `ANTIGRAVITY_ENDPOINT_DAILY_NONSANDBOX`, making them easy to confuse.
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bdf5f247f3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const isGemini3 = GEMINI_3_NOT_35_REGEX.test(lower); | ||
|
|
||
| if (!isGemini3) { | ||
| return resolveModelWithTier(requestedModel); | ||
| return resolveModelWithTier(normalizedModel); |
There was a problem hiding this comment.
Handle Gemini 3.5 Flash in Antigravity routing
When a user selects the newly exposed gemini-3.5-flash model with the default cli_first: false, getHeaderStyleFromUrl() chooses Antigravity quota, then this check classifies 3.5 as non-Gemini-3 and returns resolveModelWithTier() without the Antigravity transform. Since the -low suffix is only appended inside the explicit antigravity- path, the request is sent as gemini-3.5-flash even though the new comment says only the -low quota row is live; this breaks the default path for the new model unless users pick the prefixed antigravity-gemini-3.5-flash-low ID or enable CLI-first.
Useful? React with 👍 / 👎.
Fixes #578, #572, #573. Based on PR #575 by @Daltonganger. Adds antigravity-gemini-3.5-flash-low model definition, isGemini35FlashModel() resolver, and openid scope. Fixed endpoint fallback order to daily-cloudcode-pa first (matches official agy CLI).