Şimdi açık konuşayım, GitHub’ın geçen hafta yayınladığı duyuruyu ilk gördüğümde önce bir yutkundum. Sonra hesap makinesini açıp birkaç müşteri senaryosunda kabaca rakam çıkardım (evet, doğru duydunuz). Sonuç? Panik yapacak bir şey yok ama hazırlıksız yakalanırsanız faturada sürpriz var. Lafı dolandırmadan girelim konuya.
Olay şu: 1 Haziran 2026’dan itibaren GitHub Copilot code review, sadece Copilot premium request birimini değil, aynı zamanda GitHub Actions dakikalarınızı da tüketmeye başlayacak (buna dikkat edin). Yanı şimdiye kadar “bedavaya geliyor” diye düşündüğünüz agentic code review, artık çift taraftan ücret yazıyor. Hmm, işte hayatı nokta burada.
“Public repo’larda hiçbir şey değişmiyor — Actions dakikaları orada hâlâ ücretsiz. Değişiklik neredeyse tamamen private repo’lardaki kullanım için.”
Ne Değişiyor, Tam Olarak?
GitHub geçen ay Copilot code review’ın artık agentic tool-calling mimarisi üstünde çalıştığını duyurmuştu. Yanı agent, sadece pull request diff’ine bakmıyor; repository’nın geneline göz atıyor, bağlam topluyor, ilgili dosyaları çekiyor. Sonra daha anlamlı yorum yapıyor. Fena değil. Ama bir bedeli var, işte o kısım biraz can sıkıcı. Bu altyapı GitHub Actions üzerinde, GitHub-hosted runner’larda dönüyor.
Çok konuştum, örnekle göstereyim.
Haziran 2026’dan sonra her code review iki ayrı kalemle faturalandırılacak:
- AI Credits olarak Copilot kullanımı: Yeni usage-based billing modeli kapsamında sayılacak. Bu zaten yavaş yavaş gelmesi beklenen bir şeydi.
- GitHub Actions dakikası tüketimi: Private repo’larda her review için planınızdaki dakikalardan düşecek. Dahil edilen dakikalar biterse, standart Actions tarifesi devreye giriyor.
Etkilenen planlar da net: Copilot Pro, Pro+, Business ve Enterprise. Lisanssız kullanıcıların review’ları da buna dahil (direct org billing üzerinden faturalandırılan senaryo yanı). Küçük ekip de etkileniyor, büyük kurum da; kaçış yok gıbı duruyor.
Neden Şimdi Bu Değişiklik?
İlginç olan şu ki, Bence sebep baya basit. Agentic mimarı, klasik prompt-response işinden daha pahalıya geliyor; agent her review’da repository’yi tarıyor, dosya açıyor, tool çağırıyor ve bunların hepsi compute tüketiyor. GitHub bu maliyeti bir yere yazmak zorundaydı — ya fiyatı yukarı çekecekti ya da yükü Actions tarafına kaydıracaktı. İkincisini seçmişler. Kağıt üstünde mantıklı duruyor ama pratikte ekiplerin çoğu zaten Actions dakikalarını dikkatli kullanıyor.
Açık konuşayım, Evet.
Neyse uzatmayalım; burada asıl mesele şu: bu değişiklik teknik olarak sürpriz değil. Bütçe tarafında küçük bir sızıntı yaratabilir. En çok da yoğun review yapan ekiplerde, hani fark etmeden dakikalar eriyip gidebilir.
Maliyet Etkisi: TL Bazında Düşününce
Size bir şey söyleyeyim, Geçen gün Logosoft’ta bir finans müşterimizin ortamına baktım — ayda yaklaşık 800 PR açılıyor, her birinde Copilot code review aktif. İlk bakışta “eh, idare eder” diyorsunuz (şaşırtıcı ama gerçek). Ama işin içine premium request değil de Actions dakikası girince tablo biraz garipleşiyor,. E peki, sonuç ne öldü? Haziran sonrası senaryoyu kabaca çıkarınca şu görüntü ortaya çıktı:
| Ekip Tipi | Aylık PR | Tahmini Actions Dakikası | Plan Yetersizliği Riski |
|---|---|---|---|
| Küçük startup (5 dev) | ~150 | ~300-450 dk | Düşük (Pro planında) |
| Orta ölçek (20 dev) | ~600 | ~1.200-1.800 dk | Orta (Business planında dikkat) |
| Enterprise (100+ dev) | 3.000+ | 6.000-9.000 dk | Yüksek (ek ödeme kesin) |
Rakamlar tahmini, çünkü GitHub her review’ın tam olarak kaç dakika tutacağını net söylemedi. Ama benim gördüğüm agentic review’lar genelde 1.5-3 dakika arası dönüyor; bazen hızlı bitiyor, bazen de nedense küçük bir repo’da bile uzayıp gidiyor, sonra siz oturup “bu kadar mı?” diye soruyorsunuz. Bunu PR sayısıyla çarpıp Actions dakikası yetkinizden düşeceksiniz.
Türkiye’deki Şirketler İçin Pratik Bakış
Şunu fark ettim: Peki neden bu kadar konuşuyorum? Çünkü Türkiye’deki kurumsal müşterilerimde Actions dakikası bütçesi çoğu zaman “set and forget” mantığıyla yönetiliyor. Yanı bir kez ayarlıyorsunuz, sonra kafanız rahat sanıyorsunuz. Bu değişiklikten sonra o rahatlık pek kalmıyor; özellikle dolar bazlı faturalanan Actions overage ücretleri, TL tarafı zayıflayınca bütçeyi resmen sarsıyor, geçen yıl bir e-ticaret müşterimizde yaşadığımız şey de buydu ve ay sonu faturasında neredeyse iki katına çıkan rakamı görünce ekip uzun süre sessiz kaldı.
Bunu biraz açayım.
Bence Türkiye’de bu duyurudan en çok etkilenecek kesim orta ölçekli yazılım şirketleri. Enterprise müşteriler zaten FinOps tarafında raporu açıyor, kırılımı izliyor, nerede ne yandığını az çok biliyor (bu beni çok şaşırttı). Startup’lar da çoğunlukla public repo ya da küçük private repo ile yürütüyor işi; yanı orada alan dar. Neden önemli bu? Asıl sıkıntı arada kalan ekiplerde, hani 30-100 developer bandındaki yapılarda — onlar için mesele sadece teknik değil, baya doğrudan nakit akışı meselesi oluyor.
Şöyle ki, Tam da öyle.
Self-Hosted Runner Alternatifi: Mantıklı mı?
Önemli bir nüans var. GitHub Copilot code review self-hosted runner’ları da destekliyor, ayrıca GitHub-hosted larger runner’ları da. Tarifesi ayrı, yanı işin maliyeti biraz başka yerden geliyor. Teoride kendi runner’ınızı ayağa kaldırırsanız, Actions dakikasını azaltabilirsiniz.
Ama dür bir saniye. Bu iş o kadar düz değil. Self-hosted runner kurmak demek, bir VM ya da Kubernetes pod altyapısı yönetmek (ve sonra onun kaprisleriyle uğraşmak), güvenlik patch’lerini takıp etmek, network tarafında private endpoint ile NSG. Firewall kurallarını düzgünce oturtmak, runner’ın ayakta kalmasını izlemek ve peak saatlerde tökezlememesi için auto-scaling mantığını da düşünmek demek.
Aslında, Bunların hepsi adam-saat. Evet. Eğer ekipte zaten Platform Engineering tarafı varsa, bu model gayet mantıklı gelebilir; ama tek başına çalışan bir DevOps mühendisiyseniz, açık konuşayım, bence GitHub-hosted tarafta kalıp Actions dakikası satın almak daha az yorar. Daha az baş ağrısı.
Kısa bir not düşeyim buraya. Bu konuyla ilgili Copilot Cloud Agent %20 Daha Hızlı: Custom Image Etkisi yazımıza da göz atmanızı tavsiye ederim.
Ufak Bir Hatırlatma: Larger Runner’lar Tuzak Olabilir
Eh, GitHub-hosted larger runner’lar var ya, 4-core, 8-core, 16-core seçenekleriyle geliyorlar; standart 2-core runner’a göre dakika başına fiyatları ciddi şekilde yukarı çıkıyor. Bir keresinde bir müşterinin pipeline’ında “performance için” 16-core runner açıldığını gördüm, hani ilk bakışta mantıklı gıbı duruyor ama aylık fatura kabaca 6 kat artmıştı. Code review için böyle bir şeye gerçekten ihtiyaç yok; standart runner baya iş görüyor. Siz de daha önce “ne ölür ne olmaz” diye larger runner ayarladıysanız, şimdi geri standarda çekmenin tam zamanı. Bu konuyla ilgili Kubernetes v1.36’da User Namespaces GA: Rootless Devri Geldi yazımıza da göz atmanızı tavsiye ederim. Gateway API v1.5: Stable’a Taşınan Özellikler ve Notlarım yazımızda bu konuya da değinmiştik.
Şimdiden Ne Yapmalısınız? Adım Adım Hazırlık
Haziran 2026 uzak gıbı duruyor, biliyorum. Ama bütçe tarafında iş öyle yürümüyor; planı bugün kurmazsanız, o tarih geldiğinde tablo biraz tatsız olabilir. Şu adımlarla ilerleyin:
1. Mevcut Kullanımı Ölç
Önce nerede olduğunuzu görün. GitHub Copilot usage metrics ve GitHub Actions metrics ekranlarına girin, sonra mevcut PR hacmini, ortalama review süresini ve Actions dakikası tüketimini çıkarın; yoksa elinizde sadece hissiyat kalır, o da çoğu zaman yanıltıyor.
2. Spending Limit Ayarlayın
Bak şimdi, bu kısım gerçekten kritik. GitHub Actions için bir budget cap koyun; hem kişisel hesaplarda hem organization seviyesinde bunu yapabiliyorsunuz. İsterseniz mevcut kullanımı CLI ile de çekersiniz:
# GitHub Actions kullanım raporu (CLI ile)
gh api /orgs/ORG_NAME/settings/billing/actions \
--jq '{total_minutes_used, included_minutes, total_paid_minutes_used}'
# Belirli bir repo için workflow run'larını sayı
gh api /repos/ORG_NAME/REPO_NAME/actions/runs \
--paginate --jq '.workflow_runs | length'Hani, Bu komutlar ay sonu sürprizlerini azaltıyor, hatta baya işe yarıyor. Bir cron job’a koyup haftalık alarm da kurabilirsiniz; küçük bir kontrol gıbı görünüyor. Sonra “neden fatura böyle çıktı?” sorusunu epey yumuşatıyor (şaşırtıcı ama gerçek) Daha fazla bilgi için CVE-2026-3854: git push Üzerinden GitHub’da RCE Vakası yazımıza bakabilirsiniz.
3. Code Review Politikanızı Gözden Geçirin
Peki her PR’da Copilot code review gerçekten gerekli mi? Emin değilim. Sanırım çoğu ekip burada fazla hevesli davranıyor; ben olsam şu ayrımı netleştirirdim:
- Production branch’lerine merge: Bence aktif olsun
- Feature branch’ler arası PR: Manuel tetikleme yeterli
- Documentation-only değişiklikler: Skip edin (path filter ile) (bence en önemlisi)
- Dependabot/auto-generated PR’lar: Skip edin
- Draft PR’lar: Vallahi skip
Yukarıda bahsettiğim o olay var ya, işte önü daha önce Copilot Chat Pull Request’lerde: Gerçekten Fark Yaratıyor yazımda senaryolarla açmıştım; isterseniz oradan devam edin,. Bazı ekiplerde kural koymak yetmiyor, neyin neden çalıştığını da görmek gerekiyor.
4. FinOps Süreçleri Kurulu mu?
Neyse, i̇lginç olan şu ki, Bunu özellikle Enterprise müşterilerime soruyorum (ben de ilk duyduğumda şaşırmıştım). GitHub Actions kullanımını cost center bazında raporluyor müsünüz? Hangı takım ne kadar tüketiyor biliyor müsünüz? Eğer cevap “hayır” işe, bu değişiklikten önce büyük ihtimalle Billing Usage Report’u CSV olarak export edip Power BI’a bağlayın; yoksa maliyet konuşurken herkes başka bir rakam söylüyor ve toplantı uzayıp gidiyor.
Neyse, çok dağıttım gıbı öldü ama konu tam buraya geliyor. Yeni GitHub PR Dashboard: Artık Varsayılan Geliyor yazısında PR analitiği için anlattığım mantıkla benzer bir yapı maliyet analitiğinde de kurulabilir; yanı mesele sadece veri toplamak değil, o veriyi takıma göre anlamlı hâle getirmek.
İşte tam da bu noktada devreye giriyor.
Enterprise vs Startup: Farklı Stratejiler
Burada tek bir kalıp yok. Hani herkes için aynı reçete varmış gıbı davranınca işler biraz dağılıyor, ekip yapınıza göre ayrı ayrı bakmak lazım, yoksa maliyet de kullanım da gereksiz şişiyor.
Küçük ekipseniz (1-10 developer): Hiçbir şeyi hemen kurcalamayın. Pro ya da Pro+ planındaki dahil dakikalar çoğu zaman yetiyor, açık konuşayım; sadece spending limit’i 0$ yapın ki yanlışlıkla overage’a düşmeyin, PR sayısı bir anda patlamaya başlarsa o zaman yeniden hesap yaparsınız.
Orta ölçek (10-50 developer): İşte burada tablo değişiyor. Mevcut Actions dakikası kullanımınızı bir kenara not (belki yanılıyorum ama) edin, üstüne code review yükünü de kabaca ekleyin, çünkü bazen dakika tarafı sakın görünür ama review trafiği sessizce faturayı büyütür; eğer dahil minutes’i aşacaksanız ya plan yükseltin ya da review politikasını sıkılaştırın. Azure DevOps Git Policy API: 10-15 Kat Hız Geldi yazısındaki branch policy mantığını GitHub tarafında da kullanabilirsiniz — review’ı sadece korumalı branch’lerde tetiklemek baya iş görüyor. Kubernetes v1.36 Controller Staleness: Artık Daha Az Acı yazımızda bu konuya da değinmiştik.
Enterprise (50+ developer): Self-hosted runner burada ciddi bir alternatif oluyor (ki bu çoğu kişinin gözünden kaçıyor). Neyse, en çok da de Azure’da Spot VM Scale Set üstünde runner havuzu kurarsanız, Actions dakikası maliyetinin %60-70 altına inebiliyorsunuz; ama dür bir saniye, bunun bedeli de var, bu altyapıyı ayakta tutacak ekip ve operasyon disiplini sizde olmalı, yoksa ucuz diye girip sonra uğraştırır.
Kısa bir not düşeyim buraya.
--ephemeral flag’ını ASLA atlayın.
Karşılaştığım Bir Sorun: Path Filter Tuzağı
Kendi deneyimimden konuşuyorum, Geçen hafta bir müşteride tuhaf bir şey gördük. Copilot code review bazı PR’larda hiç çalışmadı, bazılarında işe çalıştı; yanı düzenli bir desen yoktu, tam kafa karıştıran türden bir durumdu. Sebep de aslında basit gıbı duruyordu: workflow dosyasında paths-ignore ile **/*.md filtresi vardı, ama PR’lar markdown ile kod değişikliğini birlikte taşıyordu; GitHub da burada bazen tetikliyor, bazen sessiz kalıyor. İşin aslı biraz sinsiceydi.
Doğrusu, Peki neden? Çünkü bu tıp path filtreleri, özellikle karışık PR’larda, ilk bakışta mantıklı görünse de davranışı tahmin etmeyi zorlaştırıyor. Açık konuşayım, ben de ilk anda “tamamdır” dedim ama sonra loglara bakınca olayın öyle olmadığını gördüm; bazı durumlarda workflow kaçıyor, bazı durumlarda devreye giriyor. Yanı güvenmek pek iyi fikir değil.
Çözüm tarafında yolu değiştirdik. paths-ignore kullanmak yerine workflow’un içine guard clause koyduk, böylece karar mekanizması daha net öldü (ve en azından neyin neden çalıştığını anlayabiliyorsunuz):
on:
pull_request:
types: [opened, synchronize]
jobs:
copilot-review:
if: |
!contains(github.event.pull_request.labels.*.name, 'skip-copilot') &&
!github.event.pull_request.draft
runs-on: ubuntu-latest
steps:
— uses: github/copilot-code-review@v1Böyle kurunca label bazlı opt-out yapabiliyorsunuz, draft PR’ları da kenara alıyorsunuz. Fena değil yanı. Haziran 2026 sonrası bu tarz küçük görünen optimizasyonlar ciddi tasarruf sağlayacak; hani bugün “ne fark eder” dediğiniz şeyler var ya, yarın bayağı iş görüyor.
Evet.
Kişisel Görüşüm: Doğru Yönde Atılmış Bir Adım Ama…
Açık konuşayım — bu değişikliği prensipte mantıklı buluyorum. Agentic mimarı gerçekten daha pahalı,. Bu maliyetin transparent şekilde Actions dakikasına yansıması, fiyatları gizli gizli şişirmekten daha dürüst bir yol. Hani GitHub bunu yapmasaydı, muhtemelen sonra Copilot lisans ücretlerini direkt artırırdı; o zaman da iş iyice kontrol dışına çıkardı.
Yine de bir boşluk var. Per-review dakika maliyeti tam olarak ne olacak, şu an net değil. “GitHub-hosted runner’da çalışıyor” demek, Linux için dakika başı 0.008$ demek, tamam; (şaşırtıcı ama gerçek). Bir review ortalama kaç dakika sürüyor, 1 mi, 3 mü, 5 mi? Bunu bilmeden bütçe hesabı yapmak biraz fal bakmaya dönüyor. GitHub’ın yakında daha açık metrikler paylaşmasını bekliyorum, yoksa karanlıkta tahmin yürütmeye devam edeceğiz.
Bir de küçük bir sitemim var. Self-hosted runner kullananlar için herhangi bir indirim sinyali yok gıbı duruyor. Yanı altyapıyı zaten siz yönetiyorsanız, Actions tarafına da katkıyı siz veriyorsanız, Copilot AI Credits hâlâ tam fiyat gidiyor. Bak şimdi, burası biraz daha esneyebilirdi bence; en azından insanın içi rahat ederdi.
Sıkça Sorulan Sorular
Public repo’larda Copilot code review yine ücretsiz mi?
Evet, öyle. GitHub zaten net bir şekilde söyledi: public repo’larda Actions dakikaları ücretsiz kalıyor, yanı code review tarafında da sana ekstra bir maliyet çıkmıyor. Siz hiç denediniz mi? Aslında değişiklik tamamen private repo’ları etkiliyor, public tarafında bir şey değişmiyor.
1 Haziran 2026 öncesi yaptığım review’lar Actions dakikası yer mi?
Hayır. O tarihe kadar her şey eskisi gıbı işliyor — Copilot code review sadece premium request unit (PRU) allowance’ından düşüyor. GitHub Actions dakikalarına hiç dokunmuyor. Yanı şimdilik rahatça kullanabilirsin, telaşlanmana gerek yok.
Self-hosted runner kullanırsam yine dakika tüketir mi?
Hayır, self-hosted runner’larda GitHub-hosted runner dakikaları gitmiyor. Ama bence burada şunu da göz önünde bulundurmak lazım: bu sefer kendi compute maliyetini ödüyorsun, yanı VM, k8s pod falan. Hangisi daha ucuz? Açıkçası kullanım hacmine göre değişiyor — tecrübeme göre yüksek hacimlerde self-hosted genelde kazandırıyor.
Spending limit’i 0 yaparsam ne ölür?
Plan dahilindeki dakikalar bitince Copilot code review otomatik olarak durur. Sürpriz fatura yok, ama review’lar da çalışmıyor. Bence kritik branch’lerde bunu göze almak biraz riskli — mesela manuel review zorunluluğu gıbı bir fallback mekanizma kurman iyi ölür.
Mevcut Copilot premium request kullanımım da değişiyor mu?
Evet, değişiyor. Tüm Copilot kullanımı artık yeni usage-based billing modeli kapsamında AI Credits olarak ölçülecek. Hani bu sadece code review için değil — Copilot Chat ve diğer özellikler için de geçerli. Detaylar için GitHub’ın usage-based billing duyurusunu bir göz atmanı kesinlikle öneririm, oldukça açıklayıcı.
Kaynaklar ve İleri Okuma
GitHub Resmî Duyurusu: Copilot Code Review & Actions Minutes
GitHub Actions Faturalandırma Resmî Dokümantasyonu
Şunu söyleyeyim, Copilot Code Review Kullanım Kılavuzu
Self-Hosted Runner Yapılandırma Rehberi
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.
