بقلم: ليلى | محررة أدوات المطورين · صوت تحريري بإشراف بشري
كل مرة ينتظر فيها وكيلك الرئيسي في claude-thermos نتائج subagent لأكثر من خمس دقائق، يختفي الـ cache بصمت — ويُعاد ترميز سجل المحادثة كاملاً بالسعر المرتفع. قاس المطوّر إيليا زايغرمان هذا على 185 جلسة محلية، ووجد أن إعادة الترميز هذه تستهلك 22% من إجمالي الفاتورة (وفقاً لـ claude-thermos على GitHub). الأداة التي بناها تُحلّ هذه المشكلة تحديداً، لا أكثر.
المشكلة تقنية في جوهرها: Claude Code يعتمد على prompt cache بـ TTL مدته خمس دقائق فقط. طالما تتتالى الطلبات على نفس الـ prefix خلال هذه النافذة، يُقرأ سجل المحادثة بـ 0.1x من سعر الإدخال. لكن حين يُوكَل جزء من العمل إلى subagent، فهو يعمل على system prompt وأدوات مختلفة، أي prefix مختلف تماماً — ولا تُعيد طلباته تحديث cache الوكيل الرئيسي. نتيجة ذلك: cache الوكيل الرئيسي يتقادم خلال انتظاره، وعند عودة الـ subagent يضطر Claude إلى إعادة ترميز كامل السياق بمعدل 1.25x. في جلسات طويلة، يبلغ حجم هذا السياق بين 200 ألف و500 ألف token في كل عملية إعادة ترميز — وهو المبلغ الذي كان مخزّناً منذ لحظات.
آلية عمل claude-thermos بسيطة مفاهيمياً لكنها ذكية في التنفيذ. تُشغّل الأداة Claude Code خلف reverse proxy محلي صغير يستمع على loopback port ويُحوّل ANTHROPIC_BASE_URL إليه، بينما يبقى كل الترافيك متجهاً نحو Anthropic API الحقيقي. يراقب الـ proxy مسار /v1/messages ويُصنّف الطلبات إلى lineages — كل lineage يتعرّف عليه بمجموعة model + tool set + system text. أول lineage يحمل أدوات هو الوكيل الرئيسي؛ الباقي subagents. حين يصمت الوكيل الرئيسي ويُكتشف subagent نشط، تبدأ دورة الإدفاء: تُرسَل نسخة من آخر طلب حقيقي للوكيل الرئيسي — بنفس الـ prefix القابل للتخزين، لكن بـ max_tokens: 1 ودون streaming. الهدف من هذا الطلب هو الـ prefill فحسب؛ يُحدَّث الـ cache ويُرمى الرد. تذهب طلبات الإدفاء مباشرة للـ API دون المرور بالـ proxy حتى لا تتداخل مع الترافيك الحقيقي.
الاستخدام لا يتطلب تعديلاً في سير عملك. يكفي Python 3.11+ وأن يكون claude في الـ PATH:
- شغّل
uvx claude-thermosبدلاً منclaudeمباشرة — أي arguments تمرّرها تصل إلى Claude بدون تعديل، مثل:uvx claude-thermos -p "fix the bug" - لتعطيل الأداة لجلسة واحدة دون تغيير الأمر، اضبط
CLAUDE_WARMER_DISABLE=1قبل التشغيل - اضبط
--idle 270لتحديد عدد الثواني التي يجب أن يظل فيها الوكيل الرئيسي خاملاً قبل بدء الإدفاء (الافتراضي: 270 ثانية) - اضبط
--interval 270لتحديد الفاصل الزمني بين دورات الإدفاء (الافتراضي: 270 ثانية أيضاً) - استخدم
--max-cycles 4للحد من عدد مرات الإدفاء في كل فترة خمول — أو اتركه فارغاً لعدد غير محدود - اضبط
--subagent-window 540لتحديد عدد الثواني التي يُعتبر فيها subagent لا يزال نشطاً (الافتراضي: 540 ثانية)
تكتب كل جلسة سجلاتها في ~/.claude-thermos/logs/<session_id>/ وتحتوي على ملفَّين: events.jsonl لتدفق الأحداث المفصّل، وsummary.json لملخص التوفير. في الأخير ستجد حقولاً واضحة: عدد طلبات الإدفاء المُرسَلة (warms_fired)، وعدد الـ tokens التي قُرئت (cache_read_total)، وعدد الـ tokens التي كانت ستُعاد كتابتها لولا الأداة (rewrite_avoided_tokens). حساب التوفير بالدولار بسيط: net_savings × (سعر الـ input token). على سبيل المثال، عند سعر 3 دولار لكل مليون token، يعني net_savings قدره 1,200,000 token توفيراً فعلياً بمقدار 3.60 دولار في جلسة واحدة.
المعادلة المالية واضحة: كل طلب إدفاء يكلف 0.1x على الـ tokens التي يقرأها، بينما إعادة الترميز التي يمنعها تكلف 1.25x على prefix أكبر بكثير. التبادل في مصلحة المطوّر تقريباً في كل سيناريو. القيد الوحيد الذي ينبغي الانتباه إليه هو أن الأداة مُصمَّمة تحديداً لحالة الانتظار على subagents — إن كانت جلساتك لا تعتمد على subagents أو كانت قصيرة عموماً، فستكون الفائدة محدودة. لكن للعمليات الطويلة المعقّدة التي تُنسّق وكلاء متعددين، وهي بالضبط الأنماط التي تتكاثر مع نضج مشاريع الـ AI agents، يغدو claude-thermos واحدة من أكثر أدوات تحسين التكلفة مباشرةً ودقةً في هذا المجال.
