GitHub Copilot usage-based billing modeline geçtikçe herkesin sorduğu bir soru öne çıkıyor: “Değer üretmeye devam ederken maliyetin öngörülemez olmasını nasıl engellerim?” Microsoft Developer Community Blog’unda Gaurav Bhardwaj ve Dustin Ellis (Senior Cloud Solution Architect’ler), 12 maddelik pratik bir rehberle bu soruya cevap veriyor. Zihniyet değişikliği net: “Copilot kullanabilir miyim?” sorusundan “bu görev için doğru yeteneği, doğru modeli, doğru context’i ve doğru otomasyon seviyesini kullanıyor muyum?” sorusuna geçmek.
Yeni maliyet modelinin özü
Usage-based billing altında Copilot maliyetleri iki faktöre bağlı:
- Kullanılan model (frontier vs lightweight)
- Tüketilen token sayısı
En büyük maliyet sürücüleri:
- Basit görevler için pahalı modeller kullanmak
- Aşırı geniş context window’lar
- Aynı context’i tekrarlayan uzun chat oturumları
- Çok fazla dosyayı inceleyen agentic workflow’lar
- Gereksiz yere aktif edilmiş tool’lar
- Terminal log’ları veya tam repo scan’lerinin chat’e boşaltılması
- Aktif bütçe ve kullanım monitoring eksikliği
1. Önce harcama guardrail’lerini kur
İlk adım teknik değil, finansal yönetişim. Ağır kullanım başlamadan önce harcama cap’leri ve bütçe kontrolleri koyulmalı.
- Aylık bütçe ve mümkünse hard-stop kontrolleri
- Standart kullanıcı ve power user için ayrı limitler
- Kullanıcı, ekip, organizasyon ve cost center bazında granular takip
- İlk haftaların analizi ve limitlerin gerçek kullanıma göre ayarlanması
“One size fits all” bütçe kaçınılması gereken bir tuzak. Junior geliştirici ile platform mühendisinin bütçesi aynı olmamalı.
2. Görev başına doğru model
Her görev için en güçlü model gerekmiyor. Bu belki de usage-based billing’in en önemli zihniyet değişimi.
Hafif/ucuz modeller için ideal: Basit kod açıklamaları, dokümantasyon ve yorum güncellemeleri, küçük unit test üretimi, temel debug ve syntax yardımı, regex, tek dosya özet.
Güçlü/premium modeller için ideal: Mimari kararlar, kompleks debug ve multi-file reasoning, güvenlik odaklı review, legacy modernizasyon, performans tuning, belirsiz cross-service production sorunları, büyük PR review.
Ekip altın kuralı: “Görevi iyi yapabilecek en ucuz modelle başla. Derin reasoning gerekirse yukarı çık.”
3. Code completion’lara daha çok yaslan
Inline code completion ve next edit suggestion özellikleri, ücretli planlarda AI credit tüketmiyor. Ne istediğinizi zaten biliyorsanız chat yerine completion kullanmak ciddi tasarruf sağlıyor.
Kural: “Reasoning gerekiyorsa chat, hızlanma gerekiyorsa completion.”
4. Tool’ları sadece gerektiğinde aç
Tool’lar güçlü ama maliyeti çarpanlı büyütüyor. Her tool çağrısı daha fazla context, daha fazla model çağrısı ve daha fazla output demek. Amaç tool’ları yasaklamak değil, doğru scope’lamak.
- Her agent için her tool’u açmayın
- Specialized agent’lar oluşturun (dokümantasyon agent’ının terminal veya cloud DB erişimine ihtiyacı yok)
- Full scan yerine belirli dosya/klasör inspect edin
- Terminal output’ları özetletin, sayfalarca raw log yapıştırmayın
Cost-aware bir prompt örneği: “Tool’ları sadece gerekirse kullan. Belirttiğim dosyaları okumaya başla. Tüm repo’yu tarama. Test gerekirse sadece ilgili unit testleri çalıştır ve hatayı özetle, tam log’ları yapıştırma.”
5. Context window’u daralt
Context ancak ilgiliyse yararlı. Yaygın maliyet sürücüsü: geniş prompt’larla alakasız kod bloklarını oturuma çekmek.
Kötü: “Bu repo’yu analiz et ve bug’ı düzelt.” | İyi: “Bug muhtemelen /src/auth/tokenValidator.ts ve /src/auth/sessionStore.ts içinde. Sadece bu dosyaları ve ilgili testleri incele. En küçük güvenli fix’i öner.”
Konu değişince ya da compaction sık olunca yeni oturum aç. Devam etmek gerekiyorsa Copilot’tan Markdown özet çıkart, yeni temiz oturumun başına yapıştır.
6. Kompleks iş için plan-first prompt
Büyük refactoring, multi-file değişiklik, legacy modernization ve dependency upgrade için agent’ı doğrudan dosya editine bırakmayın. Önce plan isteyin.
Örnek: “Dosyaları düzenlemeden önce kısa bir plan çıkart. İncelemen gereken dosyaları, muhtemel kök nedeni, risk seviyesini ve en dar validation testini listele. Plan netleşene kadar değişiklik yapma.”
Bu, pahalı bir multi-step agentic loop başlamadan önce scope’u daraltma imkanı veriyor.
7. İlgili soruları tek oturumda batch’le
Her küçük soru için yeni chat açmak da context reload overhead’i yaratıyor. Dengeyi bulmak gerek: ilgili işleri tek konuşmada batch’le, ama tamamen farklı konuya geçince yeni chat aç.
8. Custom instruction’ları kısa tut
.github/copilot-instructions.md ve AGENT.md dosyaları güçlü, ama her prompt’a taban token olarak ekleniyorlar. Şişkin instruction gizli bir vergi gibi. Kısa, kural tabanlı tutun. Detaylı workflow’lar için lokal prompt dosyaları ve özel skill’ler kullanın.
9. Tekrarlanan iş için skill ve özel agent
Ekibiniz sık sık aynı workflow’u istiyorsa (API review, PR özet, Accessibility audit, Terraform check) yeniden kullanılabilir skill’ler, prompt file’lar veya custom agent’lara çevirin. Her seferinde “yeniden öğrenme” için token yakmayın.
10. Gereksiz agentic mode’u kullanma
Agent mode için: Multi-file bug fix, kompleks test suite üretimi, cross-file refactor, PR görevleri.
Chat/completion için: Basit syntax, tek dosya açıklama, küçük snippet, format tweak.
11. Kullanımı haftalık izle
Ölçmeden optimizasyon körlük. Haftalık review’da bakın:
- En yüksek hacimli modeller hangileri?
- Basit görevler için premium modeller mi kullanılıyor?
- Hangi ekip veya workflow bütçesini aşıyor?
- Tool kullanımı ya da uzun context history maliyeti mi şişiriyor?
Amaç yüksek kullanımı utandırmak değil, sistemik token israfını yok etmek.
12. Basit bir ekip politikası oluştur
- Önce completion, sonra chat
- Önce ucuz model, gerekirse frontier
- Belirli dosya/klasör mention et, kör repo scan yapma
- Büyük değişiklikten önce plan iste
- Tool ve custom instruction’ı sıkı scope’la
- Haftalık metrik review, aylık bütçe ayarı
Hazır cost-aware prompt şablonları
- Debug: “Sadece belirttiğim dosyaları kullanarak bu hatayı analiz et. Repo’yu tarama. Önce kök nedeni açıkla, sonra en küçük fix’i öner.”
- Agent mode: “Tool’ları sadece gerekirse kullan. Editten önce kısa plan çıkart. Sadece en dar testi çalıştır.”
- Code review: “Bu PR’ı correctness, security ve maintainability açısından incele. Sadece yüksek etkili sorunlara odaklan. Gerekmedikçe kod yazma.”
- Test: “Mevcut test stiliyle bu fonksiyon için unit test üret. Production kodunu değiştirme. Test scope’u dar tut.”
- Refactor: “Sadece bu dosyayı refactor et. Davranışı koru. Public API değiştirme. Düzenleme öncesi riski açıkla.”
- Büyük repo: “Repo’nun tamamını analiz etme. /src/payment ve /tests/payment ile başla. Scope’u genişletmeden önce sor.”
Copilot maliyeti optimizasyonu, AI’ı daha az kullanmak değil, daha iyi kullanmak. Daha küçük context, daha sıkı tool scope, daha temiz prompt ve doğru model seçimi sadece fatura düşürmüyor, modelin doğruluğunu da artırıyor. Alakasız dosyalar ve dağınık log’larla modeli bunaltırsanız, gürültü çıktının kalitesini de düşürüyor.
Yani cost optimization aslında bir engineering maturity pratiği. Doğru işletim modeliyle Copilot, güvenli hızlanmayı, boilerplate azaltmayı ve gerçek işe odaklanmayı sürdürüyor. Bu rehberin en pratik tarafı hazır prompt şablonlarını ekibin ortak wiki’sine koyup her geliştiricinin günlük iş akışına yerleştirmesi. Bir ekip için birkaç hafta içinde ciddi bir tasarruf ve daha odaklı çıktılar getirebilir.
