اگر از Claude Code برای مدیریت پروژههای پیچیده استفاده میکنید، احتمالاً بخشی از بودجه شما بهطور نامحسوس در حال هدر رفتن است. یک ابزار جدید به نام claude-thermos که در واقع یک پروکسی معکوس (Reverse Proxy) محلی است، میتواند هزینهٔ اجرای جلسات این ابزار را تقریباً ۲۲٪ کاهش دهد. این افزایش بهرهوری، یک نشت مالی خاموش را حل میکند که زمانی رخ میدهد که عاملهای پیچیده هوش مصنوعی، وظایفی را به عاملهای زیرمجموعه (Sub-agents) میسپارند.
پروژه claude-thermos با تکیه بر پوششهای قبلی ما در مورد اینکه چگونه Omni Flash ویرایش ویدئویی وضعیتدار (Stateful) را ممکن میسازد، به مشکل ناپایداری ذاتی در تداوم وضعیت (State Persistence) در جریانهای کاری عاملمحور میپردازد. در یک جلسه با پیچیدگی بالا، عامل اصلی اغلب در حالت انتظار (Block) قرار میگیرد تا عامل زیرمجموعه کار خود را تمام کند. طبق یافتههای توسعهدهنده این ابزار که در ۲۳ ژوئیه ۲۰۲۶ منتشر شد، اگر عامل زیرمجموعه بیش از ۵ دقیقه زمان ببرد، حافظه موقت (Prompt Cache) — که شبیه به میز کاری است که مدل برای دسترسی سریع به اطلاعات جلسه روی آن میگذارد — بهطور خودکار و در سکوت منقضی میشود.
این اتفاق باعث ایجاد چیزی میشود که توسعهدهنده آن را «مالیات حافظه» (Cache Tax) مینامد. وقتی عامل زیرمجموعه در نهایت بازمیگردد، عامل اصلی مجبور است کل تاریخچه گفتگو را دوباره کدگذاری (Re-encode) کند. در این حالت، بهجای خواندن تاریخچه با نرخ ارزان ۰.۱ برابر، باید آن را با نرخ گران نوشتن ۱.۲۵ برابر پردازش کند. در مطالعهای بر روی ۱۸۵ جلسه محلی، این بازسازیهای تکراری عامل ۲۲٪ از کل صورتحسابها بودهاند و در هر مورد منجر به بازنویسی ۲۰۰ تا ۵۰۰ هزار توکن (Token) شدهاند. این رویکرد بخشی از تلاشهای گستردهتر برای بهینهسازی است، مشابه آنچه در راهکارهای کاهش هزینه توکنها در اتوماسیون تست بررسی کردیم.
مشکل انقضای حافظه
حافظه موقت در Claude Code از یک زمان انقضا یا Time-To-Live (TTL) پنج دقیقهای استفاده میکند. تا زمانی که این حافظه زنده باشد، تاریخچه گفتگو با قیمتی بسیار پایینتر (۰.۱ برابر قیمت ورودی) سرو میشود. اما اگر بیش از ۵ دقیقه بین درخواستها روی یک پیشوند (Prefix) یکسان فاصله بیفتد، حافظه منقضی میشود.
این وضعیت عمدتاً توسط عاملهای زیرمجموعه تحریک میشود. از آنجایی که یک عامل زیرمجموعه از پرامپت سیستمی (System Prompt) و مجموعه ابزارهای متفاوتی استفاده میکند، درخواستهای آن پیشوند حافظه متفاوتی دارند. در حالی که عامل زیرمجموعه در حال کار است، تاریخچه کششدهی عامل اصلی دستنخورده میماند و با گذشت ۵ دقیقه، این تاریخچه از بین میرود. این امر منجر به یک بازنویسی کامل و گرانقیمت در لحظه بازگشت عامل زیرمجموعه میشود. برای حل دائمی این مشکل، ابزارهایی مانند deja-vu تلاش میکنند نشستها را به لایهی حافظهی دائمی تبدیل کنند تا نیاز به بازسازیهای مداوم کمتر شود.
سازوکار عملکرد claude-thermos
ابزار claude-thermos ترافیک را با تغییر مسیر ANTHROPIC_BASE_URL به یک پورت لوپبک محلی رهگیری میکند. این ابزار ترافیک مسیر /v1/messages را رصد میکند تا درخواستها را در قالب «جلسات» و «دودمانها» (Lineages) گروهبندی کند. دودمانها بر اساس مدل، مجموعه ابزارها و متن سیستمی تعریف میشوند. اولین دودمانی که دارای ابزار است، به عنوان عامل اصلی شناسایی شده و سایرین بهعنوان عاملهای زیرمجموعه علامتگذاری میشوند.
وقتی دودمان اصلی غیرفعال میشود و یک عامل زیرمجموعه فعال است، پروکسی یک درخواست «گرمکننده» (Warm Request) را تحریک میکند تا از انقضای پیشوند اصلی جلوگیری کند. این فرایند شامل مراحل زیر است:
- تکرار آخرین درخواست واقعی عامل اصلی در بازههای زمانی کمتر از TTL پنج دقیقهای.
- استفاده از یک پیشوند قابلکش با بایتهای کاملاً یکسان، اما تنظیم مقدار
max_tokens: 1و غیرفعال کردن استریم (Streaming). - دور ریختن تکتوکن خروجی؛ زیرا هدف تنها پیشپُرکردن (Prefill) است که باعث تازهسازی کامل پیشوند کششده میشود.
- ارسال مستقیم درخواستهای گرمکننده به API و دور زدن پروکسی برای اطمینان از اینکه ترافیک واقعی دستنخورده باقی میماند.
تنظیمات و اجرا
کاربران میتوانند این ابزار را از طریق دستور uvx claude-thermos اجرا کنند و هر آرگومان استاندارد Claude را از طریق آن منتقل کنند (مثلاً: uvx claude-thermos -p "fix the bug"). همچنین برای غیرفعال کردن گرمسازی در یک اجرای خاص بدون تغییر دستور، میتوان متغیر محیطی CLAUDE_WARMER_DISABLE=1 را تنظیم کرد.
برای کنترل دقیقتر بر گرمسازی پسزمینه، فلگهای تنظیمات اختیاری زیر در دسترس است:
--idle(پیشفرض ۲۷۰ ثانیه): تعداد ثانیههایی که عامل اصلی باید بیکار بماند تا گرمسازی آغاز شود.--interval(پیشفرض ۲۷۰ ثانیه): فاصله زمانی بین چرخههای گرمسازی.--max-cycles(پیشفرض ۴): حداکثر تعداد دفعات گرمسازی در هر دوره بیکاری؛ برای مقدار نامحدود میتوان آن را روی "auto" قرار داد.--subagent-window(پیشفرض ۵۴۰ ثانیه): بازه زمانی که طی آن یک عامل زیرمجموعه همچنان «فعال» تلقی میشود.
ردیابی صرفهجویی
تمامی جلسات در مسیر ~/.claude-thermos/logs/<session_id>/ ذخیره میشوند. این دایرکتوری شامل فایل events.jsonl است که یک جریان فقط-افزودنی (Append-only) از میزان مصرف توکنها و تصمیمات گرمسازی (مانند warm_fired یا resume_detected) را ثبت میکند. همچنین فایل summary.json مجموعهای نهایی را ارائه میدهد.
فایل summary.json میزان صرفهجویی خالص (net_savings) را از طریق محاسبه تفاوت بین «هزینه بازنویسی اجتنابشده» (۱.۲۵ × توکنهای اجتنابشده) و «هزینه گرمسازی» (۰.۱ × توکنهای خواندهشده) به دست میآورد. برای تبدیل این عدد به ارز، مقدار net_savings را در قیمت توکن ورودی مدل ضرب کنید. برای مثال، با قیمت ۳ دلار بهازای هر میلیون توکن، صرفهجویی ۱,۲۰۰,۰۰۰ توکن در یک جلسه، تقریباً معادل ۳.۶۰ دلار سود است.
برای کیف پول توسعهدهندگان، این به معنای کاهش شدید اتلاف است. با صرف کسری از یک سنت برای زنده نگه داشتن کش، کاربران از پرداخت هزینه بازنویسی عظیم تاریخچههای با کانتکست طولانی اجتناب میکنند. این کار بهطور مؤثری اقتصاد حلقههای عاملمحور طولانیمدت را تغییر میدهد.
این ابزار شکافی بحرانی را در نحوه مدیریت وضعیت توسط ارائهدهندگان فعلی LLM برجسته میکند. اگرچه کشینگ پرامپت ویژگی قدرتمندی است، اما TTL سختگیرانه آن برای ماهیت نامتقارن همکاریهای چندعاملی بهینه نشده است.
برای شروع، مطمئن شوید که Python 3.11+ و Claude CLI در مسیر PATH شما قرار دارند.
گام بعدی شما
- اگر از Claude Code برای توسعه نرمافزار استفاده میکنید، پکیج
claude-thermosرا نصب کنید تا از هزینههای پنهان بازنویسی توکنها بکاهید. - فایل
summary.jsonرا بررسی کنید تا متوجه شوید چه مقدار از بودجه شما صرف «مالیات حافظه» میشده است. - تنظیمات
--idleرا بر اساس میانگین زمان پاسخدهی عاملهای زیرمجموعه خود بهینهسازی کنید.
اما بهینهسازی هزینه تنها بخشی از ماجراست؛ برای درک اینکه چگونه مدلهای استدلالی هزینه استنتاج را جابهجا میکنند، به تحلیل ما درباره مدلهای Reasoning مراجعه کنید.
گفتگو