GitHub Agentik İş Akışlarında Token Kullanımını %30’a Kadar Azaltma Yöntemleri

GitHub’daki Agentik İş Akışları, repository’lerdeki küçük hataları otomatik olarak temizleyerek geliştirici verimliliğini önemli ölçüde artırıyor. Ancak bu akışların arka planda sürekli çalışması, token tüketimini de beraberinde getiriyor. Özellikle otomatik olarak tetiklenen CI görevleri, fark edilmeden yüksek maliyetlere yol açabiliyor.

Neyse ki, agentik sistemlerin token verimliliğini artırmak, masaüstü etkileşimli oturumlardakinden çok daha öngörülebilir ve kontrol edilebilir durumda. Agentik iş akışları, YAML dosyalarında tam olarak tanımlanmış görevleri tekrar tekrar yürütüyor. Bu da onların optimize edilmesini kolaylaştırıyor. Nisan 2026’dan itibaren, GitHub kendi repository’lerinde kullandığı yüzlerce agentik iş akışının token tüketimini sistematik olarak iyileştirmeye başladı. Bu süreçte yapılan geliştirmeler ve elde edilen ilk sonuçlar, geliştiriciler için önemli bir rehber niteliğinde.

Token Tüketimini Ölçmek: İlk Adım

GitHub, yüzlerce agentik iş akışını kendi repository’lerinde hem bakım hem de CI süreçleri için kullanıyor. Bu akışlar, GitHub Actions üzerinden gerçek API hız sınırlarına (rate limits) tabi olarak çalışıyor. Geliştiriciler olarak, "uçağı uçururken yakıt ikmali" yapmaya çalışıyoruz.

Token tüketimini optimize etmeye başlamadan önce, hangi tokenların ne şekilde harcandığını anlamak gerekiyordu. İlk zorluk, farklı agent framework’lerinin (Claude CLI, Copilot CLI, Codex CLI) farklı log formatlarında veri üretmesiydi. Geçmiş yürütmelerdeki kullanım verileri ise eksik olabiliyordu. Neyse ki, agentik iş akışlarının güvenlik mimarisi, agent’ların doğrudan kimlik doğrulama bilgilerine erişmesini engelleyen bir API vekil sunucusu (proxy) kullanıyordu. Bu vekil, tüm agent framework’lerinden bağımsız olarak token kullanımını tek bir normalleştirilmiş formata dönüştürdü.

Her iş akışı artık token-usage.jsonl adlı bir yapıt (artifact) üretiyor. Bu dosya, her API çağrısı için bir kayıt içeriyor: girdi token sayısı, çıktı token sayısı, önbellek okuma/yükleme tokenları, kullanılan model, sağlayıcı ve zaman damgaları. Bu veriler, diğer loglarla birleştirildiğinde, token tüketiminin tarihsel olarak nasıl gerçekleştiğini gösteriyor ve gelecekteki optimizasyonlara ışık tutuyor.

İş Akışlarını Optimize Eden İş Akışları

Token verilerine sahip olduktan sonra, iki yeni günlük optimize iş akışı geliştirildi.

Birincisi, Günlük Token Kullanım Denetçisi olarak adlandırılıyor. Bu iş akışı, yakın geçmişteki yürütmelerden gelen token kullanım verilerini okuyor, tüketimi iş akışı bazında birleştiriyor ve yapılandırılmış bir rapor oluşturuyor. Amacı, son dönemde token tüketiminde önemli artış gösteren iş akışlarını işaretlemek, en maliyetli olanları ortaya çıkarmak ve olağandışı yürütmeleri (örneğin normalde dört LLM adımında tamamlanan bir iş akışının 18 adımda bitmesi) tespit etmektir.

Denetçi bir iş akışını işaretlediğinde, Günlük Token Optimizörü devreye giriyor. Bu optimize edici, iş akışının kaynak kodunu ve yakın geçmişteki loglarını inceleyerek, somut verimsizlikleri ortaya koyan ve spesifik optimizasyon önerileri sunan bir GitHub issue oluşturuyor. Optimizör, elle tespit edilmesi zor birçok verimsizliği bulmayı başardı.

Tabii ki, Denetçi ve Optimizör de agentik iş akışları olarak çalışıyor. Bu da onların kendi token tüketimlerinin de günlük raporlara dahil edilmesiyle küçük bir olumlu döngü yaratıyor.

Kullanılmayan MCP Araçlarının Kaldırılması

İlk Denetçi ve Optimizör sonuçlarına göre, en yaygın verimsizlik kaynağı, kayıtlı ancak kullanılmayan MCP (Model Context Protocol) araçları olarak öne çıktı.

LLM API’leri durum bilgisi taşımadığı için, agent çalışma ortamları genellikle her istekle birlikte tüm MCP araç fonksiyon adlarını ve JSON şemalarını gönderiyor. Örneğin, 40 araç içeren bir GitHub MCP sunucusunda, her adımda yaklaşık 10–15 KB’lık fazladan yük oluşabiliyor. Eğer agent yalnızca iki aracı kullanıyorsa, kalan 38 araç her istek için gereksiz yere token tüketimine neden oluyor.

İş akışı yazarları genellikle tüm araç setiyle başlıyor, çünkü bu en az dirençli yol. Zamanla çoğu iş akışı, dar ve istikrarlı bir araç kümesine odaklanıyor. Optimizör, araç manifestolarını gerçek araç çağrılarıyla karşılaştırarak kullanılmayan araçları belirliyor ve yapılandırmadan kaldırılmasını öneriyor.

Yapılan testlerde, kullanılmayan araçların kaldırılmasıyla her çağrı başına 8–12 KB’lık bir azalma sağlandı. Bu da her yürütmede binlerce token tasarrufu anlamına geliyor — davranışlarda ise hiçbir değişiklik olmadı.

GitHub MCP’nin Yerine GitHub CLI Kullanılması

Kullanılmayan araçların kaldırılması basit bir kazançtı. Daha büyük bir fırsat ise, çekme isteği farklarını (pull request diff), dosya içeriklerini ve inceleme yorumlarını almak gibi veri getirme işlemleri için GitHub MCP çağrılarını GitHub CLI’nin yerini almasıydı.

Bu değişiklik, yalnızca kullanılmayan araçların yükünü azaltmakla kalmadı. Çünkü bir MCP araç çağrısı, veri getirmenin yanı sıra bir de muhakeme adımı gerektiriyor. Agent, aracı çağırmaya, argümanlarını formüle etmeye ve çıktısını almaya kadar tüm süreci LLM API çağrısı olarak gerçekleştiriyor. Bu da JSON şema, argüman bloğu ve yanıt için token tüketimine neden oluyor. Oysa gh pr diff komutunu çağırmak, tamamen LLM katılımı olmaksızın GitHub’ın REST API’sine belirleyici bir HTTP isteği göndermek anlamına geliyor.

Bu geçiş için iki strateji uygulandı:

• Agent Öncesi Veri İndirme: Agent’in her zaman ihtiyaç duyacağı veriler (örneğin bir çekme isteğinin farkı ya da değişen dosyaların listesi) için iş akışına, agent başlamadan önce gh komutlarını çalıştıran ve sonuçları çalışma alanındaki dosyalara yazan adımlar eklendi. Agent artık bu dosyaları okuyor ve MCP araç çağrıları yapmıyor. Bu sayede hem araç çağrı yükünden kurtuluyor hem de agent’ın bash betiklerini verimli kullanma yeteneğinden faydalanabiliyor.

• Agent İçi CLI Vekil Sunucu Yerine Geçmesi: Bazı durumlarda, agent’in neyi getireceğine çalışma zamanında karar verdiği senaryolar var. Bu durumlarda, hafif bir şeffaf HTTP vekil sunucusu kullanıldı. Bu vekil, CLI trafiğini GitHub API sunucularına yönlendirirken, agent’a doğrudan kimlik doğrulama bilgisi vermiyor. Agent, terminaldeki bir kullanıcı gibi gh pr view –json komutunu çalıştırıyor ve yapılandırılmış veriyi geri alıyor. Bu da token kullanımını azaltırken, agent için sıfır gizlilik gereksinimlerini koruyor.

Bu teknikler birlikte, agentik iş akışlarındaki token tüketimini önemli ölçüde azaltıyor. Yapılan testlerde, bazı iş akışlarında token tüketiminde %30’a varan azalma gözlemlendi. Bu optimizasyonlar, hem maliyetleri düşürüyor hem de API hız sınırlarının daha verimli kullanılmasını sağlıyor. GitHub’un kendi repository’lerinde elde edilen bu kazanımlar, topluluk tarafından da benimsenmeye ve uygulanmaya başlandı. Gelecekte, agentik sistemlerin daha da verimli hale gelmesiyle birlikte, geliştiricilerin bu teknolojilerden daha fazla faydalanması bekleniyor.