Google releases three new Gemini models — but no 3.5 Pro

Three model launches would normally signal a broad platform upgrade. The more important detail in Google’s latest Gemini release, however, is the model that did not appear: Gemini 3.5 Pro.

That omission matters because developers do not experience model releases as a list of product names. We experience them as migration decisions: whether to change a production model ID, rerun evaluations, revise token budgets, and accept new latency or reliability characteristics. Three new options create more routes through Google’s stack, but without a 3.5 Pro release, they do not automatically provide a new top-end replacement for demanding Gemini 3 workloads.

The announcement is therefore less about a new flagship and more about portfolio expansion. For API teams, that can still be valuable, particularly when most requests do not require the largest available model.

What Google Announced

Google released three new members of the Gemini family while leaving Gemini 3.5 Pro out of the launch.

That distinction is the central confirmed fact. It is tempting to treat any batch of new models as evidence that the entire generation has advanced, but model families rarely move in lockstep. Providers increasingly update individual price, speed, reasoning, and deployment tiers independently.

In practical terms, developers should read this release as:

• Three additional Gemini deployment choices are now entering the market.
• There is no announced Gemini 3.5 Pro endpoint to serve as an obvious flagship upgrade.
• Existing Gemini 3 applications should not assume a drop-in successor exists.
• The new models need to be evaluated individually, not as interchangeable members of one generation.
• Context limits, regional availability, rate limits, tool support, and stable API identifiers must be verified from the live model metadata before production use.

That last point is not administrative trivia. In practice, launch-day model access can differ across a provider’s consumer application, first-party developer console, managed cloud platform, and regional endpoints. A model appearing in a chat interface does not prove that it supports structured output, function calling, batch jobs, or the same context window through every API surface.

Why No 3.5 Pro Is the Real Story

“Pro” models usually carry an implicit contract: use this tier when output quality and task complexity matter more than the lowest possible cost or latency. Teams build routing policies around that contract even when providers do not guarantee identical behavior between generations.

Without Gemini 3.5 Pro, Google has not given those teams a clean answer to a common migration question:

What should replace Gemini 3 for the hardest requests?

The answer may still be one of the new models, but that must be demonstrated through evaluation. A newer name is not evidence of better performance on a specific workload.

This is particularly important for tasks such as:

• Repository-scale code modification
• Long-document synthesis with cross-references
• Multi-step tool use
• Schema-constrained data extraction
• Agent planning over many turns
• Analysis where a plausible but unsupported answer is expensive

A faster model can be a major improvement for classification or autocomplete while being a regression for a 40-step tool workflow. Conversely, a high-end reasoning model can waste money when the request is simply “extract these five fields from an invoice.”

The absence of 3.5 Pro also suggests that Google is comfortable shipping the family in stages. That is not inherently a weakness. It does mean engineering teams should separate release excitement from production planning.

How the Competitive Field Looks

The current market cannot be reduced to one universal leaderboard. Claude gpt-5.6-sol, Sonnet 4.6, Haiku 4.5, Fable 5, GPT-5.5, and Gemini 3 target overlapping but nonidentical requirements. Fable 5’s advertised 1 million-token context is a concrete architectural differentiator, for example, but context capacity alone does not establish retrieval accuracy across that entire window.

I would not assign numeric winners without running the actual workload. Model versions, inference settings, and API features change too quickly, while public aggregate scores often conceal the failure modes that matter in production.

A customer-support system, for example, may value a 99.9% valid-JSON rate more than a small improvement on a reasoning test. A coding agent may care about correct patches per tool call rather than correctness on isolated programming questions.

The API Impact Is Mostly Operational

Every new model creates operational work even if no application ultimately migrates.

First, model identifiers need to be isolated from business logic. Do not scatter a provider’s launch name across the codebase. Put it in configuration and record the resolved model in telemetry.

import os
import time

MODEL = os.environ.get("PRIMARY_MODEL", "gemini-3")

def run_request(client, messages):
    started = time.perf_counter()
    response = client.responses.create(
        model=MODEL,
        input=messages,
        temperature=0,
    )

    return {
        "text": response.output_text,
        "model": MODEL,
        "latency_ms": round((time.perf_counter() - started) * 1000),
        "input_tokens": response.usage.input_tokens,
        "output_tokens": response.usage.output_tokens,
    }

Second, routing should be based on measured task complexity rather than a blanket migration:

{
  "routes": {
    "classification": "fast-model",
    "structured_extraction": "balanced-model",
    "repository_patch": "high-capability-model",
    "long_document_review": "long-context-model"
  },
  "fallback": "gemini-3"
}

A common gotcha is evaluating only successful responses. If the new endpoint returns more rate-limit errors, malformed tool arguments, or safety refusals, its apparent quality on completed requests can hide a worse production success rate.

Track at least:

• End-to-end success rate
• Valid structured-output rate
• Tool-call completion rate
• Input and output tokens
• Median and p95 latency
• Retries and fallback frequency
• Human correction rate
• Cost per completed task

Do the Pricing Math Per Task

Model pricing is not useful in isolation. The relevant number is cost per successful task, including retries and verbose outputs.

Suppose a workload averages 18,000 input tokens and 2,000 output tokens. Assume, purely for illustration, that one endpoint costs $2 per million input tokens and $8 per million output tokens:

Input:  18,000 / 1,000,000 × $2 = $0.036
Output:  2,000 / 1,000,000 × $8 = $0.016
Total per attempt                     = $0.052

At 400,000 requests per month, the nominal bill is:

400,000 × $0.052 = $20,800 per month

Now include a 7% retry rate:

$20,800 × 1.07 = $22,256 per month

If another model costs 20% more per token but cuts retries and output length substantially, it can still be cheaper per completed task. The reverse is also true: a low token price is irrelevant if weak instruction following forces a second pass through a stronger model.

Teams that want to test several providers without opening separate billing relationships can use AI Prime Tech for cheaper Claude and multi-model API access. The engineering requirement remains the same: log provider, model, usage, and retry costs separately so aggregation does not obscure actual economics.

A Migration Process That Produces Evidence

Start with a frozen evaluation set drawn from production, not a collection of polished demo prompts. Fifty carefully selected cases can reveal more than thousands of synthetic questions if they include the failures your users actually encounter.

1. Define task-level acceptance criteria

For extraction, validate the JSON against a schema. For code generation, run tests. For support answers, check policy compliance and citation correctness. Avoid a single subjective score when deterministic checks are available.

2. Run the incumbent and candidate side by side

Use identical prompts and equivalent generation settings where the APIs permit it:

python eval.py \
  --baseline gemini-3 \
  --candidate NEW_GEMINI_MODEL_ID \
  --dataset evals/production_cases.jsonl \
  --concurrency 8

Pin the exact candidate identifier in the evaluation record. Aliases can move, which makes later comparisons difficult to reproduce.

3. Inspect regressions, not just averages

A candidate that improves 80 easy cases and breaks five high-value workflows may be a net regression. Group results by task type, input length, tool count, language, and customer impact.

4. Canary the winning route

Send 1% to 5% of eligible production traffic to the new model. Keep Gemini 3 or another proven endpoint available as a fallback until latency, errors, and output quality remain stable under real load.

Practical Takeaways

• Treat this as a three-model portfolio expansion, not a Gemini 3.5 Pro migration event.
• Keep Gemini 3 in place for critical workloads until a candidate passes task-specific evaluations.
• Verify live API details such as model IDs, context limits, pricing, regions, quotas, tools, and structured output.
• Compare the new Gemini options against Sonnet 4.6, Haiku 4.5, Claude gpt-5.6-sol, Fable 5, GPT-5.5, and Gemini 3 using production-derived cases.
• Calculate cost per successful task, including output length, retries, and fallback calls.
• Route simple and difficult requests separately; three new models are most useful when they create better routes, not when they trigger a blanket upgrade.
• Preserve rollback capability. Until 3.5 Pro arrives and proves itself, the best flagship for a given application may still come from the previous Gemini generation or another provider entirely.