Gemini 3.5 Flash: The cost and latency worksheet

A team swaps in a cheaper-looking model and ships it once the eval dashboard turns green. Two weeks later finance asks why the 'savings' model costs more than the one it replaced: nobody logged the retries, and the cache was never seeded, so every call re-paid full input price. It happens almost every time a cheap-and-fast model lands, and Gemini 3.5 Flash will trigger it again for whoever skips the arithmetic.

Here's what's documented: Google lists Gemini 3.5 Flash as a current stable Gemini model, pointing new projects at the generally available Interactions API. It's fast and multimodal, built for high-volume tool-assisted work, not one hard reasoning problem, with gemini-3.5-flash the identifier worth pinning in config. Go re-check the current docs before shipping: prices and aliases move.

Price the whole request, not the sticker token

Decide what an accepted answer is before the first prompt; fluency isn't it. For extraction that's a schema-valid record whose fields trace to source evidence. For coding, a patch that passes tests and survives review. For research, a claim set where every claim has a source you can check.

Once you know what counts as a win, track this per workload class, not once for the product:

• model ID, dated API version, prompt and tool-schema revision
• cached vs uncached input, reasoning tokens, and visible output
• queue time, first token, total completion, p50 and p95
• pass rate, retry rate, abstain rate, human repair minutes
• provider errors and which fallback route absorbed them

Keep the whole request too: system instructions, tool schemas, files, sampling or reasoning settings, output limits. Drop any of it and the comparison stops meaning anything: a model looks different when one harness gets native tools and another gets pasted terminal output. Hold the workflow constant, let each provider use its own documented format.

The expensive mistake is comparing input-token list prices while outputs, cache writes, tool calls, and failed attempts run up the real bill. Frontier output looks plausible almost all the time, which is why it survives a demo. The bill is that list rate times volume, plus cache writes, tool calls, retries a flaky parse forces, and the minutes spent checking a plausible-but-wrong answer. Measure what code can verify, have reviewers label the rest with real defects, and keep the wrong answers: they're worth more than a folder of things that worked, because failures show where to route around the model.

Long context and tool calls both want supervision

Long context deserves active suspicion, especially if you're leaning on long-context workflows because a bigger window looked free. Capacity doesn't remove prefill time, retrieval noise, or the need to separate trusted instructions from whatever untrusted document got pasted in. Put stable prefixes first for caching, keep volatile metadata off the cache boundary, and skip full history when a checkpoint will do. Output wants the same restraint: a short decision plus evidence beats an essay nobody asked for.

Tool use rewrites the risk model too; better function selection from the provider doesn't change that. Your application still validates every argument, authorizes the caller, caps side effects, catches duplicate requests, and records what happened. A web page, a file, an email, a tool result: none of it is authority, it's just data the model read. A sharper model doesn't replace a narrower interface. That's the whole rule.

The decision that lasts is optimizing for verified work per dollar and second, not the cheapest token alone; put that rule in configuration, not whatever's fashionable this quarter. Log model identity, phase timings, token categories, tool outcomes, and evaluation results, without retaining sensitive prompt content by default. Keep a cheap, fast lane for routine work, a clear escalation trigger for the rest, and send your strongest model only the tasks that benefit from it. A cheap tier stops being cheap once its retries and review burden outrun what it saved.

Migration is just another operational change. Pin dated versions where stability matters, watch deprecation notices instead of finding out from an outage, canary a new alias before it touches all traffic, and keep a known-good fallback ready. Re-run the local evaluation set whenever the model, prompt, tool contract, or reasoning default changes, even when it looks small.

None of this crowns Gemini 3.5 Flash a permanent winner. It tells you which work the model finishes reliably, what that work costs once the whole receipt is added up, and when the router should reach for something else. The part I still haven't solved: turning a reviewer's five minutes into the same unit as a token bill. Everyone tracks API spend to the fraction of a cent and eyeballs the labor cost next to it. I haven't found a clean conversion, and I'm suspicious of anyone who says they have.