Gemini 3.7 Flash ve Üç Haftalık Model Döngüsü

Google, 13 Ağustos'ta Gemini 3.7 Flash'ı yayınladı ve onu kodlama ile agent'lar için "bugüne kadarki en zeki iş beygiri modeli" olarak tanımlıyor. Model, Gemini 3.6 Flash'tan üç hafta sonra geldi ve yıl sonuna kadar milyon token başına maliyeti, 3.6 Flash'ın ilk fiyatının yarısı. Benchmark kazanımları güçlü görünüyor ama benim aklım sürekli o üç haftaya gidiyor. Ekibinizin yeni bir modeli benimsemesi bir ay sürüyorsa, her zaman bir sürüm geriden gelirsiniz.

Google ne yayınladı#

Duyuru, 3.7 Flash'ı doğrudan 3.6 Flash ile karşılaştırıyor:

• FrontierCode 1.1 Main: %43,6'ya karşı %34,4
• DeepSWE v1.1: %65,3'e karşı %49,0
• WebDev Arena: Elo 1588'e karşı 1538
• GDP.pdf (karmaşık doküman işleme): %34,0'a karşı %22,0
• AutomationBench (iş akışları): %30,4'e karşı %17,0

Model kartına göre 3.7 Flash, 3.6 Flash'ı temel alıyor ve çekirdek akıl yürütmesinde algoritmik iyileştirmeler içeriyor. 1M token'a kadar girdi kabul ediyor, 64K token'a kadar çıktı üretiyor ve bilgi kesim tarihi Mart 2026. Ancak kart, bazı alanlarda bu tarihin Ocak 2025'te kalabileceği uyarısını da yapıyor. Kart ayrıca halüsinasyonları ve "ara sıra yaşanan yavaşlık veya timeout sorunlarını" kısıtlamalar arasında sayıyor. Modeli kullanıcıya dönük bir isteğin arkasına koymadan önce bunu okuyun.

Model, ilk günden itibaren Google Antigravity'de, Google AI Studio üzerinden Gemini API'de, Android Studio'da, Gemini Enterprise Agent Platform'da ve Gemini Enterprise uygulamasında kullanılabiliyor.

Fiyatın bir son kullanma tarihi var#

Tanıtım fiyatı 1M girdi token'ı için $0,75, 1M çıktı token'ı için $3,75. Bir dipnot, bu fiyatın 31 Aralık 2026'da sona erdiğini belirtiyor. 1 Ocak 2027'den itibaren fiyat girdi için $1,50, çıktı için $7,50; yani tam iki katı. Model kartı 3.6 Flash için de aynı tanıtım fiyatını ve bitiş tarihini veriyor, dolayısıyla 3.6'dan 3.7'ye geçmek bu yıl token başına ücreti değiştirmiyor.

Bu da yazıdaki ikinci maliyet detayını daha önemli hale getiriyor. Google, modelin daha titiz düşündüğünü, çok adımlı planlamaya ve tool çağrılarına daha fazla efor harcadığını söylüyor. Bunu daha az yeniden deneme ve daha az manuel gözetim olarak sunuyor. Bu doğru olabilir, ama aynı zamanda token başına fiyatın görev başına fiyat olmadığı anlamına geliyor. Daha çok planlayan ve daha az hata yapan bir model, tamamlanan görev başına daha ucuza da gelebilir, daha pahalıya da. Bunu size ancak ölçüm söyler.

Yani bu çeyrekte kurulan her maliyet modelinde iki değişiklik gerekiyor. Bütçeyi lansman fiyatına değil, 2027 fiyatına göre yapın. İstek başına maliyeti değil, tamamlanan görev başına maliyeti takip edin.

Üç hafta, çoğu review döngüsünden kısa#

Eskiden zor karar model seçmekti. Artık zor olan, bir model değişikliğinin sessizce bir şeyleri bozmadığını, işe yarayacak kadar hızlı kanıtlamak. Public benchmark'lar yönü gösterir. Bir modelin sizin repository'nizle, sizin konvansiyonlarınızla ya da sizin flaky test suite'inizle nasıl başa çıktığını göstermez. Google'ın kendi lansman sayfaları bile 3.6 Flash'ın DeepSWE baseline'ında hemfikir değil: blog yazısında %49,0, model kartında %48,6.

Üç haftalık bir tempoya ayak uydurabilen şey, kendi işlerinizden oluşturulmuş küçük bir eval altyapısı: her biri deterministik bir kontrole sahip birkaç düzine gerçek görev. Başarısız testin geçmesi gereken bir bug fix. Build'in ve type checker'ın yeşil kalması gereken bir refactor. Bir tasarım referansından oluşturulup onunla karşılaştırılan bir ekran. Her aday aynı suite'i çalıştırır ve çıktı tek başına bir skor değil, bugünkü production modeline karşı bir diff olur.

Quorate'in bir diff üzerinde birden fazla AI reviewer çalıştırıp, herhangi bir reviewer'ın görüşü yerine deterministik PASS/WARN/FAIL kapılarıyla sonuçlanmasının sebebi de bu. Modeller bu kadar sık değiştiğinde, bir makinenin tekrarlayabileceği bir karara ihtiyacınız var.

Modeli bir config değeri haline getirin#

Model değiştirmek uygulama kodunu değiştirmek anlamına geliyorsa, üç hafta çok kısa. Ben birden fazla coding agent'ı paralel çalıştırıyorum ve görevleri zaten maliyete göre modeller arasında yönlendiriyorum. Vardığım sonuç şu: model, her görev sınıfı için bir yönlendirme kararı olmalı; fiyatı ve fiyatın bitiş tarihi de hemen yanında saklanmalı.

const routes = {
  'issue-fix': {
    model: 'gemini-3.7-flash',
    fallback: 'pinned-current-default',
    evalSuite: 'repo-bugfix',
    price: { inPerM: 0.75, outPerM: 3.75, validUntil: '2026-12-31' },
  },
};

İşe yarayan kısım validUntil alanı. Maliyet dashboard'u bunu okursa, 1 Ocak sürpriz olmaktan çıkar. Model kartındaki timeout notu düşünüldüğünde, açıkça tanımlanmış fallback de önemli.

Ben ne yapıyorum#

Ekibiniz teslimat iş akışında LLM kullanıyorsa, pazartesi günü şunları kontrol ederdim:

• Production'da model versiyonlarını tam olarak sabitleyin (pin'leyin). Sessiz bir değişikliğin kullanıcılara ulaşabileceği her yerde "latest" alias'larından kaçının.
• 3.7 Flash'ı Antigravity veya Android Studio üzerinden zaten kimin kullandığını öğrenin. Model, herhangi bir platform kararından önce, ilk günden bu araçlarda.
• Flash seviyesindeki bir modelin yeterli olduğu tek bir görev sınıfında, kendi suite'inize karşı shadow modda çalıştırın.
• Token'ları ve yeniden denemeleri sadece çağrı başına değil, tamamlanan görev başına loglayın.
• Ocak 2027 fiyatını gelecek yılın bütçesine şimdiden koyun.

Benim görüşüm: 3.7 Flash sağlam bir sürüm gibi görünüyor ve daha ucuz, yetenekli modeller agent geliştiren herkes için iyi haber. Ama her üç haftada bir yenilenen bir model, diğerleri gibi bir bağımlılıktır. Bir framework yükseltmesiyle aynı disipline ihtiyaç duyar: sabitlenmiş versiyonlar, güvendiğiniz bir test suite'i ve deploy gerektirmeyen bir rollback yolu.