Repository navigation
google-antigravity provider cannot use gemini-3.7-flash (adapter speaks /v1beta, gateway has it only on /v1internal Code Assist surface) #1906
Description
Client or integration
Direct HTTP/API client
Area
Google Antigravity provider adapter
Summary
google-antigravity provider cannot use gemini-3.7-flash. The adapter speaks /v1beta/models/{id}:generateContent, but the model exists only on the /v1internal:loadCodeAssist Code Assist surface (the one agy uses). Result: 404 Requested entity was not found when the model is set as the provider's default, and 400 "not supported when using Codex with a ChatGPT account" when requested by name (router sends it to the wrong provider because it isn't matched to antigravity).
Reproduction
ocx provider edit google-antigravity --default-model gemini-3.7-flashcurl -X POST http://127.0.0.1:10100/v1/chat/completions -d '{"model":"gemini-3.7-flash","messages":[{"role":"user","content":"hi"}]}'- Observe
404 Requested entity was not found(upstream gateway: model only on the Code Assist surface). - Alternatively request
gemini-3.7-flashby name with the antigravity default restored to gemini-3.6-flash: the router matches no antigravity pattern and sends the request to the ChatGPT pool →400 model is not supported when using Codex with a ChatGPT account.
Expected behavior
gemini-3.7-flash routes to google-antigravity and completes (same as agy native, where the model id is gemini-3.7-flash-high).
Version
opencodex 2.11.0
Operating system
macOS
Provider and model
google-antigravity / gemini-3.7-flash
Logs or error output
404: Requested entity was not found (v1beta path); 400: The 'gemini-3.7-flash' model is not supported when using Codex with a ChatGPT account (router fallback to ChatGPT pool).
Screenshots and supporting files
n/a
Redacted configuration
n/a
Checks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
Activity
github-actions commentedon Aug 17, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
docs(devlog): plan WP8 from a simulated merge, not a prediction
lidge-jun commentedon Aug 18, 2026
Fixed on current
dev. The report was filed against 2.11.0; the adapter no longer speaks/v1betafor this path — google-antigravity now routes through the CCA/v1internalCode Assist surface (src/adapters/google.ts:451), andgemini-3.7-flashis present in the catalog seed (src/providers/registry.ts:1464,src/providers/antigravity-models.ts:16-23). This will reachlatestwith the v2.25.0 release. If a live CCA request still fails ondevor on 2.25.0 once published, please reopen with the request capture.docs(devlog): plan WP8 from a simulated merge, not a prediction
vibewriter-hand commentedon Oct 25, 2026
Area
Provider adapters
What are you trying to accomplish?
Allow a user with an authorized local agy installation to choose that CLI as an explicit subprocess route, while the CLI owns authentication and session storage.
Proposed validation, not executed:
What prevents this today?
This thread describes a concrete difference between the proxy route and the surface used by agy. Related #1897 reports comparing
agy modelswith OpenCodex discovery and retaining live catalog identities. Those are useful evidence for the CLI/catalog boundary, but neither report establishes an opt-in subprocess provider contract.I have not reproduced this historical bug on current OpenCodex and do not request reopening it. This comment records the related workflow here instead of creating another Antigravity issue.
What should OpenCodex do?
Consider or document an opt-in route that invokes the user's existing authorized CLI, keeps tokens inside its owner, preserves provider selection, and reports process exit, cancellation and supported model/effort results. Do not add credential extraction, client impersonation or silent fallback.
Example usage or interface
Illustrative workflow, not an existing configuration syntax: choose "local agy CLI" as the provider, choose a model advertised by that CLI, submit a prompt, and return the CLI result or a visible failure. A Claude-named model on this provider must remain on the explicitly selected provider.
Alternatives or workarounds
Invoke the existing authorized CLI directly. The direct proxy adapter and catalog improvements in #1897 are related alternatives; this proposal makes no claim that their current implementation is defective.
Additional context
Google-account suspension is a risk concern motivating this request. No causal incident, policy approval, official-client status or guarantee against suspension is asserted. Authorization compatibility needs primary-source confirmation before implementation.
Validation: NOTRUN. No provider call, login, account operation or implementation test was performed for this proposal. Sources read: this issue and #1897.
Checks
Ingwannu commentedon Oct 25, 2026
This is a distinct opt-in local-CLI proposal, not evidence to reopen the historical adapter bug. Please put follow-up implementation discussion in a new feature-request form and link this thread plus #1897, so its subprocess/lifecycle contract can be assessed independently.
The requested boundaries are clear: explicit provider selection, CLI-owned authentication, bounded exit/cancellation and no implicit provider fallback. Primary-source authorization and supported machine-readable CLI/model/effort contracts remain prerequisites; a local authorized installation alone does not establish that integration contract. No CLI invocation, login, inference or implementation validation has been performed, and this issue remains closed.