Copilot Usage Metrics API ile Kullanıcı Bazlı AI Kredisi
GitHub Copilot kullanımını kullanıcı düzeyinde izleyen kurumlar için önemli bir veri daha erişilebilir hâle geldi. GitHub’ın 19 Haziran 2026 tarihli “AI credits consumed per user now in the Copilot usage metrics API” duyurusuna göre, kullanıcı bazlı Copilot raporları artık tüketilen toplam AI kredisi bilgisini de içeriyor.
GitHub’ın güncel örnek şeması bu alanı ai_credits_used olarak adlandırıyor. Alan, users-1-day ve users-28-day raporlarında kullanıcı başına toplam AI kredisi tüketimini incelemek için kullanılabiliyor. Ancak API akışındaki önemli bir ayrıntıyı baştan netleştirmek gerekiyor: rapor endpoint’inin ilk yanıtı ile indirilen raporun içeriği aynı şey değildir.
REST API çağrısı önce raporun indirilmesini sağlayan bir yanıt döndürür. Kullanıcı kayıtları ve ai_credits_used gibi kullanım alanları, bu yanıttaki bağlantı üzerinden indirilen raporun içinde bulunur. Bu nedenle endpoint çağrısından doğrudan kullanıcı metrikleri döneceğini varsayan entegrasyonlar yanlış sonuç verebilir.
Kullanıcı bazlı AI kredisi yeniliği nedir?
GitHub’ın değişiklik günlüğü, kullanıcı başına tüketilen toplam AI kredilerinin Copilot Usage Metrics API’ye eklendiğini belirtiyor. Güncel resmî örnek şemada bu değer ai_credits_used alanıyla gösteriliyor ve iki kullanıcı raporunda yer alıyor:
users-1-day: Belirli bir güne ait kullanıcı bazlı rapor.users-28-day: En güncel 28 günlük pencereyi kapsayan kullanıcı bazlı rapor.
Bu iki rapor hem organization hem de enterprise kapsamı için alınabiliyor. Organization endpoint’i yalnızca ilgili organizasyonun kapsamını, enterprise endpoint’i ise yetkili enterprise bağlamındaki raporu hedefliyor. Kullanılan token’ın izinleri kadar, isteği yapan hesabın ilgili organization veya enterprise içindeki rolü de erişimi etkiliyor.
Bu metrik tüketimi görünür kılar; tek başına fatura tutarını göstermez. Rapordaki değeri sabit bir çarpanla dolar veya TL tutarına dönüştürmek doğru değildir. Kesin mali kayıt için GitHub Billing verileri, geçerli fiyatlandırma kuralları ve kurumun faturası esas alınmalıdır.
Güncel organization ve enterprise endpoint’leri
16 Temmuz 2026 itibarıyla resmî GitHub REST referansında bu işlemler için kullanılacak API sürümü 2026-03-10 olarak doğrulanmıştır. İsteklerde aşağıdaki başlık bulunmalıdır:
X-GitHub-Api-Version: 2026-03-10
Organization kapsamındaki endpoint’ler şöyledir:
GET /orgs/{org}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
GET /orgs/{org}/copilot/metrics/reports/users-28-day/latest
Enterprise kapsamındaki karşılıkları ise şöyledir:
GET /enterprises/{enterprise}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
GET /enterprises/{enterprise}/copilot/metrics/reports/users-28-day/latest
Burada günlük ve 28 günlük rapor yolları aynı kalıbı kullanmaz. users-1-day endpoint’inin sonunda latest bulunmaz ve day query parametresi zorunludur. Buna karşılık en güncel 28 günlük rapor, users-28-day/latest yolu üzerinden istenir.
{org} yerine organization adı, {enterprise} yerine enterprise kısa adı yazılmalıdır. Görünen kuruluş başlığı ile API’nin beklediği slug her zaman aynı olmayabileceğinden, gerçek organization veya enterprise kısa adı kullanılmalıdır.
users-1-day raporu nasıl istenir?
Günlük raporda istenen tarih day query parametresiyle ve YYYY-MM-DD biçiminde gönderilir. Organization için örnek curl isteği şöyledir:
curl --request GET \
--url "https://api.github.com/orgs/ORGANIZATION/copilot/metrics/reports/users-1-day?day=2026-07-15" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer $GITHUB_TOKEN" \
--header "X-GitHub-Api-Version: 2026-03-10"
Enterprise kapsamında aynı tarih için yapılacak istek:
curl --request GET \
--url "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=2026-07-15" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer $GITHUB_TOKEN" \
--header "X-GitHub-Api-Version: 2026-03-10"
Örnekteki tarih yalnızca query parametresinin biçimini göstermek içindir. Otomasyonda ihtiyaç duyulan rapor günü açıkça hesaplanmalı ve isteğe eklenmelidir. day parametresini kaldırmak veya günlük rotaya /latest eklemek resmî endpoint sözleşmesiyle uyumlu değildir.
Token doğrudan komut dosyasına yazılmamalıdır. Yerel geliştirmede ortam değişkeni, otomasyon sistemlerinde ise erişimi sınırlandırılmış bir secret kullanılmalıdır. Hata günlüklerinde Authorization başlığının ve rapor indirme bağlantılarının görünmediği ayrıca kontrol edilmelidir.
users-28-day raporu nasıl istenir?
En güncel 28 günlük kullanıcı raporunda day query parametresi kullanılmaz. Organization çağrısı:
curl --request GET \
--url "https://api.github.com/orgs/ORGANIZATION/copilot/metrics/reports/users-28-day/latest" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer $GITHUB_TOKEN" \
--header "X-GitHub-Api-Version: 2026-03-10"
Enterprise çağrısı:
curl --request GET \
--url "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer $GITHUB_TOKEN" \
--header "X-GitHub-Api-Version: 2026-03-10"
Bu çağrılar, en güncel 28 günlük rapor için indirme sürecini başlatır. İlk HTTP yanıtını doğrudan kullanıcı tablosu olarak veri ambarına göndermek yerine, yanıttaki rapor indirme bilgisi işlenmelidir.
Endpoint yanıtı ile indirilen raporun farkı
Raporlama API’sinde iki ayrı veri katmanı vardır. Birinci katman, organization veya enterprise endpoint’ine yapılan çağrının yanıtıdır. Bu yanıt indirilebilir rapora ulaşmak için gereken bağlantıyı veya bağlantıları sağlar. İkinci katman ise bu bağlantı kullanılarak indirilen gerçek rapordur.
Sağlıklı bir veri hattı şu sırayı izlemelidir:
- Doğru kapsam ve rapor türü için GitHub REST endpoint’i çağrılır.
- HTTP durum kodu ve API yanıtı doğrulanır.
- Yanıttaki güncel rapor indirme bağlantısı alınır.
- GitHub’ın döndürdüğü bağlantı değiştirilmeden kullanılır.
- İndirilen dosyanın biçimi ve şeması kontrol edilir.
- Kullanıcı kayıtları ile
ai_credits_usedalanı rapor içinden okunur. - Ham dosya, rapor dönemi ve indirme zamanı bilgisiyle saklanır.
İndirme bağlantısının kalıcı olduğu varsayılmamalıdır. Zamanlanmış görev her çalıştığında önce REST endpoint’ini çağırmalı ve o çağrıdan dönen yeni bağlantıyı kullanmalıdır. Bağlantının sorgu parametrelerini silmek, yolu elle yeniden oluşturmak veya başka bir host adına dönüştürmek indirme işlemini bozabilir.
İlk yanıtı PowerShell ile incelemek için aşağıdaki örnek kullanılabilir:
$headers = @{
Accept = "application/vnd.github+json"
Authorization = "Bearer $env:GITHUB_TOKEN"
"X-GitHub-Api-Version" = "2026-03-10"
}
$uri = "https://api.github.com/orgs/ORGANIZATION/copilot/metrics/reports/users-1-day?day=2026-07-15"
$response = Invoke-RestMethod `
-Method Get `
-Uri $uri `
-Headers $headers
$response | ConvertTo-Json -Depth 10
Örnekte indirme bağlantısının JSON içindeki alan adı sabit kabul edilmemiştir. Önce gerçek API yanıtı incelenmeli, ardından bağlantı güncel şemadaki doğru alandan alınmalıdır. Böylece belgede veya yanıtta yapılabilecek bir değişiklik, entegrasyonun yanlış bir JSON yolunu sessizce kullanmasına neden olmaz.
ai_credits_used alanı nasıl doğrulanır?
GitHub’ın güncel örnek şeması alan adını ai_credits_used olarak gösteriyor. Buna rağmen üretim veri hattı yalnızca duyuru metnine güvenmemeli; indirilen gerçek raporun sütunlarını veya JSON anahtarlarını da doğrulamalıdır.
Önce dosyanın biçimi kontrol edilmelidir. Dosya uzantısını tahmin etmek yerine HTTP Content-Type başlığı ve dosyanın gerçek içeriği incelenebilir. İndirilen rapor JSON dizisiyse ilk kaydın alanlarını görmek için şu komut kullanılabilir:
jq 'if type == "array" then .[0] | keys else keys end' copilot-users-report
Şema ai_credits_used alanını içeriyorsa kullanıcı ve kredi alanlarını seçmek için, gerçek rapordaki kullanıcı alanının adı doğrulandıktan sonra uygun bir jq ifadesi yazılabilir. Kullanıcı alanını veya raporun üst seviye yapısını görmeden kurgusal bir JSON örneği üretmekten kaçınılmalıdır.
Rapor CSV biçimindeyse başlık satırında ai_credits_used sütunu aranmalıdır. Beklenen alan yoksa işlem başarılı kabul edilmemeli; rapor türü, API sürümü, tarih, yetki kapsamı ve indirilen dosya tekrar kontrol edilmelidir.
FinOps ve kullanım analizinde nasıl değerlendirilir?
Kullanıcı bazlı AI kredisi metriği, Copilot kullanımının ekip içinde nasıl dağıldığını anlamak için yararlı bir sinyaldir. Bununla birlikte yüksek tüketim otomatik olarak israf, düşük tüketim de otomatik olarak başarısız benimseme anlamına gelmez. Kullanıcının rolü, çalışma biçimi, rapor dönemi ve kullanım senaryosu birlikte değerlendirilmelidir.
Örneğin ajan tabanlı veya uzun bağlam gerektiren işlerde çalışan bir geliştiricinin tüketimi diğer kullanıcılardan yüksek olabilir. Bu durum tek başına olumsuz değildir. Benzer biçimde belirli bir günlük raporda sıfır görünen kullanıcı için “Copilot’u hiç kullanmıyor” sonucuna hemen varılmamalıdır. Daha geniş raporlama penceresi ve diğer kullanım metrikleri kontrol edilmelidir.
Kurumlar ai_credits_used verisini şu amaçlarla kullanabilir:
- Kullanımın organization, takım veya kullanıcı düzeyindeki dağılımını incelemek.
- Zaman içinde olağan dışı artış veya düşüşleri belirlemek.
- Benimseme eğitimi gerektiren ekipleri tespit etmek.
- Copilot kullanım metriklerini mühendislik sonuçlarıyla birlikte değerlendirmek.
- Bütçe kontrollerini planlarken talep eğilimlerini anlamak.
- Rapor alınamayan dönemleri gerçek sıfır tüketimden ayırmak.
Copilot kullanımını benimseme evreleriyle birlikte değerlendirmek için Copilot kullanımında cohort verisi ne anlatıyor? başlıklı yazıya bakabilirsiniz. Harcama kontrolü ve bütçe yönetimi ise farklı bir katmandır; bu konu GitHub Copilot bütçe ve kullanım yönetimi rehberinde ele alınıyor.
Yanlış yorumlardan nasıl kaçınılır?
ai_credits_used bir kullanım metriğidir; fatura satırı değildir. Alanın değerini sabit bir fiyatla çarparak kesin maliyet hesaplamak, plan ve faturalama kuralları doğrulanmadıkça yanıltıcı olabilir. Maliyet raporunda GitHub Billing kaynaklarıyla Usage Metrics raporları ayrı tutulmalı, aralarındaki fark açıkça belirtilmelidir.
Ayrıca mevcut alanın sağladığı ayrıntı düzeyinin ötesinde sonuç çıkarılmamalıdır. Kullanıcı toplamından belirli bir modelin, özelliğin veya Copilot yüzeyinin ne kadar tüketim oluşturduğu sonucu üretilemez. Böyle bir kırılım gerekiyorsa indirilen güncel rapor şemasında ilgili alanların gerçekten bulunup bulunmadığı kontrol edilmelidir.
Günlük raporun varlığı da gerçek zamanlı veri garantisi anlamına gelmez. GitHub’ın resmî belgelerinde belirtilmeyen kesin bir gecikme süresi vaat edilmemelidir. Veri hattında hem raporun temsil ettiği gün hem de dosyanın indirildiği zaman tutulmalıdır.
Kullanıcı düzeyindeki verilerin yönetişimi de önemlidir. Tüketim metriği kişisel performans puanı olarak kullanılmamalıdır. Amaç; benimseme, kapasite planlaması, eğitim gereksinimi ve olağan dışı kullanım değişimlerini anlamak olmalıdır. Erişim, saklama ve paylaşım kuralları kurumun güvenlik ve gizlilik politikalarıyla uyumlu hâle getirilmelidir.
Sık sorulan sorular
users-1-day endpoint’inde latest kullanılır mı?
Hayır. Günlük rapor yolu users-1-day ile biter ve day=YYYY-MM-DD query parametresini zorunlu olarak alır.
users-28-day raporunda tarih parametresi gerekir mi?
En güncel 28 günlük rapor users-28-day/latest yolu üzerinden istenir. Bu endpoint örneğinde day query parametresi kullanılmaz.
Organization ve enterprise için yollar farklı mı?
Evet. Organization çağrısı /orgs/{org}/, enterprise çağrısı ise /enterprises/{enterprise}/ ile başlar. Rapor türü ve günlük raporun tarih kuralı iki kapsamda da aynıdır.
Hangi GitHub REST API sürümü kullanılmalı?
16 Temmuz 2026 tarihinde doğrulanan resmî REST referansına göre isteklerde X-GitHub-Api-Version: 2026-03-10 başlığı kullanılmalıdır.
ai_credits_used doğrudan REST endpoint yanıtında mı bulunur?
Rapor endpoint’inin ilk yanıtı ile indirilen rapor birbirinden ayrılmalıdır. Kullanıcı metrikleri ve resmî örnek şemada gösterilen ai_credits_used alanı indirilen rapor içeriğinde incelenir.
ai_credits_used fatura tutarını gösterir mi?
Hayır. Bu alan kullanıcı bazlı tüketim metriğidir. Kesin mali kayıt için GitHub Billing verileri, geçerli fiyatlandırma ve fatura kullanılmalıdır.
İndirme bağlantısını veritabanına kaydedip yeniden kullanabilir miyim?
Kalıcı kullanım önerilmez. Otomasyon her çalıştığında ilgili rapor endpoint’ini yeniden çağırmalı ve GitHub’ın o istek için döndürdüğü güncel bağlantıyı kullanmalıdır.
Sonuç
Copilot Usage Metrics API’ye kullanıcı başına toplam AI kredisi bilgisinin eklenmesi, kurumsal kullanım analizini daha ayrıntılı hâle getiriyor. Ancak doğru sonuç için endpoint kurallarına eksiksiz uyulması gerekiyor: günlük raporda users-1-day yolu ve zorunlu day parametresi, 28 günlük raporda ise users-28-day/latest yolu kullanılmalıdır.
Organization ve enterprise çağrılarında X-GitHub-Api-Version: 2026-03-10 başlığını gönderin. İlk REST yanıtını kullanıcı raporu sanmayın; bu yanıttaki bağlantı üzerinden gerçek raporu indirin. Son olarak ai_credits_used alanını indirilen dosyanın güncel şemasında doğrulayın ve bu değeri fatura yerine kullanım analizi sinyali olarak değerlendirin.
Resmî kaynaklar
- GitHub Changelog: AI credits consumed per user now in the Copilot usage metrics API
- GitHub REST API: Copilot usage metrics — API version 2026-03-10
- GitHub Docs: Copilot usage metrics örnek şeması
Endpoint, zorunlu query parametresi ve API sürümü 16 Temmuz 2026 tarihinde GitHub’ın resmî REST belgeleri üzerinden kontrol edilmiştir. ai_credits_used alanı resmî örnek şemadan doğrulanmıştır; metriğin eklendiği bilgi GitHub’ın 19 Haziran 2026 tarihli değişiklik günlüğüne dayanır. Token izinleri ve indirilen rapor şeması uygulama sırasında canlı ortamda yeniden doğrulanmalıdır.







2 comments