في شهري الأول لتشغيل الوكلاء بأي حجم حقيقي، أحرقت 1,400 دولار ومعظمها كان هدراً صرفاً. ليس الحالات التي يفكر فيها النموذج بجد في مشاكل صعبة — تلك أموال تُنفق بحكمة. المشكلة كانت في إعادة إرسال نفس الـ prompt النظامي المكوّن من 40,000 token دون تخزين مؤقت في كل طلب، وتشغيل كل شيء بأقصى جهد، واستخدام Opus لعمل grep على الملفات. هدر صافٍ.
الهدف ليس جعل وكيلك أرخص بجعله أغبى. أي شخص يمكنه التحويل إلى نموذج أصغر وتسميته تحكماً في التكاليف. الهدف هو قطع الهدر والحفاظ على الذكاء حيث يهم. إليك أين يذهب المال فعلاً وكيف أسدّ كل تسرب.
التخزين المؤقت للـ prompt هو الرافعة الأكبر بفارق كبير
إذا كنت تشغّل وكيلاً مع prompt نظامي كبير ومستقر ومجموعة أدوات، وكان cache_read_input_tokens لديك يساوي صفراً، فأنت تحرق الأموال. التخزين المؤقت يعمل بمطابقة البادئة — تخزّن الـ API الـ prompt المُرنَّد حتى نقطة توقف، والقراءات تكلّف تقريباً عُشر سعر الإدخال الكامل.
المشكلة: أي تغيير في بايت واحد في أي مكان في البادئة يُبطل كل ما يليها. القاتل الكلاسيكي هو الطابع الزمني في الـ prompt النظامي.
system = f"You are an agent. Current time: {datetime.now()}" # cache dead on arrival
هذا datetime.now() يجعل كل طلب بادئةً فريدة. لا شيء يُخزَّن مؤقتاً أبداً. انقل الأشياء المتغيّرة — الطوابع الزمنية، معرّفات الطلبات، السؤال الفعلي — إلى النهاية، بعد آخر نقطة توقف للتخزين المؤقت. أبقِ الـ prompt النظامي وقائمة الأدوات ثابتَيْن ومتطابقَيْن بايتاً ببايت.
كيف تعرف أنه يعمل: تحقق من usage.cache_read_input_tokens عبر الطلبات المتكررة. إذا كان رقماً كبيراً، فأنت تُخزّن مؤقتاً. إذا كان صفراً، قارن بين promptَين مُرنَّدَين وابحث عن البايت المتغير. دائماً يكون شيئاً سخيفاً — dump JSON غير مرتّب، UUID، تاريخ. في جلسة وكيل طويلة، هذا الفرق بين تشغيل بـ4 دولارات وتشغيل بـ0.40 دولار، ولا يغيّر شيئاً في جودة المخرجات. مال مجاني.
اضبط الجهد لكل مسار، لا تضع الكل على الحد الأقصى
معامل effort يتحكم في مدى تفكير النموذج بعمق. الغريزة هي رفعه إلى max في كل مكان لكي يكون الوكيل أذكى ما يمكن. غريزة خاطئة. على نماذج Opus الحالية، high هي النقطة المثلى لمعظم الأعمال، وكثيراً ما يحرق max tokens إضافية في تفكير زائد مع عوائد متناقصة.
والأهم: لا تحتاج كل خطوة في حلقة الوكيل إلى نفس القدر من القدرة العقلية. خطوة التصنيف، قرار "أي ملف أنظر إليه"، بوابة نعم/لا — كل هذه تعمل بشكل جيد عند low أو medium. احتفظ بـhigh وxhigh للاستدلال الصعب الحقيقي والتخطيط بعيد المدى.
# cheap gate
client.messages.create(model="claude-opus-4-8", output_config={"effort": "low"}, ...)
# the real work
client.messages.create(model="claude-opus-4-8", output_config={"effort": "high"}, ...)
أجريت مسحاً للجهد على مجموعة التقييم الخاصة بي — medium، high، xhigh — ووجدت أن high يطابق xhigh في الجودة لمعظم مساراتي بإنفاق أقل ملحوظ للـ tokens. لن تعرف أرقامك حتى تقيسها. لا تضع كل شيء على الحد الأقصى خوفاً.
وكلاء فرعيون للأعمال الرخيصة
هذه خدعة هي في آنٍ واحد مكسب للتكاليف ومكسب للتخزين المؤقت. عندما تحتاج إلى إنجاز مهمة فرعية رخيصة — استكشاف مجلد، تلخيص ملف، grep لشيء ما — لا تفعل ذلك مضمّناً في حلقتك الرئيسية المكلفة. ابدأ وكيلاً فرعياً على نموذج أرخص.
لماذا هو أيضاً مكسب للتخزين المؤقت: تبديل النماذج في منتصف المحادثة يُبطل تخزينك المؤقت، لأن الذاكرة المؤقتة مرتبطة بالنموذج. إذا خفّضت حلقتك الرئيسية من Opus إلى Haiku لعمل grep ثم عدت، فقد دمّرت ذاكرة البادئة المؤقتة مرتين. الوكيل الفرعي يُبقي الحلقة الرئيسية على نموذج واحد وذاكرة مؤقتة واحدة، بينما يجري العمل الرخيص جانباً على Haiku. Claude Code يفعل هذا بالضبط — وكلاؤه الفرعيون لـ Explore يعملون على Haiku لهذا السبب تحديداً.
تحرير السياق والضغط للتشغيلات الطويلة
جلسات الوكيل الطويلة تراكم نتائج أدوات قديمة وكتل تفكير منتهية. في كل دورة تُعيد إرسال كلها بالسعر الكامل. أداتان تُصلحان هذا.
تحرير السياق يمسح نتائج الأدوات القديمة من النص قبل أن يراها النموذج. الضغط يلخّص التاريخ من جهة الخادم عندما تقترب من حد النافذة. هما مختلفان — التحرير يقلّص، الضغط يكثّف — والوكلاء الطويلون غالباً ما يستخدمون كليهما. التوفيرات تتراكم: جلسة من 40 دورة كانت ستُعيد إرسال 200,000 token من مخرجات الأدوات الميتة في كل دورة، بدلاً من ذلك ترسل ملخصاً موجزاً.
مشكلة شائعة مع الضغط تعرّض لها الجميع: أضف response.content الكامل في كل دورة، ليس النص المستخرج فحسب. حالة الضغط تعيش في تلك الكتل. اكتفِ بالنص وستفقدها بصمت، وستعود تكاليفك للارتفاع بينما تتساءل لماذا.
راقب الرقم الصحيح
آخر نقطة. عندما تصحّح أخطاء التكلفة، لا تحدّق في input_tokens وحده. المجموع الحقيقي هو input_tokens + cache_creation_input_tokens + cache_read_input_tokens. رأيت أشخاصاً يذعرون لأن وكيلاً طويل التشغيل يُظهر 4,000 input_tokens فحسب ويفترضون أن شيئاً ما معطوب — لا، الباقي كان يُخدَّم من الذاكرة المؤقتة. تلك الـ4,000 هي البقية غير المخزّنة مؤقتاً. اجمع الثلاثة أو أنت تقرأ العداد بشكل خاطئ.
لا شيء من هذا يجعل وكيلك أغبى. التخزين المؤقت مجاني. ضبط الجهد يُبقي القدرة العقلية حيث تهم. الوكلاء الفرعيون يضعون العمل الرخيص على نماذج رخيصة. القرار الغبي هو الذي يبدو ذكياً: التحويل إلى نموذج أضعف في كل مكان ومشاهدة الجودة تنهار لتوفير بعض الدولارات. اقطع الهدر أولاً. الهدر ضخم، ويختبئ في طابع زمني نسيته.