[XUANZERA]

Summary

Add opt-in -search model aliases for models that support Google Search.

For example:

• gemini-3.8-flash → unchanged
• gemini-3.8-flash-search → resolves to gemini-3.8-flash with Google Search enabled

This allows clients that support Gemini-compatible APIs but do not send the native googleSearch tool to still use AIStudio2API's existing Google Search capability.

Motivation

Some third-party clients can connect to AIStudio2API through the Gemini API, but do not include Gemini's provider-native Google Search tool in the request.

In that case the incoming request contains no Search tool, so AIStudio2API correctly treats it as a normal generation request.

AIStudio2API's existing Google Search implementation already works when googleSearch is explicitly supplied.

This PR adds an opt-in compatibility mechanism without changing the behavior of existing model IDs.

Behavior

A request using:

gemini-3.8-flash-search

is internally resolved to:

gemini-3.8-flash

and Google Search is enabled through the existing GoogleSearchOptions path.

The upstream AI Studio request still uses the canonical model ID.

Normal models remain unchanged:

gemini-3.8-flash

does not automatically enable Search.

Model catalog

For eligible models that support Google Search and generateContent, an additional -search alias is exposed.

Example:

gemini-3.8-flash
gemini-3.8-flash-search

The alias inherits the base model metadata and capabilities.

Implementation

Search aliases are resolved before generation and tool capability validation.

The injected Search option continues through the existing pipeline:

GoogleSearchOptions
→ validateRequestedTools
→ encodeRequestedTools
→ encodeSearchTool
→ AI Studio

Existing tools are preserved when Search is injected.

Compatibility

This PR does not change:

• the existing Google Search wire encoding
• WAA handling
• grounding decoding
• normal model behavior
• requests that already provide Google Search
• unsupported model capability validation

The feature is only enabled when a -search model alias is explicitly requested.

API support

The shared alias resolution path supports:

• Gemini generateContent
• Gemini streamGenerateContent
• OpenAI Chat Completions
• Responses API

Tests

Added coverage for:

• Search alias resolution
• normal model behavior
• automatic Google Search injection
• preserving existing tools
• avoiding duplicate Search tools
• canonical upstream model resolution
• model catalog alias generation
• unsupported model validation
• Gemini streaming requests

Validation performed with:

go test ./internal/api ./internal/aistudio
go test ./...
git diff --check

All tests pass.

[Mag1cFall]

Thanks so much for this. We'd rather not add -search model aliases for now, so we won't merge it yet, but we'll keep it open.

What we did instead: the service now recognizes the search fields clients already send — web_search_options in OpenAI Chat, the web_search server tool in Anthropic Messages, and googleSearch in Gemini requests (fb87416). That covers clients that expose a web search option without adding model IDs. An alias would add a second catalog entry for every search-capable model, and the model list is built from each account's live upstream catalog.

The case your PR targets, clients that can't send any search field at all, isn't covered yet. If you can tell us which client you're using, we'll look at its actual requests and decide whether an alias or another mechanism fits best. This PR stays open as the reference for that.

[XUANZERA]

Sorry 4 the delay, quite busy recently.

I went with the -search alias approach precisely cause third-party client support 4 native search payloads's inconsistent across the ecosystem.

Glad 2 see this landed and helped resolve issues, thx 4 merging.