GitHub Copilot Bütçe ve Harcama Limiti Yönetimi
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)
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.
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.
2 comments