Gemini 3.8 Flash vs 3.7 Flash: A Coding Agent Test

What “a coding agent test” means here

A coding agent is not just a model answering a code question. It receives a repository, explores files, edits more than one location, runs commands, sees failures, changes its plan, and stops with a particular working-tree state. The test is therefore not whether the final explanation sounds convincing. It is whether an independent verifier accepts the repository after the agent finishes.

This article uses two evidence layers:

1. Google's release evidence. The Gemini 3.8 Flash model card reports side-by-side results for long-horizon software engineering and terminal agents. Google's methodology identifies the model IDs, pass-at-one rule, thinking settings, and agent harnesses.
2. The current DeepSWE v1.1 leaderboard. DeepSWE uses 113 original tasks across 91 repositories and five languages. Every model runs through mini-SWE-agent, and hand-written verifiers check behavior rather than demanding one exact implementation.

The short result: 3.8 wins more often by doing more work

Google's September model card reports Gemini 3.8 Flash at 73.7% on DeepSWE v1.1 versus 65.3% for 3.7 Flash. It also reports a smaller gain on Terminal-Bench 2.1—89.4% versus 85.8%—and a much larger relative gain on the newer, harder Terminal-Bench 4.0—19.1% versus 11.2%.

The last row matters. A 7.9-point gain looks dramatic relative to 11.2%, but 19.1% is still a low absolute completion rate. The honest conclusion is not “3.8 can handle any agent job.” It is “3.8 makes more progress when the environment is difficult, while strong verification and fallback paths remain necessary.”

The independent leaderboard shows the bill behind the gain

The DeepSWE v1.1 public leaderboard adds operational detail that a pass-rate table does not. In the September 3 snapshot reviewed for this article, the visible best Gemini configurations were:

This is the most useful finding in the comparison. The better solve rate is not arriving with shorter traces. The 3.8 configuration emits roughly half again as many output tokens and takes roughly two-fifths more steps. That is consistent with Google's own migration guidance: 3.8 may take smaller reasoning steps, call tools iteratively, and verify along the way on difficult goals.

The 143K and 94K output-token figures are cumulative across the many model calls inside a complete agent run. They are not single-response sizes, so they do not conflict with the 65,536-token output limit shown on each model's API page. This distinction matters when estimating quota and spend: the limit applies to one response; the leaderboard total describes a whole loop.

Using the rounded leaderboard values, an approximate cost per solved task is:

Gemini 3.8 Flash: $2.36 / 0.74 = $3.19 per solved task
Gemini 3.7 Flash: $2.03 / 0.65 = $3.12 per solved task

That point estimate should not be mistaken for a two-percent economic verdict. If we divide by the displayed pass-rate ranges instead of only their midpoints, 3.8 lands at roughly $3.15–$3.23 per solved task, while 3.7 spans roughly $2.99–$3.27. The ranges overlap substantially.

The responsible reading is therefore narrower: 3.8's higher completion absorbs much of its higher average run cost in this snapshot, but the rounded public values do not establish a meaningful difference in cost per accepted patch. Your own failed-run spend, cache use, retry policy, and human repair time can easily reverse the order.

Why this is not a perfectly controlled model-weight comparison

There are two different comparisons hiding under one headline.

Google's per-release methodology says the reported DeepSWE results for both 3.8 and 3.7 used mini-SWE-agent with high thinking. But those reports were produced in different release windows. The current DeepSWE leaderboard now labels the visible best 3.8 configuration as high and the visible best 3.7 configuration as medium. Harness packages, routing, provider behavior, and leaderboard selection can also move over time.

So 73.7% versus 65.3% is strong evidence that the deployable 3.8 setup is better on this workload. It is not a laboratory estimate proving that the checkpoint alone causes exactly an 8.4-point lift. A fair internal migration test still needs the same agent version, tools, permissions, time limit, output limit, effort level, repository image, test command, and retry policy.

There is another subtlety: pass-rate intervals describe uncertainty in these runs, not the probability that your own task will work. Your repositories may be older, private, framework-specific, poorly tested, or constrained by credentials that the benchmark never sees.

The spec sheet is almost a tie

If you compare only API rows, there is little reason to upgrade. Both stable models accept text, images, video, audio, and PDFs; output text; support a one-million-token input window and 65,536 output tokens; expose function calling, code execution, computer use, file search, URL context, search grounding, caching, and structured output; and accept low, medium, or high thinking. The minimal level is unsupported on both.

Output pricing includes thinking tokens. That makes “same price” easy to misunderstand: a million output tokens costs the same, but a model that thinks and acts longer can consume more of them per job. List price answers what a unit costs. The agent trace answers how many units the job used.

Where 3.8 is the better first choice

Use 3.8 as the first candidate when the task has a long dependency chain. Examples include a multi-file refactor with tests, a bug that crosses an API boundary, a migration that requires reading configuration before editing, or an issue where the first plausible fix is likely to fail. More persistence is valuable when another inspection or test run can recover the task.

Use it when a failed attempt is expensive. If a human must reconstruct context after every miss, nine more accepted patches per hundred can matter more than a modest increase in model spend. Measure the review and recovery time instead of treating it as free.

Use it when tool recovery is part of the job. A real agent meets missing commands, stale assumptions, partial test failures, and files that are not where the prompt implied. The 3.8 release is explicitly aimed at longer loops and more resilient tool orchestration.

Where 3.7 can still be the rational route

Keep 3.7 for short, repeated jobs that already pass. A known lint fix, a small schema conversion, or a templated repository change may not benefit from an extra 49K output tokens and 49 agent steps. If both models clear the same acceptance gate, the shorter trace is usually easier to operate.

Keep it when latency or quota is the binding constraint. The reviewed sources do not give a matched wall-clock comparison for these two configurations, so steps are not a direct latency measurement. They do show more work. If a queue serves thousands of routine tasks, test throughput and tail latency before upgrading.

Keep it while the new route earns trust. A benchmark does not inspect your private framework, security boundaries, flaky tests, or release policy. A validated 3.7 workflow should become the control group, not collateral damage from a launch announcement.

One task shows why the acceptance path matters

Consider a plausible maintenance ticket—not a claim about an observed Gemini run. An authorization regression crosses a controller, a domain policy, an old fixture, and two integration tests. The obvious one-file fix clears the reported error, but the next test reveals that an administrator path is now denied. A stale fixture then makes the second failure look unrelated.

The useful comparison is not which agent writes the more confident summary. It is whether the agent notices the new failure, traces it to the right invariant, preserves the original test instead of weakening it, avoids unrelated files, and stops with a reviewable working tree. A longer loop is valuable only when each extra step reduces uncertainty.

1. Keep the first patch. Retain the diff, files touched, first test command, and exact failure. Ask whether it fixed the symptom or the governing rule.
2. Watch the recovery loop. Record the next file inspected, tool result, changed hypothesis, and repeated actions. Extra work should produce new information, not merely repeat motion.
3. Interrogate the green test. Run a negative case, check protected files, and repeat from a clean state. Success does not count if the agent weakened the verifier.
4. Review the anonymous patch. Put the diff beside its token total, step count, and human recovery minutes. Ask whether the team would merge and maintain it at that total cost.

This scenario is not a claim about an observed Gemini run. It is a concrete review frame for the failure pattern the benchmarks cannot answer on your behalf.

A fair migration test for your own repositories

A useful internal test can be small. Twenty-four carefully selected tasks are more informative than hundreds of toy prompts:

• Eight localized fixes: one clear defect, a narrow diff, and fast deterministic tests.
• Eight cross-file changes: behavior spans a controller, domain layer, persistence, and tests.
• Eight recovery tasks: the obvious path fails, a command is missing, a fixture is stale, or the requested behavior conflicts with an existing invariant.

1. Freeze the environment. Use the same repository commit, container image, agent harness, instructions, tools, network policy, timeout, and maximum steps.
2. Match effort first. Run 3.8 medium versus 3.7 medium, then repeat the hard subset at high. Do not let a default choose the result.
3. Write the verifier before the run. Include the exact test command, protected files, allowed scope, required behavior, negative cases, and expected exit status.
4. Alternate run order. Do not run every 3.7 case on Monday and every 3.8 case on Tuesday. Interleave them so temporary service conditions do not masquerade as a model effect.
5. Keep first attempts. Report pass at one separately from success after a retry. A hidden second attempt is a different product.
6. Review the patch blind. Hide the model name when a human judges readability, scope, and maintainability.
7. Price accepted work. Add input, cached input, output, thinking, failed attempts, retries, and required human repair; divide by accepted patches.
8. Graduate the apparent winner slowly. Give it only a limited slice of live work, preserve one-click rollback, and watch failure categories rather than a single average.

The failure ledger matters more than the average

Two models can have the same pass rate and very different operational risk. Keep every failure in one of these buckets:

For every failure, record severity, extra model spend, human recovery minutes, whether a retry worked, and whether the same pattern appeared in another task. That turns “3.8 felt smarter” into an operational decision.

A routing policy is better than one global winner

The most economical deployment may use both models:

• Route small, well-specified, fast-test tasks to 3.7 at medium effort.
• Escalate cross-file, low-observability, or failed-first-attempt work to 3.8.
• Use 3.8 high only when the cost of another failed patch exceeds the cost of a deeper trace.
• Stop either model when it repeats a failed action, crosses a protected boundary, exhausts the step budget, or cannot run the acceptance command.

This policy follows the evidence more closely than “always use the newest model.” Google itself keeps 3.7 fully supported for efficiency-first workloads, while positioning 3.8 for long-horizon engineering. The product names are already telling you to segment the work.

The practical verdict

Gemini 3.8 Flash is the stronger coding-agent starting point. The published evidence shows a meaningful improvement on long-horizon repository tasks, and the gain persists across more than one terminal benchmark. At the same list price, that is a substantial upgrade.

But the mechanism matters. The reviewed DeepSWE trace is longer: more output tokens, more agent steps, and a higher average task cost. For difficult work, those extra attempts are exactly what you are buying. For routine work that 3.7 already completes, they may be waste.

Our recommendation is conditional for a reason. Test 3.8 first for hard, multi-file, recovery-heavy tasks. Keep 3.7 as the efficiency control. Choose with cost per accepted patch, not price per token or one polished demo. That decision will remain useful after the next Flash release because it is anchored to your verifier and failure cost, not the version number.

Before you switch: two practical questions

Do Gemini 3.8 Flash and 3.7 Flash cost the same?

Their current standard list rates are the same: $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026, with a scheduled increase to $1.50 and $7.50 on January 1, 2027. Per-task cost can still differ because output billing includes thinking tokens and an agent may call the model many times before it stops.

Should I compare both models at their defaults?

Not if you want a fair model comparison. Pin low, medium, or high explicitly, and keep the agent harness, tools, permissions, step limit, timeout, repository image, and verifier identical. Test the default separately if your real question is which out-of-box product route performs better.