Client or integration
Codex CLI
Provider or upstream service
Google Gemini API / AI Studio
OpenCodex version
2.41.0 installed. I also checked the v2.46.0 tagged source.
Endpoint or capability
Model discovery: GET https://generativelanguage.googleapis.com/v1beta/models?pageSize=1000
Current behaviour
Every catalog sync reports Google discovery as malformed even though the API returns HTTP 200. OpenCodex then falls back to the configured static catalog:
[opencodex] Provider model discovery for "google" returned malformed 2xx data [status=200, contentType=application/json, urlClass=provider-models, fallback=configured].
The provider connection test accepts the same response and reports 54 available models. Authoritative catalog discovery does not: it accepts only a top-level array or data[], while Google AI Studio returns models[]. The result is a split behavior where the same response proves connectivity but cannot update the catalog.
Expected behaviour
For Google AI Studio, OpenCodex should treat the native models[] response as an authoritative catalog source. I would expect it to strip the models/ prefix from name, filter to rows that support generateContent, and use fields such as inputTokenLimit and outputTokenLimit for catalog metadata.
Vertex and Cloud Code Assist can keep their current discovery behavior. If authoritative parsing is intentionally out of scope, the connection test and sync logs should use the same vocabulary and status so the provider is not shown as connected while discovery calls its successful response malformed.
Minimal redacted request or reproduction
export GEMINI_API_KEY='<redacted>'
curl -sS -D - \
-H "x-goog-api-key: $GEMINI_API_KEY" \
'https://generativelanguage.googleapis.com/v1beta/models?pageSize=1000'
ocx sync
ocx provider test google --json
ocx models live --provider google --json
Actual response or error
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
{
"models": [
{
"name": "models/gemini-2.5-flash",
"inputTokenLimit": "<redacted>",
"outputTokenLimit": "<redacted>",
"supportedGenerationMethods": [
"generateContent",
"countTokens"
]
}
]
}
The response had one top-level property, models, and 54 rows. The first row exposed name, token limits, supportedGenerationMethods, and display metadata. I removed values and nonessential fields.
Upstream documentation
https://ai.google.dev/api/models
Suggested mapping or implementation notes
The connection-test path already reads models[] for a count, so it may be possible to share a Google-specific normalization step with catalog discovery. The mapping should be scoped to AI Studio mode so Vertex and Antigravity keep their existing parsers.
Additional context and attachments
Closed PR #55 described this exact response-shape mismatch, and the maintainer comment said the stabilization branch handled models[], response parsing, context hints, and pageSize=1000. I still see the authoritative catalog reject that envelope in v2.46.0 source. Related catalog-discovery work is #406 and #652.
Checks
Client or integration
Codex CLI
Provider or upstream service
Google Gemini API / AI Studio
OpenCodex version
2.41.0 installed. I also checked the v2.46.0 tagged source.
Endpoint or capability
Model discovery:
GET https://generativelanguage.googleapis.com/v1beta/models?pageSize=1000Current behaviour
Every catalog sync reports Google discovery as malformed even though the API returns HTTP 200. OpenCodex then falls back to the configured static catalog:
The provider connection test accepts the same response and reports 54 available models. Authoritative catalog discovery does not: it accepts only a top-level array or
data[], while Google AI Studio returnsmodels[]. The result is a split behavior where the same response proves connectivity but cannot update the catalog.Expected behaviour
For Google AI Studio, OpenCodex should treat the native
models[]response as an authoritative catalog source. I would expect it to strip themodels/prefix fromname, filter to rows that supportgenerateContent, and use fields such asinputTokenLimitandoutputTokenLimitfor catalog metadata.Vertex and Cloud Code Assist can keep their current discovery behavior. If authoritative parsing is intentionally out of scope, the connection test and sync logs should use the same vocabulary and status so the provider is not shown as connected while discovery calls its successful response malformed.
Minimal redacted request or reproduction
Actual response or error
The response had one top-level property,
models, and 54 rows. The first row exposedname, token limits,supportedGenerationMethods, and display metadata. I removed values and nonessential fields.Upstream documentation
https://ai.google.dev/api/models
Suggested mapping or implementation notes
The connection-test path already reads
models[]for a count, so it may be possible to share a Google-specific normalization step with catalog discovery. The mapping should be scoped to AI Studio mode so Vertex and Antigravity keep their existing parsers.Additional context and attachments
Closed PR #55 described this exact response-shape mismatch, and the maintainer comment said the stabilization branch handled
models[], response parsing, context hints, andpageSize=1000. I still see the authoritative catalog reject that envelope in v2.46.0 source. Related catalog-discovery work is #406 and #652.Checks