# Bir Kodlama Ajanı Görevi İçin Kesin Harcama Limiti Nasıl Belirlenir? > Kesin harcama limiti, görev bütçesini yöneten bir ağ geçidi tarafından her model veya ücretli araç çağrısından önce uygulanmalıdır. En kötü durum maliyetini rezerve edin, gerçek kullanımı uzlaştırın, bütçeye sığmayan çağrıları reddedin ve ajanı yararlı bir kontrol noktasıyla durdurun. # Bir Kodlama Ajanı Görevi İçin Kesin Harcama Limiti Nasıl Belirlenir? Kesin görev bütçesi admission control problemidir. Her ücretli model veya araç çağrısından önce güvenilir ağ geçidi, izin verilen en yüksek maliyetin görevde kalan bakiyeye sığdığını kanıtlamalıdır. Uyarı ve çalışma sonrası rapor yararlıdır, ancak olmuş aşımı durduramaz. Tasarım giriş token'larını, maksimum çıktıyı, yeniden denemeleri, fallback'leri, alt ajanları, embeddings'i, aramaları, sandbox'ları ve diğer ücretli araçları kapsamalıdır. ## Kesin limitleri yumuşak hedeflerden ayırın Üç değer kullanın: | Kontrol | Amaç | Davranış | |---|---|---| | Hedef | Beklenen maliyet | Uyar veya daha ucuz plan seç | | Yumuşak limit | Yükseltme eşiği | Onay iste veya kaliteyi azalt | | Kesin limit | Yetkili en yüksek harcama | Sonraki çağrıyı başlamadan reddet | Örneğin görev $0.60 hedefleyip $0.90'da onay isteyebilir ve $1.00'da durabilir. Kesin limit yalnızca ajan isteminde değil, sunucu tarafında yaşamalıdır. ## Her ücretli eylemi tek ağ geçidi arkasına koyun Ajana yalnızca ağ geçidinizi çağırabilen kısa ömürlü görev kimlik bilgileri verin. Ağ geçidi `task_id` ekler, bütçeyi okur, sonraki eylemi tahmin eder ve fon rezerve eder ya da reddeder. Ajanın muhasebeyi atlamasını sağlayan sağlayıcı anahtarı vermeyin. Aynı kuralı web araması, barındırılan sandbox, kod çalıştırma ve ücretli retrieval hizmetlerinde uygulayın. ## Çağrıdan önce rezerve, sonra uzlaştırın Model çağrısında bilinen giriş token'ları ve yapılandırılmış maksimum çıktıdan üst sınırı tahmin edin. Atomik rezervasyon yapın, isteği gönderin ve rezervasyonu gerçek kullanım maliyetiyle değiştirin. ```text remaining = hard_limit - committed_cost - open_reservations worst_case = input_cost + max_output_cost + tool_allowance if worst_case > remaining: reject("task_budget_exceeded") else: reserve(worst_case) call_provider() reconcile(actual_cost) ``` Atomik rezervasyon iki paralel alt ajanın aynı kalan bakiyeyi harcamasını önler. ## Sürümlenmiş fiyat kartıyla fiyatlayın Her tahminde kullanılan fiyatı olayla saklayın. Model fiyatları ve faturalandırma kuralları değişir; eski kullanımı bugünün tarifesiyle yeniden hesaplamayın. Sağlayıcı kesin maliyet döndürürse tahmini ve son ücreti birlikte tutun. Yalnızca token dönerse çağrıdan önce seçilen fiyat kartını kullanın. Bilinmeyen araç ücretleri için temkinli ek pay koyun veya üst sınırı bilinmeyen çağrıları reddedin. ## Akışı güvenli hale getirin Akışı açmadan izin verilen yanıtın tam maliyetini rezerve edin. Kullanımı sayın, ancak istemci bağlantısını kapatmanın sağlayıcı faturalandırmasını anında durdurduğunu varsaymayın. İptal optimizasyondur, uygulama sınırı değildir. Çağrı başına çıktı limiti ve duvar saati timeout'u belirleyin. Kesin görev limiti tüm akış, retry ve fallback'lerin toplamını kapsar. ## Yeniden denemeleri ve alt ajanları dahil edin Her deneme aynı üst görev defterinden düşer. Sessizce yeni bütçe açan retry ilkesi limiti bozar. Delegasyonda hiyerarşik bütçe kullanın: | Defter | Limit | Kural | |---|---:|---| | Üst görev | $1.00 | Mutlak tavan | | Uygulama alt ajanı | $0.55 | Üstün kalan bakiyesini aşamaz | | Test analizi alt ajanı | $0.25 | Kullanılmayan rezervasyonu iade eder | | Son inceleme | $0.20 | Yalnızca fon kalırsa çalışır | Alt limitler ek para değil, dağıtımdır. ## Yararlı kontrol noktasıyla durun Sonraki eylem sığmıyorsa orkestratörün anlayacağı tipli hata döndürün. Ajan reddedilen çağrıyı sürekli yeniden denememelidir. Mevcut bağlamdan maliyetsiz kontrol noktası üretmesini isteyin: * tamamlanan değişiklikler ve test sonuçları; * kalan iş ve engellenen eylem; * mevcut depo durumu; * tahmini ek bütçe; * devam token'ı veya görev kimliği. Böylece bütçe durması bozuk kısmi çalışma yerine kontrollü devre dönüşür. ## Sağlayıcı kontrollerini ek güvence olarak kullanın Sağlayıcı ve ağ geçidi hesap limitleri etkiyi azaltabilir, ancak nadiren görev başına hassastır. Birden çok depoyu birleştirebilir, asenkron güncellenebilir veya araç maliyetini kapsamayabilir. Atlas Cloud gibi çok modelli ağ geçidinde kesin görev defterini orkestrasyon katmanında tutun ve uzlaştırma için ağ geçidi kullanım kimliklerini kaydedin. Böylece model değişse de sınır korunur. ## Limiti finansal kontrol gibi test edin Paralel çağrıları, uzun akışları, sağlayıcı timeout'larını, eksik kullanım alanlarını, retry'ları, model fallback'lerini ve defter arızalarını test edin. Bütçe hizmeti yoksa varsayılan olarak reddedin. Kesinleşen maliyet artı açık rezervasyonların hiçbir zaman kesin limiti aşmadığını doğrulayın. ## Sonuç Gerçek kesin harcama limiti, her ücretli eylem için atomik rezervasyon ve tek defterle harcamadan önce uygulanır. Sistem yalnızca kullanım geldikten sonra uyarıyorsa bu izleme sistemidir, kesin üst sınır değildir. ## FAQ ### max_tokens kesin bir dolar limiti midir? Hayır. Tek bir yanıtın uzunluğunu sınırlar; toplam görev maliyetini, giriş token'larını, yeniden denemeleri, model değişikliklerini veya ücretli araçları sınırlamaz. Dolar limiti her ücretli eylem için bütçe defteri gerektirir. ### Kodlama ajanı bütçesi nerede uygulanmalıdır? Tüm model ve ücretli araç çağrılarının geçtiği sunucu taraflı ağ geçidinde veya orkestrasyon katmanında uygulayın. İstemci taraflı sayaçlar aşılabilir ve eşzamanlılıkta yarışabilir. ### Akış yanıtları nasıl bütçelenir? Akışı açmadan önce izin verilen maksimum çıktı maliyetini rezerve edin ve kapanışta bildirilen kullanımla uzlaştırın. Sağlayıcıda iptali kullanın, ancak yalnızca iptale güvenmeyin. ### Yeniden denemeler ilk görev bütçesini paylaşmalı mı? Evet. Yeniden denemeler, fallback'ler, alt ajanlar ve değerlendirme çağrıları kullanıcı ayrı bir bütçeyi açıkça onaylamadıkça aynı görev defterinden düşmelidir. ### Kalan bütçe yetersiz olduğunda ne olmalıdır? Sonraki ücretli çağrıyı reddedin ve ajandan mevcut bağlamla tamamlanan işleri, çözülmemiş maddeleri ve devam için gereken tutarı içeren bir kontrol noktası üretmesini isteyin. ### Sağlayıcı hesap limitleri görev başına limitin yerini alabilir mi? Genellikle hayır. Hesap limitleri tüm hesabı korur ve gecikmeli güncellenebilir. Görev ağ geçidi anlık yalıtım sağlar; hesap kontrolleri ek koruma olarak kalır.