Google Gemini 3.7 Flash is incorrectly rewritten to nonexistent -tiered model ID

[RainbowDashy]

Client or integration

Codex App

Provider or upstream service

Google Gemini API / AI Studio

OpenCodex version

2.22.0

Endpoint or capability

/v1/responses → Gemini streamGenerateContent

Current behaviour

Selecting google/gemini-3.7-flash returns HTTP 404.

OpenCodex rewrites the valid model ID:

gemini-3.7-flash → gemini-3.7-flash-tiered

This mapping currently exists in src/adapters/google.ts:

const GEMINI_DIRECT_WIRE_RENAMES: Record<string, string> = {
  "gemini-3.7-flash": "gemini-3.7-flash-tiered",
  "gemini-3.6-flash": "gemini-3.6-flash-tiered",
};

The authenticated Gemini Models API confirms:

• models/gemini-3.7-flash returns HTTP 200.
• models/gemini-3.7-flash-tiered returns HTTP 404 with:
  Model is not found: models/gemini-3.7-flash-tiered for api version v1beta

Consequently, requests routed through OpenCodex fail with http_404.

Expected behaviour

OpenCodex should send gemini-3.7-flash unchanged to the Gemini API, matching Google's documented model code and the model returned by models.list.

Minimal redacted request or reproduction

# Confirm the documented model exists
curl \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash
# HTTP 200

# Confirm the OpenCodex-rewritten model does not exist
curl \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash-tiered
# HTTP 404

# Reproduce through OpenCodex
codex exec \
  --skip-git-repo-check \
  -m google/gemini-3.7-flash \
  "Reply only OK"
# HTTP 404 / http_404

Actual response or error

Model is not found: models/gemini-3.7-flash-tiered for api version v1beta

OpenCodex request history reports:

provider: google
model: gemini-3.7-flash
status: 404
errorCode: http_404

Upstream documentation

https://ai.google.dev/gemini-api/docs/models/gemini-3.7-flash

Suggested mapping or implementation notes

Remove the gemini-3.7-flash entry from GEMINI_DIRECT_WIRE_RENAMES, allowing the direct Gemini adapter to use the documented model ID unchanged.

A local test with that single mapping removed resolves the incorrect endpoint selection.

Additional context

• OS: macOS 15.7.7
• The API key is valid and can retrieve models/gemini-3.7-flash.
• The same stale rewrite is present on the current main branch.
• Existing provider-compatibility issues were searched; no duplicate was found.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or concrete client requirement.

[RainbowDashy]

#1739 seems to fix this issue

[lidge-jun]

Fixed on dev in #1921 (merge 9dbc5fc42), which lands #1739.

What was actually wrong. Your capture and the one behind commit a70bb78d4
disagree, and both are correct. That commit was written from a live account where
gemini-3.7-flash returned 404 and gemini-3.7-flash-tiered returned 200; your
account returns exactly the inverse, with models.list carrying no -tiered row
at all. So the rename is a per-deployment fact, not a universal one — which means
the bug was not the mapping's direction but that it was unconditional. Whichever
spelling is hardcoded, one population gets a 404.

What shipped. A provider-level setting rather than a new guess:

{
  "providers": {
    "google": {
      "directGeminiWireRenames": false
    }
  }
}

Omitted or true keeps the -tiered rewrite for the deployments that need it;
false sends the requested id to the wire unchanged, which is what your account
wants. Vertex keeps the requested model identity and Cloud Code Assist routing is
untouched. The default is unchanged, so you will need to set this explicitly
after the release containing it — closing this issue without saying so would leave
you exactly where you started.

A second defect surfaced while fixing this one: the -tiered spelling was leaking
into the system identity, so the model was being told it was
gemini-3.7-flash-tiered. The wire id and the identity are now separate.

Verification. bun run typecheck, bun run privacy:scan, and the full suite
(12747 pass, 10 skip, 0 fail across 823 files) green on the merged tree; focused
regressions in tests/google-adapter.test.ts and tests/config.test.ts cover the
default, the opt-out, the persisted round-trip, and the identity line.

Closing as completed. This is on dev and not yet in a published release — it will
ship in the next one after v2.24.2.