Google releases Gemini 3.7 Flash three weeks after 3.6, with halved introductory pricing
Rapid point releases and time-boxed pricing show how model vendors now compete on iteration speed as much as raw capability.
Google on 13 August released Gemini 3.7 Flash, which it positions as its workhorse model for coding and agent workloads and describes as its most capable Flash-class release yet for those tasks. The launch comes three weeks after Gemini 3.6 Flash, and the company says the new version folds in developer feedback along with algorithmic changes aimed at software engineering, knowledge work and web development.
Google published a set of comparisons against the previous Flash model. On FrontierCode 1.1 Main the new model scores 43.6% versus 34.4%; on DeepSWE v1.1 it reaches 65.3% against 49.0%. Its WebDev Arena Elo rating rises to 1588 from 1538. On GDP.pdf it scores 34.0% compared with 22.0%, and on AutomationBench 30.4% versus 17.0%. The company also cites gains in multi-step planning, document comprehension and adherence to UI design instructions, along with strengthened safeguards in the CBRN and cyber-offence domains.
Pricing is time-boxed. Through 31 December 2026 the model costs $0.75 per million input tokens and $3.75 per million output tokens, which Google describes as half the price of 3.6 Flash. From 1 January 2027 standard pricing rises to $1.50 and $7.50 respectively.
Availability spans developer and enterprise channels. Developers can reach the model through Google AI Studio and Android Studio, while enterprises get it in the Gemini Enterprise Agent Platform and the Gemini Enterprise app. Consumers with AI Pro or Ultra subscriptions gain access through Gemini Spark in more than 160 countries, though the European Economic Area, the United Kingdom, Switzerland and Nigeria are excluded at launch.
Why it matters
A three-week gap between point releases signals that frontier labs now ship at a cadence closer to web software than research. The benchmarks Google chose are all agentic or repository-scale tasks, showing where it thinks buyers are looking. Time-limited pricing is a customer-acquisition lever borrowed from cloud services, and it makes total cost of ownership a moving target. Regional exclusions show regulatory posture now shapes who gets a model first.
A three-week gap between point releases signals that frontier labs now ship at a cadence closer to web software than research.
- FrontierCode 1.1 Main43.6% (from 34.4%)
- DeepSWE v1.165.3% (from 49.0%)
- GDP.pdf34.0% (from 22.0%)
- AutomationBench30.4% (from 17.0%)
Figures: Figures published by Google in its launch post
What you can learn from this
- What agentic coding benchmarks measure. Older code benchmarks asked a model to complete a single function. Suites in the style of DeepSWE or FrontierCode instead hand the model a real repository and an issue, then check whether its patch passes hidden tests. Success depends on reading unfamiliar code, planning several edits, running tools and recovering from errors, which is why scores are far lower than on function-level tests. The gap between models on these suites is a better proxy for usefulness inside an IDE than any single-shot leaderboard.
- Elo ratings for model comparison. WebDev Arena and similar leaderboards show two anonymous model outputs to a human, record which one wins, and update a rating using the same Elo system chess uses. Ratings are relative, so a 50-point rise means the model now wins noticeably more head-to-head matchups, not that it is 50 units better in some absolute sense. Because the judges are humans with preferences, Elo can reward style and polish as much as correctness, and a rating built on a few hundred votes moves easily. Read it alongside test-based benchmarks rather than instead of them.
- Token pricing and the input/output asymmetry. API models charge separately for input tokens (your prompt and context) and output tokens (the reply). Output is priced higher because generating each token requires a full forward pass while input can be processed in parallel. Agent workloads are input-heavy, since every tool result flows back into context, so input price often dominates their bill. Estimating cost therefore means measuring your actual token mix, not multiplying a single rate.
- Introductory pricing as a strategy. Cutting price for a fixed period lets a vendor win workloads that then become expensive to move, since prompts, evaluations and integrations are tuned to one model's behaviour. It also generates usage data and feedback before the standard rate applies. For buyers, the mechanism behaves like a promotional cloud credit: valuable, but only if the architecture can switch providers when the rate changes. Abstracting the model call behind an interface keeps that option open.
- Model tiers and the Flash designation. Vendors ship families where a smaller, faster tier trades some capability for lower latency and cost, and a larger tier serves the hardest problems. Flash-class models typically use fewer parameters or aggressive distillation from a bigger sibling, which is why they can be improved rapidly and priced low. Distillation trains the small model to mimic the large one's outputs, transferring much of the capability at a fraction of the inference cost. The practical question is not which tier is best but which tasks each tier can handle at acceptable accuracy. Routing easy requests to the cheap tier is where most savings come from.
We teach this
How to use this in practice
- Build a cost model for one workload. Take an existing prompt you run regularly, log its input and output token counts for ten runs using the API's usage fields, and put the averages into a spreadsheet with both the introductory and standard rates for this model. Add a column for monthly volume and a second scenario where the workload doubles. Done means two totals, one for 2026 and one for 2027, that you can defend line by line, plus a note on which term dominates the bill.
- Run a head-to-head on your own task. In Google AI Studio, give the new model and its predecessor the same three coding prompts drawn from your own codebase, keeping temperature and system instructions identical. Save each response, record how long it took, and check whether the code compiles or the tests pass. Done means a three-row table with pass or fail for each model and a note on any difference in approach, such as one model adding tests unprompted.
- Write a five-case eval harness. Create a small script that loads five prompts with expected answers from a JSON file, calls a model, and scores each response with a simple check such as exact match or a regular expression. Print a summary line with the model name and score, append it to a dated CSV so runs can be compared over time, and commit the script so it can run against any model name. Done means you can swap the model identifier and get a score in under a minute.
- Wrap the model call in an interface. Refactor one place in a personal project where a model is called directly so that it goes through a single function that takes a provider and model name as parameters, reads them from configuration, and logs token usage on every call. Done means switching models is a one-line configuration change, nothing else in the codebase references a specific model string, and you have usage numbers to feed the cost model above.
Sources
- Introducing Gemini 3.7 Flash — Google
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report