Copilot Usage Metrics API’ye ai_credits_used Geldi: FinOps İçin Ne Anlama Geliyor?
Kendi deneyimimden konuşuyorum, Şimdi açık konuşayım: GitHub’ın Copilot tarafında attığı her küçük adımı elimden geldiğince izliyorum, çünkü kurumsal müşterilerde en çok kafa karıştıran konulardan biri AI maliyetleri oluyor. Geçen hafta GitHub blog akışında minicik bir changelog notu gördüm — “AI credits consumed per user now in the Copilot usage metrics API”. Başlık sade, içerik kısa. Ama işin aslı, bu bence görünenden daha büyük bir hamle.
Bak şimdi, Neden mi? Çünkü FinOps tarafında çalışan herkesin bildiği o meşhur kural var: ölçemediğin şeyi yönetemezsin. Evet, bu kadar net. Şimdiye kadar Copilot’un AI bir düşüneyim… credit tüketimi kullanıcı bazında günlük olarak dışarıya düzgünce açılmıyordu; faturalama tarafında toplu rakamlar vardı, tamam,. “Hangi developer ne kadar credit yakıyor, hangi takımda yoğunluk var?” sorusuna cevap vermek için çoğu zaman elde hesap yapmak gerekiyordu, biraz da tahmin yürütüyorduk.
Neyse, lafı gevelemeden devam edelim. Gelelim teknik tarafa.
Olay Tam Olarak Ne? Yeni Alan Ne İşe Yarıyor?
GitHub, Copilot usage metrics API’ye ai_credits_used diye yeni bir alan ekledi. Bu alan, kullanıcı bazlı raporlarda her kullanıcının o gün ne kadar AI credit tükettiğini gösteriyor. Veri kaynağı da öyle bambaşka bir şey değil; usage-based billing API‘nın kullandığı tüketim verisinden türetiliyor. Yanı en azından faturayla kavga eden iki ayrı sayı görmüyorsunuz.
Alan iki yerde çıkıyor:
users-1-day— Tek günlük kullanıcı raporuusers-28-day— Son 28 günün kullanıcı bazlı dökümü
Hem enterprise hem de organization seviyesinde erişilebiliyor. Yanı büyük şirketlerde merkezî BT ekipleri tüm enterprise’ı görebilirken, organization owner’lar da kendi kapsamındaki veriyi çekebiliyor. Güzel tarafı bu. Ama dur bir saniye — burada her şey pembe değil.
Ama Bir Saniye — Şunu Net Söyleyeyim
Bu rakam fatura değildir. GitHub’ın kendi notunda da bunu açıkça söylüyor: “metrics signal for analyzing consumption, not a billed total”. Yanı buradan gördüğünüz toplamı alıp invoice’a yapıştıramazsınız. Faturalama hâlâ ayrı kanaldan geliyor ve kendi hesabını yapıyor. Bu alan tamamen analitik amaçlı (kendi tecrübem)
Bir de şu detay önemli: ai_credits_used kullanıcının toplam tüketimini gösteriyor. Hangi özelliğe (chat, code completion, code review, agents), hangi modele (GPT-5, Claude, Gemini vs.), hangi yüzeye (IDE, CLI, web) gittiğine dair bir kırılım henüz yok. Ben şahsen o kırılımı bekliyorum; çünkü gerçek FinOps iyileştirmeu için lazım olan şey tam da bu. Ama ilk adım olarak da fena değil doğrusu.
Neden Önemli? Bunu Türkiye Bağlamında Anlatayım
Yıllardır Azure. Microsoft 365 tarafında danışmanlık yapıyorum; son dönemde de Copilot tarafı işin epey büyük bölümünü kaplıyor. Türkiye’deki kurumsal müşterilerde değişmeyen bir gerçek var: bütçe konuşuluyorsa iş birim bazına kadar iniyorlar. CFO’nun ya da CIO’nun masasına “şu kadar AI credit harcadık” demek yetmiyor. “Hangi takım, hangi developer, hangi proje?” sorusu büyük ihtimalle geliyor. Kaçamıyorsun.
Şimdiye kadar bu sorulara cevap verirken biraz tahmin tabanlı ilerliyorduk. ai_credits_used alanı bu boşluğu ciddi ölçüde kapatıyor. Artık her developer için günlük tüketim rakamı var; üstüne bir de faturalama verisiyle aynı kaynaktan geldiği için uyumsuzluk ihtimali düşük.
Türkiye’deki orta-büyük ölçekli yazılım organizasyonlarında en sık duyduğum cümle şu: “Copilot’a aylık ne ödediğimizi biliyoruz da, kimin işine yarıyor önü bilmiyoruz.” İşte bu yeni metrik, tam olarak o sorunun cevabı için iyi bir başlangıç.
Üç Somut Kullanım Senaryosu
Yanı, GitHub kendi blog notunda üç başlık vermiş ama ben biraz genişleteceğim; çünkü sahada uygulama kısmı teoriden daha çetrefilli oluyor.
1. Tüketimi değerle eşleştirmek. Aynı raporlarda zaten kod tamamlama kabul oranları, chat etkileşimi gibi metrikler var. Şimdi bunların yanına credit tüketimi de geldi. Yanı “Falanca developer çok credit harcıyor ama kabul oranı düşük” gibi bir tespit yapmak mümkün hâle geliyor. Ya da tam tersi — “Bu takım az credit harcıyor ama PR throughput’u uçmuş” gibi sonuçlar çıkabiliyor.
Şimdi gelelim işin can alıcı noktasına.
Hani, 2. Adoption analizi. Hangi takımda Copilot gerçekten benimsenmiş, hangisinde sadece lisans verilmiş ama kimse dokunmamış? Credit tüketimi 0 olan bir kullanıcı büyük ihtimalle Copilot’u açmıyor bile. Bu da lisans optimize etmeu için baya işe yarayan bir sinyal. Kullanılmayan koltukları geri alıp ihtiyacı olana vermek artık daha kolay olacak.
3. Bütçe planlaması. Usage-based billing modeline geçtiğinizde ya da geçmeyi düşünüyorsanız gün gün tüketim trendini izlemek can alıcı hâle geliyor (ciddiyim). Aksi hâlde ay sonunda gelen fatura sürprize dönüşüyor. Açıkçası en hayatı kullanım alanlarından biri bu.
Peki API’yi Nasıl Çağırırız?
Bilgiyi soyut bırakmayalım; somut örnekle gidelim. Enterprise seviyesinde 28 günlük kullanıcı raporunu çekmek için kabaca şöyle bir çağrı yaparsınız:
GET /enterprises/{enterprise}/copilot/metrics/users-28-day
Authorization: Bearer <PAT_with_manage_billing:copilot_scope>
Accept: application/vnd.github+json
X-GitHub-Api-Version: 2022-11-28Cevap olarak gelen JSON’da her kullanıcı için artık ai_credits_used alanı bulunacak. Yapı kabaca şöyle:
{
"date": "2026-06-18",
"user_login": "ahmet.developer",
"ai_credits_used": 142.5,
"code_suggestions": {... },
"chat_interactions": {... }
}Bunu Power BI’a, Grafana’ya ya da kendi data warehouse’unuza akıttığınızda işin rengi değişiyor. Ben genelde müşterilere şunu öneriyorum: ham veriyi Azure Data Explorer’a ya da Log Analytics workspace’e atın, üstüne KQL ile rapor kurun; çünkü ham GitHub API çağrısıyla CFO’nun kapısını çalamazsınız, görselleştirme şart oluyor.
Tek Tabloya Neleri Koymalı?
Küçük ama faydalı bir öneri vereyim: aşağıdaki gibi bir özet tabloyu haftalık olarak yöneticilere gönderirseniz, “Copilot işe yarıyor mu?” sorusu daha sağlam zeminde konuşulur.
| Takım | Aktif Kullanıcı | Total AI Credit | Dortadaki Kabul Oranı | Kullanıcı Başına Credit |
|---|---|---|---|---|
| Backend | ||||
| Frontend | ||||
| Mobile | ||||
| Data/ML |
Bakınca tablo kendi hikayesini anlatıyor aslında; Data/ML takımının kullanıcı başına 230 credit harcadığını ama kabul oranının da %52 olduğunu görüyorsunuz. Yanı harcama yüksek ama karşılığında değer üretiyor gibi dürüyor no comment., Mobile takımı işe hem az harcıyor hem de kabul oranı düşük — burada adoption problemi olabilir denebilir., İşte bu tür içgörüler için bu metrik altın değerinde diyebilirim.
Enterprise vs Startup: Strateji Farklı Olmalı mı?
Burası önemli; çünkü “herkese uyan tek yöntem” diye bir şey yok bu işte.
Küçük ya da orta ölçekli ekip iseniz (mesela 20-50 developer), işi fazla dallandırıp budaklandırmaya gerek yok bence., API’den haftada bir veri çekip basit bir Google Sheet’e ya da Excel’e atın ve outlier’ları yakalayın (yanı anormal yüksek ya da düşük tüketimleri). Genelde sorun oralarda saklanıyor zaten., Çok parlatmaya gerek yok; çoğu zaman tablo kendini ele veriyor.
Büyük ölçekteseniz (yüzlerce hatta binlerce developer), iş biraz sertleşiyor., Burada şunları yapmanızı öneririm:
- API verisini düzenli olarak (günlük cron) bir veri ambarına çekin;
- Anomali tespiti kurun — mesela bir kullanıcının tüketimi 7 günlük ortalamasının 3 katına çıkarsa alarm üretin;
- Aylık FinOps review toplantılarının içine bu raporu sokun.
İkinci grupta lisans optimize etmeu da ciddi konu oluyor., Bizim sahada gördüğümüz tipik tablo şu:, büyük organizasyonlarda Copilot lisansı verilmiş ama hiç açmamış yüzde 10-20 arası bir kullanıcı kitlesi var., Bunu artık net biçimde tespit edebilirsiniz., Lisansları geri çekip aktif kullanıcılara dağıtmak direkt maliyet düşürüyor.; Evet., bu kadar basit olabilir bazen.
Türkiye’de Maliyet Boyutu: TL Bazında Düşünmek
Daha açık söyleyeyim, kendi deneyimimden konuşuyorum, Kur dalgalanmaları yüzünden Türkiye’deki BT bütçeleri zaten yeterince stresli., Copilot Business ya da Enterprise lisansları dolar bazlı;, üstüne usage-based AI credit ücretleri de devreye giriyor., Böyle olunca credit tüketimini gerçek zamanlı izlemek ay sonu sürprizlerini önlemek için önemli hâle geliyor., Peki neden? Çünkü kur oynadıkça aynı kullanımın TL karşılığı başka yere gidiyor.
Bir öneri vereyim:, API’den çektiğiniz veriyi anlık kur ile çarpıp TL bazlı dashboard kurun., Yöneticiye “bu ay şimdiye kadar X TL harcadık;, ay sonuna kadar tahmini Y TL olacak” diyebilmek bütçe yönetiminde baya işe yarıyor., Bunu GitHub Code Quality artık ücretli: Kurumlar neyi hesap etmeli? yazımda farklı bir bağlamda değinmiştim — GitHub tarafındaki tüm fiyatlandırma değişiklikleri tek tek küçük görünüyor ama toplandığında ciddi bir maliyet kalemi oluyor., Açık konuşayım;, mesele tek ürün değil;, paket halinde etkisi büyüyor.
Eksiklikler ve Beklentiler — Tarafsız Bir Değerlendirme
Şimdi madalyonun diğer yüzü., Bu güncelleme kağıt üstünde iyi dursa da pratikte hâlâ eksikler var., Açık söyleyeyim;, beklediğim kadar oturmuş değil bu özellik.; Hmm,, evet,, biraz erken aşamada dürüyor.
Feature kırılımı yok., Bir kullanıcının credit’lerinin ne kadarı code completion’a;, ne kadarı agent çağrılarına;, ne kadarı chat’e gidiyor göremiyoruz., Halbuki gerçek optimizasyon için lazım olan şey tam burada saklı., Mesela bir developer’ın creditlerinin yüzde 80’i agent çalıştırmaktan geliyorsa bu başka hikâye;, yüzde 80’i basit autocomplete’ten geliyorsa bambaşka hikâye olur.
Model bazlı kırılım yok., Hangi model ne kadar credit yakıyor bilmiyoruz., Bu önemli çünkü Claude Opus ile GPT-5’in kredi ağırlığı aynı değil.; Hangi modelin ne kadar kullanıldığını görmek ve model seçimi politikası belirlemek gerekiyor., Bu konuda Opus 4.6 (fast) Emekli Oluyor: Copilot Kullanıcıları Ne Yapmalı? yazımda model değişimlerinin maliyet etkisine değinmiştim.
Bunu biraz açayım.
Real-time değil., Veri günlük geliyor yanı anlık tüketim spike’larını yakalamak için uygun sayılmaz., Bütçe alarmı kuracaksanız en azından 24 saatlik gecikmeyle çalışacaksınız.; İdare eder mi? Eder,, ama anlık refleks beklemeyin.
Pratik Yol Haritası: İlk Hafta Ne Yapmalı?
Bu özelliği görüp “Güzelmiş;, sonra bakarım” deyip rafa kaldırmayın., İlk hafta için somut adımlar şunlar olabilir:
- Gün 1-2:, Yetkili bir PAT oluşturun;, API’yi Postman ya da curl ile test edin.;
users-28-day - Gün 3-4:, Veriyi parse eden basit bir Python ya da PowerShell scripti yazın ve CSV’ye atın.
- Gün 5:, Bu CSV’yi Power BI’a;, Excel’e ya da Grafana’ya bağlayın.; Takım bazında kullanıcı başı ortalama tüketimi görselleştirin.
- Gün 6-7:, Outlier’ları (çok yüksek ve çok düşük tüketimler) listeleyin ve yöneticilerle paylaşıp gerekçeleri konuşun.
–>
Sıkça Sorulan Sorular
ai_credits_used alanını faturalama için kullanabilir mıyım?
Şöyle söyleyeyim, Hayır, kullanamassın. GitHub bu konuda zaten net bir şekilde söylüyor: bu alan aslında analitik amaçlı bir sinyal, yanı faturalanmış toplam değil. Resmî fatura için billing API’yi ve invoice’ları referans alman gerekiyor. İki rakam birbirine yakın çıkıyor ama %100 örtüşme garantisi yok.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Hangi özelliğin ne kadar credit harcadığını görebilir mıyım?
Şu an için hayır. ai_credits_used tek bir toplam değer veriyor; feature, model ya da yüzey (IDE/CLI/web) bazında kırılım sunulmuyor. Açıkçası bence GitHub yakın gelecekte bu kırılımı ekleyecek, çünkü kullanıcı talebi ortada. Ama şimdilik sadece toplam var.
Veriler ne sıklıkla güncelleniyor?
Raporlar günlük bazlı. Yanı gerçek zamanlı izleme için pek uygun değil — en az 24 saatlik bir gecikme söz konusu. Anlık spike alarmı kurmak istiyorsan bu API’ye değil, mesela organization seviyesi spending limits gibi başka mekanizmalara bakman lazım.
Hangi yetki seviyesi gerekiyor?
Enterprise admin ya da organization owner olman gerekiyor (buna dikkat edin). Bunun yanında Copilot usage metrics’e REST API üzerinden erişmek için uygun PAT scope’larını da almak şart. Normal bir developer bu endpoint’lere erişemiyor — ki tecrübeme göre maliyet verisi olduğu için bu aslında gayet doğru bir tasarım kararı.
Şimdi gelelim işin can alıcı noktasına.
Bu özellik en çok hangi senaryoda işe yarıyor?
Usage-based billing modeline geçmiş ya da geçmeyi düşünen kurumlar için kritik bir şey bu. Hani sabit lisans — ki bu tartışılır — modelinde tüketim verisi “sadece bilgi” iken, kullanım bazlı modelde direkt bütçeyi etkiliyor. 100’den fazla developer’ı olan organizasyonlarda kullanıcı bazlı izleme şart, daha küçük ekiplerde işe toplam metrikler de yeterli olabiliyor.
Kaynaklar ve İleri Okuma
GitHub Changelog: AI credits consumed per user now in the Copilot usage metrics API
GitHub REST API: Copilot Metrics Documentation
About Billing for GitHub Copilot — Usage-Based Pricing
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