Provider routing
Gemini Interactions proxy for stored 3.x model calls
Route two registered Gemini 3.x models through stored Interactions with provider-configured visibility retries, cleanup, and one blocking proxy request.
Developers adding Gemini as a provider without bringing Gemini-specific payloads into every app.
The problem
Stored Gemini Interactions require polling and cleanup, which shared proxy callers must not have to coordinate.
How LLM Proxy helps
LLM Proxy polls and cleans up registered Gemini 3.x resources while callers keep one blocking request.
How it works
- Keep the Gemini transport and offerings in providers.yml. Create a Gemini connection and connect the tenant.
- Select provider=gemini or set Gemini as a tenant default.
- Send canonical messages through /v2 or compatibility text requests.
- Keep max_tokens within configured Gemini output limits.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Native adapter | The backend maps user messages into Gemini interaction steps. | System instructions use Gemini's system_instruction shape, and assistant history is invalid. |
| Resource lifecycle | The proxy polls queued and in-progress Gemini 3.x interactions server-side. | Active resources are cancelled and every stored interaction is deleted on exit. |
| Tenant defaults | Omitted model uses the tenant's saved Gemini text model. | Client code can omit the model while tenant settings remain authoritative. |
| Output limit contract | Gemini max_tokens values above configured limits return 400 before upstream calls. | An incomplete interaction returns a provider error without replay. |
Use-case examples
Gemini summary
A service sends provider=gemini and omits model to use the configured default.
Long user input
A /v2 request routes user messages through Gemini without a Gemini SDK.
Limit check
A caller sets max_tokens inside the configured Gemini limit.
Objections and limitations
- Gemini dictation is not exposed through /dictate in this repo.
- Web search is not marked supported for Gemini in the current proxy catalog.
- Each Gemini Interactions route rejects assistant history.
- The Gemini model list must be maintained in providers.yml.
Repository evidence
resource_visibility:
retry_interval_milliseconds: 5000
retry_limit: 6
retry_status_codes:
- 400
- 403
- 404Verified 2026-09-10 by Tyemirov on GitHub against configs/providers.yml.
FAQ
Which Gemini models does this route register?
The catalog registers Gemini 3.5 Flash and Gemini 3 Flash Preview.
Can a Gemini request contain assistant history?
No. Each Gemini Interactions route rejects an assistant message before it sends an upstream request.
What happens when Gemini returns an incomplete interaction?
The proxy cleans up the stored interaction and returns a provider error. It does not replay the partial output.
How does the proxy handle delayed Gemini resource visibility?
The Gemini transport declares six retries at five-second intervals for HTTP 400, 403, and 404 responses after creation.
What should I read next?
A closely related resource is Integrate once through one multi-provider LLM proxy, which covers multi-provider LLM proxy.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference