Opus 4.6 (fast) Emekli Oluyor: Copilot Kullanıcıları Ne Yapmalı?
Bir GitHub Copilot duyurusu daha geldi, yine model emekliliği. Açık konuşayım, bu tip haberleri artık takvime bile yazmıyorum; çünkü neredeyse her ay benzer bir not düşüyorlar. Ama bu sefer iş biraz farklı — Opus 4.6 (fast), özellikle ajan modunda. Uzun bağlamlı kod düzenlemelerinde bayağı yer etmiş bir modeldi, yanı sessizce geçilecek türden değil.
Kısaca durum şu: GitHub, 29 Haziran 2026 itibarıyla Opus 4.6 (fast) modelini tüm Copilot deneyimlerinden kaldırıyor. Chat, inline edits, ask modu, agent modu, kod tamamlama — hepsinden gidiyor (inanın bana). Önerilen alternatif de Opus 4.8 (fast) (en azından benim deneyimim böyle). Resmî duyuru tek paragraflık bir not gibi dursa da, kurumsal tarafta bunun yankısı epey konuşulur.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Şöyle söyleyeyim, Bu yazıda hem duyurunun teknik tarafına gireceğim, hem de — daha önemlisi — Türkiye’deki ekiplerin bu geçişi nasıl planlaması gerektiğine dair pratik bir yol haritası çıkaracağım. Çünkü “modeli değiştir, bitsin” demek kolay. Copilot Enterprise lisansı olan bir yerde işler öyle düz ilerlemiyor, hani kağıt üstünde basit görünen şeyler sahada bazen uzuyor da uzuyor.
Duyurunun Özü: Tarihler, Modeller, Aksiyonlar
Önce kuru bilgiyi bir kenara koyayım, sonra yorum kısmına geçerim. Aşağıdaki tablo, GitHub’ın resmî changelog’undan süzdüğüm kısa özet; yanı lafı uzatmadan, ne var ne yok burada dürüyor.
| Model | Emeklilik Tarihi | Önerilen Alternatif | Etkilenen Yüzeyler |
|---|---|---|---|
| Opus 4.6 (fast) | 29 Haziran 2026 | Opus 4.8 (fast) | Chat, inline edits, ask/agent modları, completions |
Yanı işin özü iki şeye çıkıyor: iş akışlarınızı güncellemek, bir de eğer Copilot Enterprise yöneticisiyseniz model politikalarından 4.8’i açmak. Model kendi kendine ortadan kaybolacak diye ekstra bir şey yapmanız gerekmiyor, o tarafı GitHub zaten hallediyor.
Şimdi “ne var bunda” diyebilirsiniz (evet, doğru duydunuz). Küçük bir ekipte hakikaten çok büyütülecek mesele değil. Ama 200+ geliştiricinin çalıştığı bir kurumdaysanız, hele bir de model seçimini hardcode etmiş CI agent’larınız veya custom prompt katmanlarınız varsa, olay bir anda başka yere dönüyor; bak şimdi, asıl dert orada başlıyor.
Bir dakika — bununla bitmedi.
Evet. Microsoft Build 2026: Liderlerin Bilmesi Gereken 3 Kritik Çıkarım yazımızda bu konuya da değinmiştik.
Neden Bunu Ciddiye Alıyorum?
Bana kalırsa asıl mesele emeklilik tarihi değil, etraftaki sessiz kırılma riski. Bir gün her şey normal gidiyor gibi görünürken (build yeşil, PR yorumları akıyor, agent cevap veriyor), ertesi hafta ufak bir değişiklik yüzünden bazı akışlar garip davranmaya başlayabiliyor; işte tam bu yüzden önceden hazırlık yapmak daha rahat ettiriyor.
Açık konuşayım, model değişimi bazen sadece “işim değişti” gibi dürüyor ama pratikte öyle olmuyor. Prompt davranışı biraz kayıyor olabilir, latency tarafı farklı hissedilebilir ya da sizin ince ayar verdiğiniz otomasyonların çıktısı beklediğiniz ritmi tutturmayabilir; emin değilim ama sanırım en çok sürpriz yaratan kısım da bu oluyor.
Bir dakika — bununla bitmedi.
Peki neden?
İşin garibi, Cevap basit gibi dürüyor ama küçük değil: ekip büyüdükçe standartlaştırılmış araç zinciri kuruyorsunuz. O zincirin içinde model seçimi tek başına masum kalmıyor. En çok da enterprise ölçeğinde policy katmanı olan yerlerde, tek bir ayar yüzünden birkaç takımın işi aksayabiliyor; hani dışarıdan bakınca ufak görünür ama içeride baya uğraştırır.
Sizin Tarafta Ne Yapılır?
Lafı gevelemeden söyleyeyim: önce nerede Opus 4.6 (fast) kullandığınızı bulun. Sonra bunu Opus 4.8 (fast)‘e taşıyacak noktaları tek tek listeleyin; chat entegrasyonları var mı, inline edit kullanan ekipler var mı, ask/agent moduna yaslanan otomasyonlar var mı diye bakın.
Neyse ki süreç genelde sandığınız kadar dramatik olmuyor. Eğer model çağrısını uygulama koduna gömmüşseniz biraz refactor çıkar. Policy ile yönetiyorsanız iş daha temiz ilerler — yine de test etmeden geçmeyin çünkü küçük farklar bazen prod’da tokat gibi geliyor.
Sız ne dersiniz?
Bence burada en mantıklı hareket erken taşımak ve son güne bırakmamak. Çünkü 29 Haziran 2026 kulağa uzak geliyor olabilir ama böyle tarihler nedense hep yaklaşınca hızlı akıyor; sonra bir bakmışsınız CI agent eski modele takılmış, kullanıcı da “neden farklı cevap veriyor bu?” diye soruyor.
Opus 4.6 (fast) Aslında Ne İşe Yarıyordu?
Adındaki “fast” eki insanı bir an yanıltıyor, açık konuşayım. Anthropic’in standart Opus modeli zaten daha çok “düşünen” tarafta dürüyor; yanı derin akıl yürütüyor, ama bunun bedeli olarak da biraz ağır kalıyor. GitHub’ın Copilot’a eklediği “fast” varyantları işe düşük gecikme ve daha kısa cevap süresi için ayarlanmış sürümler. Birebir aynı modelin hızlandırılmış hali değil bu; daha çok belli senaryolara göre ince ayar çekilmiş bir profil gibi düşünün. Daha fazla bilgi için Azure Cosmos DB’ye Immutable Backup Geldi: Ne Değişiyor? yazımıza bakabilirsiniz.
Şöyle ki, Sahada ben şunu sık görüyorum: ekipler hangi modelin neye yaradığını netleştirmeden seçim yapıyor. “Opus daha akıllı” deyip herkesin gözü kapalı oraya koşması mesela (en azından benim deneyimim böyle). Hani kulağa mantıklı geliyor, ama işin aslı öyle düz değil.
- Inline completions için “fast” modeller doğru tercih — kullanıcı saniyeler içinde cevap bekliyor. — ciddi fark yaratıyor
- Agent modu ve çok adımlı kod düzenleme için “fast” değil, normal Opus daha yerinde dürüyor.
- Chat’te kısa soru-cevap için “fast” yine yeterli oluyor.
Tuhaf ama, Opus 4.6 (fast), özellikle ikinci grupta, yanı agent senaryolarında, biraz orta yol gibi davranıyordu. Ne tam hızlıydı, ne de derin tarafta rahat ediyordu; garip bir denge vardı orada. 4.8’in bunu daha iyi toparlaması bekleniyor, zaten GitHub’ın yönü de aşağı yukarı o tarafa dönmüş durumda.
Peki neden zaten “deprecate” ediyorlar?
Açık söyleyeyim: model emeklilikleri çoğu zaman teknik sebepten değil, ticari sebepten geliyor. Anthropic ile GitHub arasındaki lisans yapısı, üstüne yeni modeller geldikçe eskilerin maliyetinin GitHub tarafında anlamsızlaşması… işin düğümü burada. 4.8 hem performans hem maliyet tarafında muhtemelen daha dengeli dürüyor; eski modeli ayakta tutmak da bir noktadan sonra sadece operasyonel yük oluyor.
Bakın, Evet.
“Modeli kullanan herkes geçecek, bunda bir seçim yok. Asıl soru: 29 Haziran’a kadar yumuşak bir geçişi nasıl planlarsınız?”
Kurumsal Tarafta İşler Neden Karışık?
Copilot Enterprise tarafında model erişimi model policy denen bir mekanizmayla yönetiliyor. Yanı admin, “şu modele erişim açık, bu modele kapalı” diye organizasyon çapında politika veriyor. Güzel tarafı var, tabiî; güvenlik ve compliance için lazım. Ama işin komiği şu: tam da bu yüzden bazen gözden kaçıyor. Peki bunu neden söylüyorum? Hani, varlığı bile unutuluyor. Agents League Hackathon 2026: Enterprise Agents Kategorisi Rehberi yazımızda bu konuya da değinmiştik.
Yanı, Türkiye’deki kurumsal müşterilerimde gördüğüm tablo genelde aynı oluyor. Copilot lisansı alınıyor, ilk birkaç ay her şey açılıyor, sonra kimse model policy ekranına dönmüyor; ta ki bir geliştirici “hocam Opus seçemiyorum” diye yazana kadar. O noktada anlaşılıyor ki yeni model policy’de açılmamış, ya da başka bir grup kuralı araya girmiş. Bir de üstüne 4.8 tarafı var; varsayılan açık gelmeyebilir. 29 Haziran’dan sonra geliştiriciler hem 4.6’yı hem 4.8’i göremeyebilirler.
Admin tarafı için kontrol listesi
Yapılması gerekenleri sıralayayım. Önce şunu söyleyeyim, bunu Copilot CLI’da Akıllı Subagent Delegasyonu: Az Devretmek Daha İyi yazımdaki ajan modeli geçişlerinde de benzer şekilde düşünmek gerekiyor. Aynı dert, farklı ekran. Bu konuyla ilgili Microsoft Agent Framework: Katmanlı SDK Tasarımının İç Yüzü yazımıza da göz atmanızı tavsiye ederim.
- Copilot Settings → Policies altına gidin
- Opus 4.8 (fast)” politikasının durumuna bakın
- Etkin değilse açın, ama hangi gruplara vereceğinizi iyi düşünün
- Pilot bir kullanıcıyla test edin: VS Code Copilot Chat model seçicide görünüyor mu? (bu kritik)
- github.com tarafında da aynı kontrolü tekrar edin (iki ayrı UI var çünkü)
- İletişim mesajını hazırlayın — “29 Haziran’dan sonra Opus 4.6 kaybolacak, yerine 4.8 kullanın”
Bu listenin en kilit kısmı bence son madde. Teknik geçiş tamam, evet; ama insanların alışkanlığı başka mesele. Bir geliştirici dropdown’dan her gün 4.6’yı seçmeye alıştıysa, o seçenek bir sabah kaybolunca “Copilot bozuldu” diye ticket açması hiç şaşırtıcı olmaz.
Evet.
Vallahi, Neyse uzatmayayım, işin özü bu: policy tarafını sessiz bırakmayın, yoksa model değişimi teknikten çok iletişim problemine dönüyor.
Geliştiriciler İçin: Workflow Güncellemesi
Eğer sız de modeli sadece IDE içinden elle seçiyorsanız, açık konuşayım, çok kasmanıza gerek yok; dropdown’dan 4.8’i seçersiniz, biter gider. Ama iş biraz workflow’a, otomasyona ya da takım tarafındaki ayarlara kaydıysa, işte orada durup bir bakmak lazım. Daha fazla bilgi için RDBMS’ten Cosmos DB’ye Geçiş: AI Asistanı Ne Kadar İşe Yarar? yazımıza bakabilirsiniz.
- VS Code settings.json‘da model adı hardcode’lanmışsa
- GitHub Actions workflow‘larında Copilot CLI çağrılarında model parametresi varsa
- Custom chat participant veya tool extension yazdıysanız ve model adını referans alıyorsa
- Takım dokümantasyonunuzda “şu işi yapmak için Opus 4.6 fast’i seç” gibi yönergeler varsa (bence en önemlisi)
Bunlar ilk bakışta ufak tefek detay gibi dürüyor, ama özellikle son madde bayağı can sıkabiliyor. Wiki’de kalmış eski notlar var ya, Notion’da unutulmuş sayfalar, Confluence’ta tozlanmış yönergeler — itiraf edeyim, beklentimin üstündeydi —. Daha açık söyleyeyim, 29 Haziran’dan sonra öylece kalacaklar ve yeni gelen birinin kafasını gereksiz yere karıştıracaklar.
Çok konuştum, örnekle göstereyim.
Settings.json tarafında basit bir örnek göstereyim, ne demek istediğim daha net olsun:
{
"github.copilot.chat.defaultModel": "opus-4.6-fast",
"github.copilot.advanced": {
"model.preference": "opus-4.6-fast"
}
}Bunu şuna çevirmek gerekiyor:
{
"github.copilot.chat.defaultModel": "opus-4.8-fast",
"github.copilot.advanced": {
"model.preference": "opus-4.8-fast"
}
}Tek bir developer için bu iş otuz saniye sürer, hatta bazen daha az. Ama 50 kişilik ekipte herkesin kendi config’ını tek tek güncellemesini beklemek? Hmm, pek akıllıca değil; orada ya bir takım policy’si devreye girmeli ya da repo üzerinden dotfiles paylaşımı yapılmalı (bizzat test ettim)
Neyse, çok dağıtmadan devam edeyim. Hani Visual Studio 2026 Tema Renkleri: Artık IDE Sizin Dediğiniz Gibi yazımda IDE kişiselleştirmesinden bahsetmiştim ya, oradaki meseleyle bunun arasında bayağı benzerlik var: bireysel ayar mı olacak, yoksa takım standardı mı baskın gelecek? İkisi arasında denge kurmak kolay değil, açıkçası çoğu ekipte biraz sürtüşme çıkarıyor.
Türkiye Bağlamında: Maliyet ve Strateji
Şimdi biraz yerel taraftan bakalım, çünkü çoğu kişi tam burada konuyu hafife alıyor. Türkiye’deki kurumsal müşterilerimde Copilot Enterprise lisansı kullanıcı başına aylık 39 USD civarında geliyor; TL’ye vurunca da, bugünkü kurla, yaklaşık 1500 TL/kullanıcı/ay gibi bir yere oturuyor (buna dikkat edin). 100 kişilik bir geliştirici ekibi düşününce yıllık tablo kabaca 1.8 milyon TL ediyor. Az para değil.
Bu yatırımın geri dönüşü işe model seçimine baya bağlı. Yanlış model seçiyorsunuz, cevaplar ağırlaşıyor, geliştirici bekliyor, sonra sinirlenip Copilot’u kapatıyor, en sonunda da bütçe boşa gitmiş oluyor. Sahada bunu birkaç kez gördüm, hatta bir CTO arkadaşım düz söylemişti: “Lisansı aldık ama kimse kullanmıyor, çünkü bekleme süresi uzun.” E peki neden? Çünkü iş akışı tökezleyince kimse romantik davranmıyor.
Hmm, bunu nasıl anlatsamdı…
Opus 4.8 geçişinde özellikle üç noktaya bakmanızı öneririm:
- Pilot ölçüm yapın: Geçişten önce ve sonra en az bir hafta boyunca completion acceptance rate, chat oturum sayısı gibi metrikleri izleyin. GitHub’ın Copilot metrics API’si bunu sağlıyor; yanı körlemesine ilerlemeyin.
- Use case bazlı yönlendirme: Geliştiricilere hangi senaryoda hangi modeli seçmeleri gerektiğini anlatan kısa bir rehber hazırlayın. Bir sayfalık bir cheatsheet bile bazen şaşırtıcı derecede iş görüyor. — ciddi fark yaratıyor
- Fallback planı: Eğer 4.8 sizin senaryonuzda 4.6’dan daha kötü performans verirse, alternatif modellere (GPT, Claude Sonnet vb.) geçiş yolunu önceden test edin; yoksa kriz anında doğaçlama yapmaya kalırsınız. — bunu es geçmeyin
Startup vs Enterprise: İki Farklı Yaklaşım
Bu tip duyurularda en sevdiğim taraf şu: aynı haber, ölçeğe göre bambaşka bir şeye dönüşüyor. Küçük ekipte omuz silkip geçiyorsunuz, büyük yapıda işe herkes bir anda dosya açıyor; hani, olayın kendisi aynı ama etrafındaki gürültü resmen değişiyor.
Küçük ekip/startup iseniz
Tuhaf ama, Çok basit aslında. 29 Haziran’ı bir yere not edin, o gün dropdown’dan 4.8’i seçin. Yolunuza devam edin; belki takıma kısa bir Slack mesajı atarsınız, “yarın model değişiyor, panik yok” dersiniz, bu kadar. Süreç yönetimi mi? Evet, bazı yerlerde şart ama burada genelde gereksiz bir yük oluyor.
Kurumsal yapıdaysanız
Bak şimdi, Burada iş biraz farklı akıyor, açık konuşayım. Çünkü iç denetim. Bu ne anlama geliyor? Compliance ekipleri model değişikliklerini zaten izliyor olabilir, data residency politikalarınız varsa yeni modelin hangi region’da çalıştığını kontrol etmek gerekir (bazen gözden kaçıyor), SOC 2 ya da ISO 27001 gibi sertifikasyonlarınız varsa kullanılan AI modellerinin listesi de dokümante edilmiş olabilir; yanı evet, önü güncellemek lazım.
Bir dakika — bununla bitmedi.
- Internal audit ve compliance ekipleri model değişikliklerini takip ediyor olabilir
- Data residency politikalarınız varsa, yeni modelin hangi region’da çalıştığını kontrol etmek gerekiyor
- SOC 2, ISO 27001 gibi sertifikasyonlarınız varsa, kullanılan AI modellerinin listesi dokümante edilmiş olabilir — önü güncellemek lazım
- Yasal departman, modelin output kullanım haklarını yeniden değerlendirmek isteyebilir
Açıkçası bu liste bazılarına biraz abartılı gelebilir. Ama finans. Sağlık tarafında çalıştığım müşterilerde bunların hepsi gayet gerçek prosedürlerdi; “sadece bir model değişikliği” diye bakılan şey, bir bankada üç farklı komitenin önüne giden bir change request’e dönüşebiliyor (ve sonra kimse “neden bu kadar uzadı” diye şaşırıyor).
Daha Geniş Resim: Model Yorgunluğu Geliyor mu?
Bir gözlem bırakayım, çünkü işin rengi biraz oraya dönüyor. Son 18 ayda Copilot (söylemesi ayıp) tarafında model deprecation duyuruları bariz biçimde arttı; GPT-4, GPT-4o, Claude 3, Claude 3.5, Opus 4.x, Sonnet, Haiku… bir de bunların “fast” ve normal varyantları var, yanı liste uzadıkça uzuyor ve insanın model dropdown’ına bakası kaçıyor (şaşırtıcı ama gerçek)
İlginç olan şu ki, Bence GitHub bu konuda bir yerde yön değiştirmek zorunda kalacak. Ya kullanıcıdan model seçimini tamamen alıp “biz seçeriz, sen işine bak” çizgisine gelecekler (Copilot Chat’in bazı modlarında bunu zaten yapıyorlar), ya da rol bazlı varsayılan modeller koyacaklar; çünkü şu an hem kafa yoruyor, hem de bu emeklilik döngüleri durmadan yeni toplantı çıkarıyor. Açık konuşayım, beklediğim sadeleşme henüz gelmedi.
Bu konu sadece Copilot’la da sınırlı değil aslında. Şey, benzer dalga ajan tarafında da var; Claude Fable 5 Microsoft Foundry’de: Otonom Ajan Devri Başlıyor yazısında değindiğim gibi, otonom ajan modelleri de hızla değişiyor (bizzat test ettim). Eski sürümler kısa sürede kenara alınıyor. Yanı mesele tek bir ürün değil, sektörün tamamı böyle akıyor (bu beni çok şaşırttı)
Sıkça Sorulan Sorular
Opus 4.6 (fast) modeline 29 Haziran’dan sonra ne olacak?
Kısaca: tamamen erişilemez hâle geliyor. VS Code’da, github.com’da, Copilot CLI’da — hiçbir yerde göremeyeceksiniz. Eğer bir workflow’da model adı hardcode edilmişse, yanı direkt yazıldıysa, o çağrılar başarısız olacak ya da GitHub sizi varsayılan bir alternatife yönlendiriyor. Bence şimdiden kontrol etmek mantıklı.
Opus 4.8 (fast), 4.6 ile birebir aynı çıktıyı veriyor mu?
Açıkçası, hayır. Model versiyonları arasında her zaman ufak farklar oluyor — yanıt tarzı, kod stili, açıklama uzunluğu gibi şeyler. Çoğu durumda bu farkı pek hissetmezsiniz. Özellikle prompt engineering’i çok ince ayarlayan ekipler için durum biraz farklı. Tecrübeme göre bu ekiplerin kendi test setleriyle bir karşılaştırma yapması iyi olur.
Copilot Enterprise admin değilim, ne yapmam lazım?
Bireysel kullanıcıysanız aslında çok basit. IDE’nizdeki Copilot Chat dropdown’undan modeli 4.8’e çevirmeniz yeterli (yanlış duymadınız). Eğer settings.json’da hardcode’lu bir tercihiniz varsa önü da güncellemeniz gerekiyor. Başka bir şeye gerek yok.
Yeni model politikamda görünmüyorsa ne yapmalıyım?
Araya gireyim: Önce Copilot Settings → Policies altında “Opus 4.8 (fast)” politikasının etkin olup olmadığına bakın. Etkinse ve hâlâ görünmüyorsa, kullanıcı hesabınızın doğru organizasyona bağlı olduğunu ve lisans atamasının yapıldığını teyit edin. Yanı bazen sorun sadece lisans tarafında oluyor. Sız hiç denediniz mi? Hâlâ düzelmediyse GitHub Enterprise hesap yöneticinize ulaşmak en hızlı çözüm.
Bu geçiş için ne kadar süre ayırmalıyım?
Küçük bir ekipseniz mesela 1-2 saatlik bir iletişim ve dokümantasyon güncellemesi genellikle yeterli oluyor. 100+ kişilik organizasyonlarda işe pilot test, metrik karşılaştırması, dokümantasyon ve iç iletişim dahil 1-2 haftayı planlamak makul. Finans veya sağlık gibi kritik sektörlerde compliance onayları nedeniyle bu süreç 4-6 haftaya kadar uzayabiliyor — bence bu kısmı göz ardı etmemek gerekiyor.
Kaynaklar ve İleri Okuma
GitHub Changelog: Upcoming deprecation of Opus 4.6 (fast)
GitHub Copilot Resmî Dokümantasyonu: AI Modellerinin Seçimi
Bak şimdi, Copilot Enterprise Policy Yönetimi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder