Head to head: Google: Gemini 3.6 Flash vs DeepSeek-V4-Pro

Gemini 3.6 Flash takes this matchup the right way: not by dominating every prompt, but by being the model that breaks less often on the things that matter. It posts the stronger overall score, wins 5 tasks to 2, and clears the bar with 86% confidence—which is comfortably beyond "maybe" territory. DeepSeek-V4-Pro kept it competitive in pockets, but the broader pattern is clear.

The decisive gap showed up in implementation-heavy work and instruction discipline. Gemini was better on constraint scheduling, Go rate-limit debugging, LRU cache, LRU+TTL algorithm design, and the concurrency bug fix. That’s a meaningful cluster: code correctness, edge-case handling, and actually obeying output constraints. Again and again, DeepSeek’s problem wasn’t raw capability so much as sloppiness around format or incomplete fixes—extra exposition when the prompt wanted just the answer, or logic that solved the main bug while leaving an important edge case alive.

DeepSeek’s wins were real but narrow. It edged Gemini on unit-aware math mostly on presentation, and it was better on editing a vendor update because it preserved tone and format more faithfully. Those are legitimate strengths. But they’re also the kind of wins that don’t outweigh losing the more failure-sensitive tasks where robustness matters more than polish.

The five ties reinforce the same story. On support ticket classification, SQL, and contradiction finding, the models were essentially even. The split decisions on instruction-following memo and dense summarization were mixed enough to wash out. In other words, when the task was straightforward, DeepSeek could absolutely hang. When the task demanded precision under constraints, Gemini was more dependable.

Final call: Gemini 3.6 Flash is the better text model here—clearly, not marginally. DeepSeek-V4-Pro is competitive on cleaner editorial and formatting tasks, but Gemini is the stronger all-around pick because it is more reliable where mistakes are costly.

How they were tested

We ran 12 fresh text tasks, generated on the fly for this matchup so neither model could prepare in advance, and had gpt-5.4 score each one. To cancel position bias, every task was judged twice — once in each presentation order — and every number reported here, including the headline totals, is the average of both passes. Google: Gemini 3.6 Flash scored 111.7 to DeepSeek-V4-Pro's 98.8.

1. Unit-aware math

A pump moves 3.5 liters every 8 seconds. A tank holds 0.9 cubic meters. Starting empty, how long to fill it, in minutes and seconds (mm:ss), rounded to the nearest second? Show the key steps, then give the final answer on its own line.

Winner: DeepSeek-V4-Pro — Model A and Model B both compute the correct fill time of 34:17, show the key steps clearly, and provide the final answer on its own line. Model B is slightly more polished in presentation, while Model A is a bit more concise, so neither is meaningfully better overall. (Second judge pass, order swapped — scores are the average of both: Model B and Model A are both correct and show the key unit conversions and rate calculation, arriving at 34:17. Model B is slightly better because it more explicitly follows the instruction to give the final answer on its own line and is a bit clearer and more polished in presentation.)

2. classify_support_tickets

Classify each support ticket into exactly one category: BILLING, BUG, FEATURE, ACCESS, or HOWTO. Give a one-sentence justification for each. Return in this exact format per line: ID | CATEGORY | justification T1: "I was charged twice for the HarborPlan annual renewal after updating my card." T2: "The Export CSV button spins forever only on Firefox 128 when the date filter includes April 2023." T3: "Can you add a dark mode for the dispatch dashboard?" T4: "I reset my password, but the login page still says my account is locked." T5: "Where do I change the default tax rate on quotes for Quebec customers?" T6: "The mobile app closes immediately after I tap Scan Receipt on a Pixel 7a."

Winner: Tie — Model A and Model B both classify all six tickets correctly, provide exactly one category per ticket, include one-sentence justifications, and follow the required line format. Model A is slightly more specific in a few justifications, while Model B is slightly more concise, but neither has a meaningful quality advantage overall. (Second judge pass, order swapped — scores are the average of both: Model B and Model A both classify all six tickets correctly, provide exactly one category per ticket, include one-sentence justifications, and follow the required line format precisely. The writing in both is clear and concise, with no meaningful quality difference for this task.)

3. sql_solar_shipments

Schema: customers(customer_id INT, name TEXT, state TEXT) orders(order_id INT, customer_id INT, order_date DATE) order_items(order_id INT, sku TEXT, quantity INT, unit_price DECIMAL(10,2)) products(sku TEXT, category TEXT) Write a single SQL query to answer this question: For Q3 2024 (2024-07-01 through 2024-09-30 inclusive), return the top 3 states by total revenue from products in category 'solar_battery'. Revenue is sum(quantity * unit_price). Output columns: state, revenue, order_count, ranked by revenue descending then state ascending. Count each qualifying order once in order_count even if it has multiple solar_battery line items.

Winner: Tie — Model A and Model B provide materially identical SQL that correctly filters Q3 2024 orders, restricts to 'solar_battery' products, sums revenue, and counts distinct qualifying orders per state before returning the top 3 states in the required order. Model A follows the 'single SQL query' instruction more cleanly, while Model B adds unnecessary explanatory text, but the SQL itself is equally correct. (Second judge pass, order swapped — scores are the average of both: Model B and Model A provide materially equivalent SQL that correctly filters Q3 2024 orders, restricts to 'solar_battery' products, sums revenue, counts distinct qualifying orders, and returns the top 3 states in the requested order. Model B adds brief explanatory text, while Model A is more concise, but both satisfy the task equally well.)

4. Constraint scheduling

Four talks (A, B, C, D) fill four 1-hour slots 9,10,11,12. Constraints: A is before D; C is not first; B is immediately after A; D is not at 12. Give the ONE valid schedule as 'slot: talk' lines, then a one-line justification. If impossible, say so and explain.

Winner: Google: Gemini 3.6 Flash — Model A gives the unique valid schedule correctly and follows the requested format exactly, including a one-line justification. Model B is also correct, but it does not adhere as closely to the instruction because it adds extensive step-by-step exposition instead of just the schedule lines followed by a one-line justification. (Second judge pass, order swapped — scores are the average of both: Model A is better because it gives the correct unique schedule in exactly the requested format with a one-line justification. Model B is also correct, but it adds unnecessary step-by-step reasoning and extra formatting instead of strictly following the instruction to provide only the schedule and a one-line justification.)

5. edit_vendor_update

Edit the passage for grammar, punctuation, concision, and clarity without changing meaning. Then provide 3 brief bullet notes on the main changes. Passage: "Hi team — As discussed in yesterdays review, the vendor says the replacement sensors is already shipped, however tracking haven't updated since Tuesday. If it doesn't arrive by Friday we will need to postpone the cold-room calibration, which means Ops may need reschedule the audit window. Marta and me also noticed two serial numbers on the packing list don't match whats in the ticket. Please double check before signing anything off, and let me know if there is any questions."

Winner: DeepSeek-V4-Pro — Model B is slightly better because it cleanly edits the passage while preserving the original dash-style greeting and provides exactly 3 brief bullet notes. Model A is also strong, but its added headings and separator make it a bit less concise and slightly less aligned with the requested format. (Second judge pass, order swapped — scores are the average of both: Model B is slightly better because it cleanly edits the passage while preserving tone and format, and its three brief notes match the instruction precisely. Model A is also strong, but it adds extra framing text and changes "signing anything off" to "signing off on anything," which is a slightly less faithful wording shift.)

6. Find the contradiction

The following spec contains exactly one internal contradiction. Quote the two conflicting sentences verbatim and explain the conflict in one sentence. Do not fix it. Spec: "Free accounts may create up to three projects. Every account, regardless of tier, may archive unlimited projects. Archiving a project does not count against the project limit. Free accounts are limited to three projects total, including archived ones."

Winner: Tie — Model A and Model B both correctly identify the same two contradictory sentences, quote them verbatim, and explain the conflict in one sentence without attempting to fix it. Model A is slightly more formatted, while Model B is slightly more concise, but neither is meaningfully better for this task. (Second judge pass, order swapped — scores are the average of both: Model B and Model A both identify the same two conflicting sentences verbatim and explain the contradiction accurately in one sentence without attempting to fix it. Model A is slightly more formatted, but there is no meaningful quality difference for this task.)

7. debug_go_rate_limit

Go. The function should return true if a user has made fewer than limit requests in the last windowSec seconds, otherwise false. It currently behaves incorrectly near the boundary and also mutates the stored slice unsafely. Find and fix the bug(s). Return corrected code only. package main func allowRequest(history map[string][]int64, user string, now int64, windowSec int64, limit int) bool { times := history[user] cutoff := now - windowSec i := 0 for ; i < len(times); i++ { if times[i] > cutoff { break } } times = times[i:] allowed := len(times) <= limit if allowed { times = append(times, now) } return allowed }

Winner: Google: Gemini 3.6 Flash — Model A is better because it returns corrected code only, fixes the boundary and limit checks, and avoids unsafe aliasing by copying into a new slice before storing it back. Model B fixes the main logic bugs but violates the instruction to return code only and still reuses the subslice backing array, so its mutation fix is incomplete. (Second judge pass, order swapped — scores are the average of both: Model A is better because it returns corrected code only and fully fixes both issues: the boundary condition and the unsafe slice aliasing by copying into a new slice before storing it back. Model B fixes the logic but violates the instruction to return code only and still reuses the subslice backing array, so its append can mutate shared storage unsafely.)

8. LRU cache

Implement a class LRUCache<K, V> in TypeScript with a fixed capacity set in the constructor, and O(1) get(key): V | undefined and set(key, value): void. Accessing or updating a key must mark it most-recently-used; inserting beyond capacity must evict the least-recently-used entry. Return ONLY the class, no prose.

Winner: Google: Gemini 3.6 Flash — Model A is better because it fully satisfies the LRU behavior with O(1) operations and also guards against invalid zero or negative capacity, while Model B can fail to evict correctly when capacity is nonpositive and may attempt to delete an undefined key. Both follow the instruction to return only the class, but Model A is slightly more robust and polished. (Second judge pass, order swapped — scores are the average of both: Model A is slightly better because it correctly implements the required O(1) LRU behavior while also guarding against invalid non-positive capacity, making the class more robust. Model B is also mostly correct, but with capacity 0 it can behave incorrectly when trying to evict using an undefined key.)

9. algo_lru_ttl

Python 3. Implement a cache class LRUCacheTTL with methods init(capacity:int), get(key:str, now:int)->int|None, put(key:str, value:int, ttl:int, now:int)->None. A key expires at now+ttl and must behave as absent at any later time. Evict least recently used among non-expired keys when capacity is exceeded. get() updates recency only if the item exists and is not expired. put() overwrites existing keys, resets TTL, and updates recency. Target complexity: O(1) average time per operation and O(capacity) space. Return code only.

Winner: Google: Gemini 3.6 Flash — Model A correctly handles expiration on get, updates recency appropriately, and evicts the LRU entry when needed, though it has edge-case issues such as capacity 0 and can scan multiple expired entries during put. Model B has a more serious correctness flaw: on put it evicts the tail without accounting for expired entries already occupying space, so it can remove a non-expired key even when expired keys should behave as absent and be discarded first. (Second judge pass, order swapped — scores are the average of both: Model A is better because it correctly maintains LRU order and handles expiration on access, whereas Model B can evict an expired entry instead of the least recently used non-expired key and also fails badly when capacity is 0 by trying to remove the dummy head. Model A is still imperfect because updating an existing expired key does not treat it as absent before overwrite, but overall it is closer to the requested behavior and cleaner.)

10. Concurrency bug fix

This TypeScript function is meant to memoize an async loader but has a race: concurrent callers can each trigger the underlying fetch. Fix it so the fetch runs at most once per key, and a rejected fetch does NOT poison the cache (a later call must retry). Return ONLY the corrected function. ts const cache = new Map<string, Promise<string>>(); async function load(key: string, fetcher: (k: string) => Promise<string>) { if (cache.has(key)) return cache.get(key)!; const value = await fetcher(key); cache.set(key, Promise.resolve(value)); return value; }

Winner: Google: Gemini 3.6 Flash — Model A correctly stores the in-flight promise before awaiting, preventing duplicate concurrent fetches, and removes the cache entry on rejection so later calls retry. Model B uses the same core fix, but it violates the instruction to return only the corrected function by adding explanatory text and redundantly redeclaring the cache. (Second judge pass, order swapped — scores are the average of both: Model A provides the corrected function only, exactly as requested, and correctly stores the in-flight promise before awaiting so concurrent callers share one fetch while deleting failed entries to allow retries. Model B's logic is also correct, but it violates the instruction to return only the corrected function by adding explanatory text and redundantly redeclaring the cache.)

11. instruction_following_memo

Write a customer-facing status update about a delayed furniture delivery. Constraints: - Exactly 4 bullet points. - Each bullet must start with these labels in order: Order:, Delay:, Action:, Contact: - 9 to 13 words per bullet. - Include the order number ZX-4187 and the new delivery date November 14. - Mention a warehouse transfer and a refund of the delivery fee. - Do not use the words "sorry", "apologize", or "unfortunately". - No intro or outro; bullets only.

Winner: Tie — Model A satisfies all key content requirements and keeps each bullet within the 9–13 word limit. Model B is clearer in places, but it omits the required refund mention in the Contact bullet context and its Action bullet exceeds the word limit, so Model A follows the instructions better overall. (Second judge pass, order swapped — scores are the average of both: Model B satisfies all key constraints: exactly four bullets with the required labels in order, each bullet within the 9–13 word limit, and it includes the order number, new delivery date, warehouse transfer, and delivery-fee refund. Model A is clear, but its first bullet omits the new delivery date and falls short of the required word count, so its instruction following is weaker.)

12. Summarize dense passage

Summarize the passage below in exactly three bullet points, each one sentence, capturing the mechanism, the tradeoff, and the caveat — no jargon a non-specialist couldn't follow. Return only the bullets. Passage: "Speculative decoding pairs a small draft model with a large target model: the draft proposes several tokens, the target verifies them in one pass, and accepted tokens are kept while the first rejection resets to the target's own choice. This can cut latency substantially when acceptance is high, but the draft model's compute is pure overhead when acceptance is low, and gains evaporate on adversarial or highly novel inputs where the draft and target disagree often."

Winner: Tie — Model A better matches the requested structure by cleanly covering the mechanism, tradeoff, and caveat in exactly three simple one-sentence bullets without adding unnecessary claims. Model B is also strong, but it introduces a less-grounded detail about "avoiding step-by-step work" and adds that it can underperform normal generation, which goes beyond the passage. (Second judge pass, order swapped — scores are the average of both: Model B better captures all three requested elements, especially the caveat that performance can be no better than normal and may even be worse when disagreement is frequent. Model A is clear and concise, but it omits the stronger downside implied by the passage and is slightly less precise overall.)

See every prompt and the full side-by-side outputs in the interactive Head-to-Head.