Gemini 3.5 Flash: Finding the production fit
Gemini 3.5 Flash is a volume model: fast, multimodal, tuned for tool calls at a request rate where latency becomes an infrastructure cost. That's the constraint everything here works around, not the leaderboard slot. Save it for the request that shows up over and over and needs to come back quickly and cheaply; reach for something else when the problem is genuinely hard. Google lists it as a current stable release in the Gemini family and points new integrations at the GA Interactions API, and the identifier worth testing is gemini-3.5-flash. Check the live docs before shipping: aliases, prices and defaults move faster than any writeup of them.
Decide what done means before the first prompt
Fluency is not an acceptance criterion. A schema-valid extraction whose fields trace to the source is one. A patch that passes tests and survives review is another. A claim set where every claim has a traceable source is a third. Pick the unit that matches the job before the first test prompt: a confident wrong answer and a confident right one produce the same transcript until somebody checks. The useful test labels real requests by difficulty, latency target, context size and consequence, then compares how many get accepted, not how good they feel on the page. Keep the whole request while you do it: system instructions, tool schemas, files, sampling or reasoning settings, output limits. A model looks better or worse depending on whether the harness gives it native tool calling or pasted terminal output, so hold the workflow constant and let each provider use its own documented format.
What the log has to hold
None of this needs anything clever, just discipline about what gets recorded on every call.
| What you log | Why |
|---|---|
| Model ID and dated API version | Ties the result to a pinned target, not a moving alias |
| Prompt and tool-schema revision | Separates a model regression from a prompt regression |
| Input, cached input, reasoning, output tokens | The real cost breakdown, not the list price |
| Queue, first token, total completion time | Latency fails in more than one place |
| Task pass, retry, abstain, human repair | The outcome that matters, not how fluent it read |
| Provider error and fallback route | What happens the moment the call just fails |
Keep sensitive prompt content out of the default retention policy; the raw transcript rarely needs to survive once the run is scored.
The default nobody chose on purpose
The expensive mistake is letting Gemini 3.5 Flash, or whatever ships next quarter, become the universal default and paying its latency and price on transformations a smaller model would have finished just as well. Frontier-adjacent models make this hard to catch because almost every response reads as plausible; nothing about a wrong answer looks wrong on the page. Measure what ordinary code can check instead of trusting the read. Ask reviewers to name a concrete defect instead of describing a vibe. And keep the failures. A folder of rejected outputs is worth more than another folder that passed, because the failures define where routing rules and guardrails need to sit.
More context window doesn't buy you trust
A bigger window does not remove prefill time, retrieval noise, or the need to keep trusted instructions separate from an untrusted document that just got pasted in. Put the stable prefix first when the API supports caching, keep volatile metadata off the cache boundary, and skip the full history when a structured checkpoint says the same thing in far fewer tokens; the patterns in long-context workflows make this cheap once built. Output needs the same restraint: a short decision plus evidence beats an essay nobody asked for. Tool use raises a related risk. A better model may pick the right function more often, but the application still validates arguments, authorizes the caller, caps side effects, dedupes the request, and logs what happened, because a web page, a file, an email and a tool result are data, not authority. Capability is not a substitute for a narrower interface.
Keep two lanes and write the rule down
The durable move is giving this model a narrow default lane with an explicit, written escalation condition, set in configuration rather than left to whoever remembers which model was fashionable last month. Route routine, well-specified, high-volume work here. Send the strongest model only the requests that actually benefit from its extra capability; a cheap fast lane stops being cheap once retries and review outrun the inference bill it was meant to save. Treat version migration as ordinary operations work: pin dated versions where stability matters, watch deprecation notices instead of finding out from a broken production call, canary a new alias before it takes all traffic, and keep a known-good fallback ready. Re-run the evaluation set whenever the model, prompt, tool contract or reasoning default changes.
That means giving up a little headroom on purpose. Some requests labeled routine turn out harder than the label suggested, and they get the fast lane's answer instead of the flagship's, occasionally a worse one. I'd rather absorb that cost deliberately, written into the routing rule, than pay the flagship's latency and price on every routine call by default and call it caution.