Google subscription catalog advertises Gemini 3.x models that Code Assist returns 404 for

Summary

A self-hosted Manifest Google subscription connection advertises gemini-3.1-pro-preview and gemini-3-flash-preview, but direct requests to both models consistently fail through the Google Code Assist backend with HTTP 404:

{
  "error": {
    "message": "Model or endpoint not found",
    "type": "invalid_request_error",
    "status": 404,
    "source": "provider",
    "provider": "gemini",
    "model": "gemini-3.1-pro-preview"
  }
}

The problem reproduced on Manifest 6.16.0 and still reproduces after upgrading to the pinned manifestdotbuild/manifest:6.17.1 image.

Environment

• Manifest: self-hosted Docker image manifestdotbuild/manifest:6.17.1
• Previous affected version: 6.16.0
• Provider: Google subscription / OAuth (Code Assist backend)
• Manifest mode: self-hosted
• Database: PostgreSQL

No API keys, deployment URLs, account identifiers, or OAuth credentials are included here.

Steps to reproduce

1. Connect Google as a subscription provider through Manifest's OAuth flow.
2. Refresh/reconnect the Google subscription and refresh the provider model catalog.
3. Confirm that the catalog advertises:
   • gemini-3.1-pro-preview
   • gemini-3-flash-preview
4. Send a direct request to either advertised model:

curl "$MANIFEST_URL/v1/chat/completions" \
  -H "Authorization: Bearer $MANIFEST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.1-pro-preview",
    "messages": [{"role": "user", "content": "Reply exactly OK"}],
    "max_tokens": 20,
    "stream": false
  }'

1. Repeat with gemini-3-flash-preview.

Actual result

Both models repeatedly return HTTP 404 Model or endpoint not found from the Gemini provider.

Post-upgrade checks on 6.17.1:

Reauthorizing Google and refreshing the model catalog do not change the advertised list or the failure.

For comparison, subscription-backed OpenAI models in the same harness succeed immediately. Manifest's sequential fallback engine also works correctly when an unavailable Gemini model is followed by a working model. This isolates the issue to advertised Google Code Assist model availability rather than general routing or authentication.

Some Gemini 2.5 models initially succeeded and later returned HTTP 429, which appears to be a separate quota/rate-limit condition. The Gemini 3.x failures above are stable 404s.

Expected result

Manifest should not advertise a Google subscription model that the connected account's Code Assist endpoint cannot serve, or it should clearly mark that model as unverified/unavailable for that connection.

A direct request to an advertised model should either succeed or fail early with an actionable account/model-availability diagnostic instead of routing to a statically listed but unavailable ID.

Suggested approaches

Any of these would address the production problem:

1. Validate curated Google subscription model IDs against the connected Code Assist account before exposing them as available.
2. Gate preview IDs behind a successful lightweight probe and cache the result per connection.
3. Remove unavailable IDs from the active catalog after a deterministic provider 404, with a way to retry after refresh.
4. Distinguish the static candidate catalog from account-verified models in the API/dashboard.
5. Include the native Code Assist diagnostic body when available so users can distinguish stale IDs from permissions or quota failures.

Additional context

The curated Google subscription model list appears unchanged between the 6.16.0 and 6.17.1 source, so the 6.17.1 upgrade improves diagnostics and OAuth/fallback behavior but does not resolve this stale/account-specific catalog mismatch.

A similar failure mode has been reported in another Code Assist integration: OAuth succeeds, while Gemini 3.x requests return 404 Requested entity was not found.