Bir Günde 21,5 Milyon Token Yakan OpenClaw Oturumlarımın Nedeni (Ve Gerçekten Çözümü)
Yazar: MOSHIII
Peggy, BlockBeats
Editör Notu: Agent uygulamalarının hızla yaygınlaşmasının ardından birçok ekip, sistemlerin sorunsuz çalışmasına rağmen token maliyetlerinin fark edilmeden sürekli yükseldiğini gözlemliyor. Bu makalede, gerçek bir OpenClaw iş yükünün analiziyle, maliyet patlamasının nedeninin kullanıcı girdileri veya model çıktıları değil, ihmal edilen bağlam önbelleği geri oynatması (cached prefix replay) olduğu ortaya çıkıyor. Model, her çağrıda büyük miktarda geçmiş bağlamı tekrar okuyarak devasa token tüketimi yaratıyor.
Makale, belirli oturum verilerini birleştirerek, aracın çıktısını, tarayıcı anlık görüntülerini, JSON günlüklerini gibi büyük ara ürünlerin nasıl sürekli olarak geçmiş bağlama yazıldığını ve agent döngüsü içinde nasıl tekrar okunduğunu gösterir.
Bu vaka üzerinden yazar, bağlam yapısı tasarımı, araç çıktısı yönetimi ve compaction mekanizması yapılandırmasından oluşan net bir optimizasyon yaklaşımı sunuyor. Agent sistemleri oluşturan geliştiriciler için bu, yalnızca bir teknik sorun giderme kaydı değil, aynı zamanda gerçek para tasarrufu sağlayan bir rehberdir.
Aşağıda orijinal metin yer almaktadır:
Gerçek bir OpenClaw iş yükünü analiz ettim ve birçok Agent kullanıcısının tanıdığı bir desen keşfettim:
Token kullanım miktarı oldukça "aktif" görünüyor.
Yanıt da oldukça normal görünüyor
Ancak token tüketimi ani olarak patlama gibi arttı
Bu analizin yapısal ayrıştırması, temel nedenler ve uygulanabilir onarım yolları aşağıda verilmiştir.
Kısa özet
En büyük maliyet驱动 faktörü, kullanıcı mesajlarının çok uzun olması değil, büyük miktarda önbellek öneki (cached prefix) tekrar tekrar oynatılmasıdır.
Oturum verilerine göre:
Toplam token: 21.543.714
Önbellek Okuma: 17.105.970 (79,40%)
4.345.264 (20,17%)
92.480 (0,43%)
Yani: Çağrıların maliyetinin çoğu, yeni kullanıcı niyetlerini işlemek yerine, büyük tarihsel bağları tekrar tekrar okumaktadır.
"Beklemeyin, nasıl olabilir?" anı
Yüksek token kullanımının, çok uzun kullanıcı istekleri, büyük miktarda çıktı üretimi veya maliyetli araç çağrılarından kaynaklandığını düşünüyordum.
Ancak gerçekten hakim olan model şudur:
Yüzlerce ila binlerce token
cacheRead: Her çağrıda 170.000 ila 180.000 token
Yani model, her turda aynı büyük sabit öneki tekrar tekrar okuyor.
Veri aralığı
İki düzeydeki verileri analiz ettim:
1. Çalışma zamanı günlükleri (runtime logs)
2. Oturum kayıtları (session transcripts)
Şunu belirtmek gerekir:
Çalışma günlükleri, davranış sinyallerini (yeniden başlatma, hata, yapılandırma sorunları vb.) gözlemlemek için kullanılır.
Token istatistikleri, session JSONL dosyasındaki usage alanından alınmıştır.
Kullanılan betik:
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
Oluşturulan analiz dosyası:
tmp/session_token_stats_v2.txt
tmp/session_token_stats_v2.json
tmp/session_duplicate_waste.txt
tmp/session_duplicate_waste.json
tmp/session_duplicate_waste.png
Token nerede gerçekten tüketiliyor?
1) Oturum Odaklı
Diğerlerinden çok daha yüksek bir oturum tüketimi var:
570587c3-dc42-47e4-9dd4-985c2a50af86: 19.204.645 token
Ardından açıkça dik bir düşüş:
ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1.505.038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649.584
2) Davranış odaklı
Token ana kaynakları:
toolUse：16,372,294
Durdur: 5.171.420
Sorunun temel nedeni, normal sohbet değil, araç çağırma zincirindeki döngüdür.
3) Zaman odaklı
Tepe token miktarları rastgele değil, belirli saat aralıklarında yoğunlaşır:
2026-03-08 16:00: 4.105.105
2026-03-08 09:00: 4.036.070
2026-03-08 07:00: 2.793.648
Büyük önbellek ön eki içinde tam olarak ne var?
Konuşma içeriği değil, ana olarak büyük ara ürün:
Devasa toolResult veri bloğu
Uzun bir nedenleme / düşünme izi
Büyük JSON anlık görüntüsü
Dosya listesi
Tarayıcı veri topluyor
Sub Agent'in konuşma kayıtları
En büyük oturumda karakter sayısı yaklaşık olarak:
366.469 karakter
331,494 karakter
assistant:toolCall：53,039 karakter
Bu içerikler tarihsel bağlamda saklandığında, sonraki her çağrı cache ön ekiyle tekrar okunabilir.
Örnekler (oturum dosyasından)
Aşağıdaki konumda büyük bir bağlam bloğu tekrarlanmıştır:
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
Büyük ağ geçidi JSON günlük dosyası (yaklaşık 37.000 karakter)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
Tarayıcı anlık görüntüsü + Güvenli paketleme (yaklaşık 29.000 karakter)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
Büyük dosya listesi çıktısı (yaklaşık 41.000 karakter)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
oturum/durum Durum Anlık Görüntüsü + Büyük Prompt Yapısı (yaklaşık 30.000 karakter)
Tekrarlanan içerik kaybı vs önbellek yeniden oynatma yükü
Ayrıca tek bir çağrının içindeki tekrarlanan içerik oranını da ölçtüm:
Tekrar oranı yaklaşık: %1,72
Gerçekten var, ancak ana sorun değil.
Gerçek sorun: önbellek ön ekinin mutlak boyutunun çok büyük olması
Yapı: Devasa tarihsel bağlam, her çağrıda yeniden okuma, üstüne sadece az yeni giriş ekleniyor
Bu nedenle odak noktası tekrarları kaldırma değil, bağlam yapısı tasarımıdır.
Neden Agent döngüsü bu sorunu özellikle sık yaşar?
Üç mekanizma birbirine eklenir:
1, Çok sayıda araç çıktısı geçmiş bağlamına yazıldı
2. Araç döngüsü, kısa aralıklı çok sayıda çağrı oluşturur.
3. Önek çok az değişiyor → önbellek her seferinde yeniden okunur
Eğer context compaction kararlı bir şekilde tetiklenmezse, sorunlar hızla büyüyecektir.
En önemli onarım stratejileri (etki sırasına göre)
P0—Büyük araç çıktılarını uzun vadeli bağlama sokmayın
Çok büyük araç çıktısı için:
- Özetleri koru + başvuru yolu / ID
- Orijinal payload dosya arşivine yazılır
- Chat geçmişinde tam metni tutmayın.
Öncelikle bu kategorileri sınırlayın:
- Büyük JSON
- Uzun katalog listesi
- Tarayıcı tam ekran görüntüsü
- Alt Ajan Tam Metin
P1—Kompaksiyon mekanizmasının gerçekten etkin olduğundan emin olun
Bu veride, yapılandırma uyumluluk sorunu defalarca ortaya çıktı: compaction key geçersiz
Bu, optimizasyon mekanizmasını sessizce kapatır.
Doğru yöntem: Yalnızca uyumlu sürüm yapılandırmalarını kullanın
Ardından doğrulayın:
openclaw doctor --fix
Başlangıç günlüğünü kontrol ederek compaction'ın kabul edildiğini onaylayın.
P1—Tartışma metninin kalıcı hale getirilmesi azaltılıyor
Uzun akıl yürütme metinlerinin tekrar tekrar oynatılmasını önleyin
Üretim ortamında: Tam nedenleri değil, kısa özetleri kaydedin.
P3—Prompt önbellekleme tasarımını iyileştirin
Hedef, cacheRead'i maksimize etmek değil. Hedef, sıkı, kararlı ve yüksek değere sahip öneklerde cache kullanmaktır.
Öneri:
- Sabit kuralları sistem talimatına ekleyin.
- Kararlı öneklere kararsız verileri eklemeyin
- Her turda fazla debug verisi girmeyin
Pratik Durdurma Stratejisi (Eğer ben yarın bunu çözeceksem)
1. En yüksek cacheRead oranına sahip oturumu bulun
2. runaway oturumu için /compact komutunu çalıştırın
3. Araç çıktısına kesme + artifactleştirme ekleyin
4. Her değişiklikten sonra token istatistiklerini yeniden çalıştırın
Dört KPI'yi takip edin:
cacheRead / toplamToken
toolUse avgTotal/call
>=100k token çağrısı
Maksimum oturum oranı
Başarı sinyali
İyileştirme etkili olursa, şunu görmelisiniz:
100k+ token çağrısı belirgin şekilde azaldı
Önbellek okuma oranı azalıyor
Araç kullanımı ağırlığı azaldı
Tek bir oturumun hakimiyeti azalıyor
Bu göstergeler değişmiyorsa, bağlam stratejiniz hâlâ çok gevşektir.
Deneyi tekrarlamak için komutlar
python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
-- ilk 20
--outlier-threshold 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt
python3 betikler/session_duplicate_waste_analysis.py 'oturumlar' \
--include-deleted \
-- ilk 20
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt
Sonuç
Agent sisteminizin düzgün görünüyorsa ancak maliyetler sürekli artıyorsa, ilk olarak şunu kontrol edin: Yeni bir çıkarım mı ücretlendiriyorsunuz, yoksa eski bağlamı büyük ölçekli olarak mı tekrar oynatıyorsunuz?
Benim durumumda, maliyetlerin büyük çoğunluğu bağlam yeniden oynatmadan kaynaklanmaktadır.
Bunu fark ettiğinizde çözüm oldukça net: Uzun vadeli bağlama giren verilere sıkı kontroller uygulayın.