Gemini 4 Argon, GPT-6 Astra, Claude Opus 5.5: Üç Öncü Model, Üç Farklı Kazanan

Google’ın Gemini 4 Argon duyuru yazısı 19 satırlık bir kıyaslama (benchmark) tablosu içeriyor ve tablodaki verilere göre Argon, 13 satırda tek başına zirvede yer alırken bir satırda da birinciliği paylaşıyor. Geride kaldığı beş satır ise tesadüf değil. FrontierSWE v2, Terminal-Bench Science ve OSWorld-2.0 testlerinde GPT-6 Astra öne geçerken; Terminal-bench 4.0 ve PostTrainBench’te Claude Opus 5.5 liderliği alıyor. Bu satırların her ikisi de Terminal-Bench testleri, biri otonom kodlama (agentic-coding), biri makine öğrenimi mühendisliği (ML-engineering) ve biri de iki bilgisayar kullanımı (computer-use) testinden biri: yani bir yazılım ekibinin vaktinin büyük bölümünü harcadığı asıl iş yükleri. Üstelik bu kıyaslama artık varsayımsal da değil. 13 Ekim 2026’dan bu yana Argon, ücretli Gemini API üzerinden gemini-4-argon adıyla genel erişime açılmış durumda.

Dolayısıyla “hangi model kazanıyor?” sorusunun incelenen satıra göre üç farklı yanıtı var ve birden fazla kodlama ajanını aynı anda çalıştıran bir ekip için bu hiç de önemsiz bir ayrıntı sayılmaz. Ekipteki her Agent aynı Runtime üzerinde çalışıyorsa, ilgili yapay zekâ laboratuvarının başarılarıyla birlikte eksikliklerini de peşinen kabullenmiş olursunuz ve her yeni model duyurusunda tartışmalar baştan başlar. Hangi ajanın hangi işte çalıştığı, nelerin tamamlandığı, nelerin inceleme beklediği gibi kritik süreçler, o hafta tablonun zirvesinde kimin yer aldığına göre değişmemelidir.

Özetle (TL;DR)

Kendi hazırladığı tabloda bile tüm kategorileri domine edebilen tek bir öncü laboratuvar yok. Her yeni model lansmanını toptan bir geçiş (migrasyon) gerekçesi olarak görmek yerine, yönlendirme (routing) stratejiniz için birer veri noktası olarak değerlendirin: Birden fazla Runtime’ı bağlı tutun, yönlendirme kuralınızı açıkça tanımlayın (varsayılan bir kural, bir Task’i farklı bir Agent’a devretme koşulları ve incelemeyi kimin yapacağı) ve bunu kendi kod tabanınızdan seçeceğiniz üç Task üzerinde test edin. Astra, Codex üzerinden; Opus 5.5, Claude Code üzerinden ve Gemini modelleri ise ücretli bir anahtarla Gemini CLI üzerinden çalışır. Google, Gemini CLI’ın Argon’u desteklediğini henüz resmen doğrulamadı; bu nedenle gerçek Task’leri devretmeden önce gemini-4-argon ile bir duman testi (smoke test) yapın.

Görev türlerine göre Google’ın tablosu ne anlatıyor?

Google’ın kendi sınıflandırmasına göre, kodlama ajanlarını doğrudan ilgilendiren satırlar şu şekilde sıralanıyor:

Yalnızca otonom kodlama kategorisinde bile dört farklı test ve üç ayrı lider bulunuyor. Argon’un tartışmasız üstünlük kurduğu alanlar ise bilgi odaklı işler, uzun bağlam (long context) ve çok modlu (multimodal) görevler; ancak çıktısı diff ile biten yazılım ekipleri için bunlar ikinci planda kalıyor.

Tabloyu değerlendirirken bir noktayı akılda tutmakta fayda var: Bu, Google’ın kendi tablosu. Google, birçok satırda Argon’u bizzat kendisi test etti; rakiplerin verileri ise büyük oranda beyan edilen sayılardan ya da halka açık skor tablolarından derlendi ve kullanılan test ortamları (harness) birbirinden farklılık gösteriyor. Değerlendirme metodolojisi sayfasında her bir hücrenin veri kaynağı açıkça listelenmiş durumda. Üstelik lansmandan sonra paylaşılan bağımsız sonuçlar da birbiriyle çelişiyor: Scale AI’ın Humanity’s Sixth Sense değerlendirmesinde Argon, GPT-6 Astra’nın %53,6’lık skoruna karşılık %55,4 ile birinci sırada yer alıyor; Cursor, kendi CursorBench testinde modelin Opus 5.5 ile başa baş olduğunu belirtiyor; Artificial Analysis ise 15 Ekim itibarıyla Argon’u (High), listelenen 216 varyant arasında sekizinci sırada konumlandırıyor.

Fiyatlandırma tarafı da tabloyu tek bir model lehine netleştirmiyor. Argon, 30 Kasım 2026’ya kadar bir milyon girdi token’ı başına 2 dolar, bir milyon çıktı token’ı başına ise 10 dolar olarak ücretlendiriliyor; 1 Aralık’tan itibarense bu rakamlar sırasıyla 4 ve 20 dolara çıkacak. Bu ikinci tarife tam olarak Opus 5.5’in fiyatıyla aynı. Astra’nın liste fiyatı ise 10 dolar girdi ve 50 dolar çıktı seviyesinde.

Hiçbir laboratuvar her alanda lider değil; bu yüzden tüm kontrolü tek bir modele bırakmayın

Bu çıkarım bizim şahsi görüşümüz değil, sağlayıcıların kendi paylaştığı verilerin ortaya koyduğu bir gerçek. Google’ın kendi modelini öne çıkarmak için bizzat hazırladığı bir tabloda bile beş satır iki rakibe kaptırılıyorsa, kodlama ajanları söz konusu olduğunda “tek bir en iyi modelden” bahsetmek imkânsızdır. Yalnızca belirli bir görev türü için, mevcut çeyrekte ve belirli bir test ortamında en iyi performansı gösteren bir model vardır.

Bu durum, yeni bir model çıktığında izlenecek yolu da tamamen değiştiriyor. Genellikle ilk akla gelen ve cazip görünen hamle toptan bir geçiş yapmaktır: varsayılan Runtime’ı değiştirmek, tüm kurulumları baştan yazmak ve ekibin alışkanlıklarını sıfırlamak. Oysa çok daha ekonomik olan yaklaşım; yeni modeli, yalnızca güçlü olduğu satırlara denk gelen Task türleri için aday bir seçenek olarak sisteme dahil etmek ve çalışma alanının geri kalanına dokunmamaktır. Daha önce de belirttiğimiz gibi, en iyi kodlama ajanına sahip olmaktan ziyade iş akışını nasıl yönettiğiniz önemlidir; üç farklı modelin ayrı ayrı öne çıktığı bu tablo da bu argümanın somut bir göstergesidir.

Karar verirken göz önünde bulundurmanız gereken net ayrım şudur:

• Task’lerinizin büyük kısmı birbirine benziyorsa ve her şeyi tek bir kişi gözden geçiriyorsa tek bir varsayılan Runtime kullanmaya devam edin. İkinci bir Runtime; bakımını yapmanız gereken ikinci bir yapılandırma, ikinci bir fatura ve yönetilmesi gereken yeni hata senaryoları anlamına gelir.
• Task’leriniz kabuk (shell) odaklı işler, arayüz (UI) doğrulamaları ve geniş kod tabanlarını tarama gereksinimleri arasında bölünüyorsa iki veya üç Runtime’ı birlikte çalıştırın; çünkü benchmark tablosundaki ayrışma da tam olarak bu noktalarda gerçekleşiyor.

Yönlendirme kurallarını yazılı hale getirin

Yalnızca bir mühendisin zihninde yaşayan bir yönlendirme kuralı aslında bir alışkanlıktan ibarettir; alışkanlıklar ise ekibe yeni biri katıldığında ya da yoğun bir lansman haftasında kolayca unutulup gider. Bu kuralı tüm ekibin rahatça erişebileceği bir yere yazın:

Routing rule v1 (re-test after every frontier launch)

Default
  The Agent on your current default Runtime, until your own
  comparison says otherwise.

Send the Task to the Claude Code Agent (Opus 5.5 set in Claude Code) when
  - most of the work happens in a terminal: builds, CI repair, setup  [Terminal-bench 4.0]
  - it is training or evaluation plumbing for a model pipeline        [PostTrainBench]

Send the Task to the Codex Agent (GPT-6 Astra set in Codex) when
  - the change has to be verified by driving a desktop or browser UI  [OSWorld-2.0]
  - it is scientific or data work done mostly in a terminal           [Terminal-Bench Science]

Send the Task to the Gemini CLI Agent (gemini-4-argon) when
  - it needs a very large codebase or log read in one pass            [GraphWalks]
  - note: the 1M window is shared by input, thinking and output, and
    Gemini CLI support is unverified. Smoke-test before this line routes work.

Escalate
  If a run fails its acceptance checks twice, reassign the Task to the next
  Agent in this rule. The failed runs stay on the Task as evidence.

Review
  An Agent on a different Runtime from the author reads the diff and the
  evidence. A person accepts the result.

Buradaki her koşul, dayandığı kıyaslama satırını ve kolayca ayırt edebileceğiniz bir Task yapısını belirtir. En kritik satır ise inceleme (Review) adımıdır: Bir diff’in, onu bizzat yazmamış farklı bir model tarafından denetlenmesi oldukça düşük maliyetli ikinci bir görüş sağlar; son onay ise her zaman bir insanda kalır.

Bu kuralın nerede tutulacağı yönlendirmenin nasıl yapıldığına bağlıdır. Assignee seçimini insanlar yapıyorsa, kural Space’in yazılı standartları arasında yer almalıdır. Yönlendirmeyi bir Crew lideri yapıyorsa, Crew talimatlarına eklenmelidir. Hangi yöntem benimsenirse benimsensin, sonuçlar aynı Task’e döneceği için kıyaslama geçmişi tek bir merkezde toplanır. Hangi kodlama görevi için hangi model tercih edilmeli başlıklı yazımızda, görev türlerinin model rollerine nasıl eşleneceği çok daha kapsamlı bir şekilde ele alınmaktadır.

Kurala güvenmeden önce kendi kod tabanınızda test edin

Bir benchmark satırı belirli bir Task türünü yalnızca aday listesine sokar; varsayılanın ne olacağını belirleyecek olan ise kendi deponuzdur (repository). Kodlama ajanlarını sentetik testler yerine kendi kod tabanınızda kıyaslama yöntemi bu tabloyla kusursuz bir uyum sağlar; zira tablo, hangi üç Task’i seçmeniz gerektiğini zaten doğrudan gösteriyor:

1. Bozuk bir CI işi gibi, yoğun terminal kullanımı gerektiren bir Task.
2. Yapılan değişikliğin kullanıcı arayüzü (UI) üzerinden doğrulanması gereken bir Task.
3. Kod deposunun önemli bir bölümünün bağlama (context) alınmasını gerektiren kapsamlı bir soru.

Her bir çalıştırmanın kendi worktree’sine sahip olması için Create temporary directory modunu kullanarak, her Agent’a aynı Task açıklamasını ve kabul kriterlerini verin. Ardından ajanın söylediklerine değil, Task’e dönen somut verilere göre puanlama yapın: üretilen diff, çalıştırılan kontroller ve sonuçları, ajanın yönelttiği sorular ve bir insanın sonucu onaylamasının ne kadar sürdüğü.

Gemini CLI ortamınızda gemini-4-argon ile tek satırlık bir duman testi başarıyla geçtikten sonra Argon’u bu karşılaştırmaya hemen dahil edebilirsiniz. Başka herhangi bir ayarı değiştirmeden önce aynı üç Task’i bu modelle de çalıştırın. Varsayılan runtime kıyaslaması: Opus 5.5 vs GPT-6 Sol incelememiz, aynı kararın tamamlanan görev başına maliyet boyutunu ayrıntılarıyla ele alıyor.

15 Ekim 2026 itibarıyla modeller nerede çalışıyor?

Gemini satırlarında kritik bir ayrıntı bulunuyor: Google’ın geçiş duyurusuna göre, Gemini CLI 18 Haziran 2026 tarihinden bu yana Google AI Pro, Ultra veya bireysel kullanıcılar için sunulan ücretsiz Code Assist hesaplarını desteklemiyor. Pro ve Ultra abonelikleri Gemini uygulaması içinde Argon erişimi sunsa da bir abonelik API anahtarı yerine geçmez ve Argon için ücretsiz bir API katmanı bulunmamaktadır.

Sharkly doğrudan model seçimi yapmaz. Agents dokümantasyonunda bu durum açıkça belirtilmiştir: “Agent, Runtime’ın varsayılan modelini takip eder; belirli bir model adı taahhüt etmez veya göstermez.” Modeli; Agent veya Runtime üzerindeki Custom arguments alanından ya da Computer üzerindeki ilgili aracın kendi yapılandırma dosyasından ayarlarsınız. Dolayısıyla yönlendirme kuralında geçen “Codex Agent” ifadesi, Astra kullanacak şekilde yapılandırılmış bir Codex Runtime üzerindeki Agent anlamına gelir.

Kurulum adımlarına Sharkly’de GPT-6 Astra Kullanımı ve Sharkly’de Claude Opus 5.5 Kullanımı yazılarından; Gemini CLI yapılandırması ve Argon’a geçiş sürecine ise Kodlama ajanları için Gemini 4 Argon rehberimizden ulaşabilirsiniz.

Skor tablosu değişir, çalışma düzeniniz değişmemeli

Piyasaya sürülecek bir sonraki model bu tabloyu yeniden şekillendirecektir. Asıl sabit kalması gereken ise modelin etrafındaki tüm operasyonel yapıdır: yönlendirme kuralları, Task’ler, her çalıştırmanın sunduğu kanıtlar ve sonucu nihai olarak onaylayan insan. Ajanlar araştırır, çalıştırır, test eder ve raporlar; insanlar ise yönü belirler, yetki verir ve sonucu kabul eder.

Tek bir ekosisteme bağımlı kalmak yerine birden fazla kodlama ajanını esnek bir şekilde birlikte kullanmak istiyorsanız, Sharkly tam da bu ihtiyacı çözmek için tasarlandı.