Gemini 3.5 Flash: Long context without the token landfill
Bigger context windows are inventory, not a plan. Gemini 3.5 Flash gives you room to staple your whole knowledge base into one prompt, and that says nothing about whether doing so buys a better answer or just a pricier mistake.
What I can verify: Google lists 3.5 Flash as a current stable Gemini model, pointing new projects at the generally available Interactions API, a fast multimodal model for high-volume, tool-heavy work. Test against gemini-3.5-flash, and treat that string as perishable: aliases get renamed, prices move, check the docs before shipping.
Success first, corpus second
The instinct is to start from a leaderboard and work backward. Do the opposite. Start from your requests: deadlines, evidence needed, tools called, what a wrong answer costs. Only then ask if the model changes that math. Before the first prompt, write down what success looks like: a schema-valid record for extraction, a patch that passes tests and review for coding, a claim set a colleague could check for research. Fluency doesn't count.
The real test is boring: bucket prompts by length, drop known evidence at a few positions, and measure recall against full context, holding everything else identical: same system instructions (your GEMINI.md context), same tool schemas, same sampling settings. Skip that and you're comparing harnesses, not models. Log the model id and version, token counts by input, cached, reasoning, output, and the outcome: pass, retry, abstain, human repair.
Where those extra tokens actually go
The mistake I see most: treating the advertised maximum as an architecture instead of a limit you're allowed to approach. Stuff enough documents into one prompt and the fact you needed gets buried under near-duplicates, while the model answers with total confidence anyway, because it always does. Catch this by measuring what code can verify, having reviewers label concrete defects, and keeping the wrong outputs; they teach more about routing than a folder of clean successes.
Long context earns extra suspicion: capacity doesn't shrink prefill time, filter retrieval noise, or draw the line between instructions you trust and documents you don't. Cache the stable prefix first, keep volatile bits off the cache boundary, and send a structured checkpoint instead of full history when one will do; a short decision plus its evidence beats an essay nobody asked for.
Tool use raises the stakes further. A better model might pick the right function more often, but your application still validates arguments, confirms the caller, caps what one call can do, and logs it. A web page, a tool result: that's data, not an instruction it gets to follow.
Capacity is not permission to resend every document you have.
Put the rule in config, not in your head
The rule that survives production: retrieve the smallest evidence set that answers the question, and reach for the far end of the window only once a task has proven, with your own numbers, that it needs it. Write that into configuration, not tribal memory. Log model identity, phase timings, token categories, and eval results; skip hoarding sensitive prompt content by default.
Keep a cheap lane for routine work and a clear condition for escalating. The strongest model gets tasks that benefit from its reach, not everything the gateway routes, and a cheap tier stops being cheap once retries and review outrun what it saved on inference. Treat every swap as an operational event: pin dated versions, watch deprecation notices, canary new aliases before full traffic, keep a fallback one flag away. Re-run your eval set whenever the model, prompt, or tool contract shifts under you.
None of this crowns Gemini 3.5 Flash a permanent winner. It tells you what work it does reliably, what that costs, and where the router should hand off instead. Before touching a router config, run the bucket test against your ugliest long prompt and see where the facts go missing.