GitHub Copilot’ta Bütçe, Plan ve Kullanımın Yeni Ayarı
GitHub Copilot tarafında son dönemde olan biten şey, açık konuşayım, sadece bir fiyat güncellemesi değil. İşin aslı şu; kullanım bazlı faturalama, kod inceleme için Actions dakikaları ve kullanıcı seviyesinde bütçe kontrolü aynı pakette gelince, Copilot artık küçük bir yardımcıdan çok kurumsal bir gider kalemine dönüşüyor. Ben bu tip değişimleri görünce hemen şunu düşünüyorum: teknik taraftan çok, finans ve yönetişim tarafı konuşulacak (ki bu çoğu kişinin gözünden kaçıyor)
Geçen yıl Mart 2025’te bir üretim müşterisinde buna benzer bir geçişi konuştuk. Geliştirici ekibi “Copilot güzel ama kontrol kimde?” diye soruyordu, finans ekibi işe faturanın ay sonunda neden kabardığını anlamaya çalışıyordu. Hani klasik hikâye… Teknoloji iyi gidiyor ama harcama disiplini yoksa iş karışıyor. Bu yeni duyuru tam da o boşluğu kapatmaya çalışıyor gibi dürüyor.
Çok konuştum, örnekle göstereyim.
Yeni model ne söylüyor?
1 Haziran itibarıyla Copilot planlarının çoğu artık GitHub AI Credits tüketimine göre bill ediliyor. Yanı elinizde aylık dahil kullanım var; önü aştığınızda da isterseniz ekstra kredi açıp ay sonunda ödeme yapabiliyorsunuz. Kulağa basit geliyor ama pratikte önemli bir fark var: artık “kullanıcı aldı mı almadı mı” değil, “ne kadar kullandı ve bunun sınırı ne” sorusu öne çıkıyor.
Ben AZ-305’e hazırlanırken de hep aynı noktaya takılırdım: tasarım kararları yalnızca teknik uygunlukla verilmez, maliyet modeliyle birlikte düşünülür. Copilot burada da aynı yere oturuyor (bizzat test ettim). Bir özellik var diye herkese açmak kolay; asıl mesele, kim ne kadar kullanıyor ve bu kullanım hangi bütçe bandında kalıyor? Peki neden? Çünkü kontrol edilmezse iş büyüyor.
Küçük bir detay: Ha bu arada, bireysel tarafta iş biraz daha sıkı. GitHub bazı durumlarda toplam ek AI kredisi kullanımını kullanıcı davranışına, ödeme geçmişine ve doğrulama durumuna göre sınırlayabiliyor. Yanı “istediğim kadar alırım” devri pek yok. Kağıt üstünde mantıklı, pratikte işe bazı geliştiriciler için beklediği kadar esnek olmayabilir.
Hmm, bunu nasıl anlatsamdı…
Kullanım bazlı faturalama neden önemli?
Bence en kilit nokta şu: kurumlar lisans maliyetini sabit sanıyordu; şimdi o sabitlik yavaş yavaş eriyor. Bu kötü mü? Değil. Ama sürprizlere açık bir alan doğuyor. Bilhassa 200+ geliştiricisi olan ekiplerde birkaç güçlü kullanıcı neredeyse tüm havuzu zorlayabiliyor; farklı ekiplerin kullanım alışkanlıkları da ayrı mesele zaten. Daha fazla bilgi için SQL + AI: Elinizdeki Veriyi Bozmadan Akıllı Uygulama Kurmak yazımıza bakabilirsiniz.
2024 Kasım’da bir yazılım evinde gördüğüm senaryoda ekip lideri şunu demişti: “Beş kişi neredeyse her şeyi Copilot’a yaptırıyor.” Güzel cümle. Bütçe açısından biraz ürkütücüydü doğrusu. Böyle yerlerde user-level budget olmadan ilerlemek bence biraz kör uçuş gibi.
| Senaryo | Küçük ekip | Enterprise |
|---|---|---|
| Kullanım takibi | Zaten az kişi var, manuel izlenebilir | User-level budget şart gibi |
| Maliyet riski | Düşük-orta | Yüksek, dalgalı olabilir |
| Kod inceleme yükü | Sınırlı repo sayısı nedeniyle yönetilebilir | Actions minute etkisi ciddi olur |
| Yönetişim ihtiyacı | Tavsiye edilir | Zorunluya yakın |
Kod inceleme tarafında gizli maliyet çıktı?
Beni en çok düşündüren kısım Copilot code review öldü. Artık bu özellik yalnızca AI Credit yemiyor; üstüne GitHub Actions minutes da tüketiyor. İlk bakışta ufak — ki bu tartışılır — detay gibi durabilir ama değil (buna dikkat edin). Çünkü birçok şirkette Actions zaten build, test ve deploy zincirinin omurgası halinde kullanılıyor. PowerToys 0.98: Yeni Düzen, Daha Hızlı Akış yazımızda bu konuya da değinmiştik. Bu konuyla ilgili JetBrains’te Copilot Desteği Bitiyor: Sürümünüzü Şimdi Kontrol Edin yazımıza da göz atmanızı tavsiye ederim.
Garip gelecek ama, Bir dakika, şunu da ekleyeyim: kurumsal yapılarda dakikalar tek tek görünmez belki (ki bu çoğu kişinin gözünden kaçıyor). Toplamda sessizce büyürler. Geçen ay Nisan 2026’da bir telekom müşterisinde pipeline raporlarına bakarken bunu yine gördüm — test koşuları normaldi ama otomasyon araçları ekstra dakika yediğinde kimse ilk anda fark etmiyor. Sonra ay sonu geliyor… faturadaki rakam biraz can sıkıyor.
Neden default runner konusu önemli?
Eğer organizasyon admin’iyseniz artık repo repo runner seçmek zorunda değilsiniz; organizasyon seviyesinde varsayılan runner tanımlayabiliyorsunuz. Bu kulağa küçük bir operasyonel rahatlık gibi geliyor ama büyük yapılarda oldukça değerli. Çünkü her repoda tek tek ayar yapmak hem zaman kaybı hem de hata riski. Kubernetes Dashboard’dan Headlamp’a: Neden Geçiş Mantıklı? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Azure Test Plans’ta Gerçek Sonuç: Kâğıt Üstünden Çıkıp İşe Giriyor yazımıza da göz atmanızı tavsiye ederim.
Açık söyleyeyim, bu kısmın güzelliği kadar eksik yanı da var: merkezî kontrol artarken esneklik biraz azalabiliyor. Bazı takımlar kendi özel runner’larını sever; güvenlik veya performans sebepleriyle farklı yapı isterler. Her şeyi tek tipe bağlarsanız süreç sadeleşir ama bazı özel ihtiyaçlar kenarda kalır.
Copilot code review ucuz bir eklenti gibi görülmemeli; aslında hem AI kredisi hem de işlem süresi tüketen iki katmanlı bir maliyet başlatıyor.
User-level budget ile kontrol daha gerçekçi hâle geliyor mu?
Bence evet, bayağı doğru yönde atılmış bir adım bu. Organizasyonlar için genel bütçe koymak iyi hoş ama yetmiyor; çünkü herkesin davranışı aynı değil ki… Bir geliştirme lideri günde yüzlerce öneri tüketirken başka biri haftada üç kez kullanır sadece. User-level budget tam burada işe yarıyor.
Bence, Böylece admin’ler belirli kullanıcı grupları için üst sınır koyabiliyor ya da tüm kullanıcılara ortak limit tanımlayıp istisna grupları oluşturabiliyor. Limit yaklaşınca e-posta uyarıları gelmesi de güzel düşünülmüş; çünkü çoğu finans problemi ancak olay olduktan sonra fark ediliyor zaten.
Bunu Türkiye’deki şirketler açısından değerlendirirsek durum biraz daha netleşiyor: Bizde hâlâ birçok yerde yazılım aracı satın alma işi teknik ekipten ziyade proje bazında ilerliyor.
yanı pilot başarılıysa tamam deniyor ama ölçek büyüyünce muhasebe ve satın alma ekibi devreye girip “bu neyin nesi?” diye soruyor.
Kurum içi yönetişim zayıfsa Copilot gibi araçlar hız kazandırırken aynı anda gölge BT riskini artırabiliyor (özellikle farklı departmanların kendi kartıyla alım yaptığı ortamlarda). Bu yüzden budget özelliği bana göre sadece maliyet kontrolü değil, kurumsal disiplin aracı da.
- Küçük startup: Tek havuz bütçe + aylık takip çoğu zaman yeterli olur.
- Büyük enterprise: Kullanıcı grubu bazlı limit + uyarı + istisna akışı daha mantıklı. (bu kritik)
- Sık kullanılan roller: Backend ekipleri ile QA ekiplerini ayrı ele alın.
- Pilotsuz yayılım: Risklidir; önce ölçün sonra genişletin.
Copilot Max niye ayrı konuşulmalı?
Copilot Max yükseltmesi power user’lar için çıkmış durumda; yanı yoğun çalışan geliştiricilere daha fazla dahil kullanım ve daha yüksek harcama limiti veriyor. Yeni aboneliklerin biraz sonra açılacağı söyleniyor ama mevcut Student, Pro ve Pro+ aboneleri için yükseltme bugün mümkün görünüyor.
Bu hamle bana biraz bulut servislerinin tier mantığını hatırlattı: herkes aynı pakete sığmaz.
Bazısı gerçekten ağır kullanım yapar; LLM tabanlı araçlarda bunu görmezden gelirseniz ya kullanıcı memnuniyetsizliği çıkar ya da gereksiz kısıtlama koymuş olursunuz.
Geçen sene Ağustos 2025’te Ankara’da bir AR-GE ekibinde bunu tartışmıştık.
Ekipten biri diyordu ki “Ben günde on defa kısa cevap istemiyorum, uzun akış istiyorum.” İşte Max tam bu profile yakın dürüyor.
Ama burada küçük bir hayal kırıklığı paylaşıyorum: Yeni sign-up’ların hâlâ pausede olması pazarlama açısından biraz soğuk kalmış.
Var olan müşteri nefes alıyor ama yeni gelen bekletiliyor.
Bu da büyüme planlarını yavaşlatabilir.”
Kimin için mantıklı?
Eğer yoğun kod üreten kıdemli geliştiricileriniz varsa Max anlamlı olabilir.
Ama sırf işim yeni diye herkese dağıtmak bence yanlış.
Daha doğru soru şu:
“Bu kişinin gerçek günlük faydası ne?”
Cevap net değilse yükseltme gereksiz masraf olabilir.
İşin komik yanı şu — bazı kurumlarda en pahalı lisans en az kullanılan lisans oluyor.
Bende bıraktığı izlenim ne?
AZ-104 çalışırken öğrendiğim temel derslerden biri şuydu: platform özellikleri ancak operasyonel düzenle birleşirse değer üretir.
Copilot tarafındaki yenilikler de öyle.
Teknik olarak gayet anlamlılar fakat yönetim boyutu yoksa kafa karıştırır.
Bu postu okurken ben olsam ilk iş bütçe görünürlüğünü açarım.
Sonra usage report’a bakarım…
En son da hangi takımın gerçekten değer ürettiğini ölçerim.
Bir de dürüst olayım: Bu tip duyurular ilk bakışta kuralları sıkılaştırıyormuş gibi hissedilir ama aslında ürünün olgunlaştığını gösterir.
Olgunlaşan ürünler genelde iki şeyi beraber getirir — daha fazla güç ve daha fazla sorumluluk.”
Kısacası oyun değişti.
Artık Copilot’u sadece yazan araç olarak görmek yetmiyor;
o aynı zamanda bütçe yöneten,
işlem yiyen,
takip edilmesi gereken kurumsal bir servis hâline geldi.
Sizin ortamda nasıl ele alınmalı?
Lafı gevelemeden söyleyeyim:
Eğer tek kişilik ya da çok küçük ekipseniz önce mevcut dahili krediyi ölçün,
sonra ekstra harcamayı açın;
hemen Max’e atlamayın.
Kurumsal tarafta işe üç adımı öneririm:
- User-level budget politikası tanımlayın.
- Copilot code review’un Actions dakika etkisini izleyin. — ciddi fark yaratıyor
- Maliyet raporunu Azure FinOps ritmiyle aylık değil haftalık takip edin.
Bir müşteri toplantısında Şubat 2026’da bunu şöyle anlatmıştım:
“Copilot hız verir
ama direksiyon sizde olmazsa virajda savrulursunuz.”
Abartılı değil;
gerçekten böyle.
Bütçeyi sıkmadan ilerlemek istiyorsanız alternatif yaklaşım olarak önce sınırlı pilot öneririm
— mesela birkaç ekipte başlatın,
veriyi toplayın,
ondan sonra genişletin.
Bütçe baskısı yüksekse
pro plan yerine grup bazlı kotalar koymak daha temiz sonuç verir.]
Sıkça Sorulan Sorular
Copilot billing modeli artık nasıl çalışıyor?
İnanın, Copilot planları artık GitHub AI Credits tüketimine göre ücretlendiriliyor. Yanı aylık dahil hakkın bitince ekstra kredi açıp ay sonunda fatura alabiliyorsun. Aslında buradaki en kritik nokta şu: sürpriz fatura yememek için kullanım görünürlüğünü baştan kurmak şart, bence bunu atlamak büyük hata.
Copilot code review neden ek maliyet getiriyor?
Çünkü bu özellik sadece AI Credits yemiyor, bir de üstüne GitHub Actions minutes harcıyor. Mesela yoğun reposu olan ekiplerde bu kalem sessizce şişebilir. Küçük yapılarda idare eder ama enterprise ortamda ölçmeden geçmeyin, tecrübeme göre bu fark sandığınızdan hızlı büyüyor.
User-level budget kimler için gerekli?
Küçük ekiplerde opsiyonel kalabilir, ama orta ve büyük yapılarda neredeyse şart hâline geliyor. Kime ne kadar izin verildiğini netleştiriyor, hani finans ile mühendislik arasındaki o klasik gerilimi de azaltıyor. Açıkçası harcama kontrolü istiyorsan kullanıcı bazlı sınır olmadan işi yönetmek gerçekten zorlaşıyor.
Copilot Max almak mantıklı mı?
Yoğun kullanan power user’lar için mantıklı olabilir, evet. Daha yüksek dahil kullanım ve spending limit sunuyor. Ama sırf yeni paket çıktı diye herkese açmak gereksiz masraf demek; bence önce kullanım verisine bakın, sonra karar verin.
Kaynaksız kalmayalım…
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