تصور کنید یک اصلاح تکخطی در کد در Claude Code، ده برابر گرانتر از یک اصلاح مشابه در فایلی دیگر تمام شود. این جهش قیمتی ربطی به پیچیدگی کد ندارد، بلکه به حجم توکنهای بیربطی برمیگردد که در هر درخواست همراه کد شما سفر میکنند و این موضوع کاملاً به نحوه مدیریت جلسه (Session) بستگی دارد.
دو جلسه را در نظر بگیرید که هر دو در حال رفع یک خطای تست هستند. در حالت اول، شما نام فایل را میدهید؛ کلود آن را میخواند، یک خط را اصلاح میکند و تست را اجرا میکند. در حالت دوم، شما میگویید «تستها خطا میدهند». کلود شروع به اجرای دستور grep در مخزن میکند، دهها فایل کاندید را میخواند و در نهایت همان اصلاح تکخطی را انجام میدهد. حالا هر یک از آن دهها فایل بیربط در تمام درخواستهای بعدی همراه کد شما میمانند و مدل در هر نوبت باقیمانده، زمان و هزینه خود را صرف استدلال پیرامون دادههایی میکند که هرگز اهمیتی نداشتند.
همانطور که در تحلیل قبلی ما دربارهی لاگهای مهندسی findmypylibrary اشاره کردیم، ابزارهای کدنویسی عاملمحور این فرض قدیمی را که هزینه ویرایشگر ثابت است، بهکل تغییر دادهاند. در یک گردشکار عاملمحور (Agentic) — شبیه به استخدام دستیاری که برای پیدا کردن یک پیچ، کل انبار را زیر و رو میکند — شما فقط هزینه نتیجه نهایی (Diff) را نمیپردازید، بلکه هزینه تمام مسیر اکتشاف مدل را متحمل میشوید که اغلب شامل خواندن دهها فایل است که در نهایت هیچ کاربردی در حل مسئله نداشتند. در این راستا، برخی راهکارهای جایگزین مانند Locally Uncensored توانستهاند هزینههای توکن را تا ۴۰٪ کاهش دهند که نشاندهنده پتانسیل بهینهسازی در لایههای زیرساختی است.
مکانیسم صورتحساب
به نقل از راهنمای فنی مفصلی که در ۲۱ سپتامبر ۲۰۲۶ منتشر شد، سه عامل اصلی قیمت هر توکن را تعیین میکنند: انتخاب مدل، نوع توکن (ورودی یا خروجی) و اینکه آیا سرور قبلاً آن توکن را دیده است یا خیر.
انتخاب مدل مانند یک ضریب روی تمام هزینههای دیگر عمل میکند. برای مثال، فاصله قیمتی ورودی بین مدل Haiku 4.5 (۱ دلار به ازای هر میلیون توکن) و Fable 5.1 (۱۰ دلار به ازای هر میلیون توکن) ده برابر است. تمام اهرمهای دیگر مثل حافظه پنهان، اندازه زمینه (Context Size) و طول جلسه، در این ضریب ضرب میشوند.
توکنهای خروجی گرانترین بخش هستند و در تمام مدلهای Anthropic تقریباً ۵ برابر توکنهای ورودی قیمت دارند. دلیل این موضوع ساختار دو مرحلهای درخواست است: پیشپُرکردن (Prefill) که در آن مدل پرامپت را در یک گذر سریع میخواند، و رمزگشایی (Decoding) که در آن پاسخ توکن به توکن تولید میشود. یک پاسخ ۲۰۰ توکنی، نیازمند ۲۰۰ اجرای متوالی مدل است.
این ساختار باعث میشود «توکنهای تفکر» (Thinking Tokens) به یکی از عوامل اصلی هزینه تبدیل شوند. این توکنها با قیمت خروجی محاسبه میشوند. اگر مدل در یک نوبت ۵۰۰۰ توکن فکر کند تا پاسخی ۵۰۰ توکنی بدهد، شما هزینه ۵۵۰۰ توکن خروجی را میپردازید. تنظیمات /effort مستقیماً این هزینه را کنترل میکند؛ چون تعیین میکند مدل چقدر استدلال کند، چند فایل را بخواند و چند ابزار را پیش از بازگشت به کاربر فراخوانی کند.
قدرت حافظه پنهان پرامپت
حافظه پنهان پرامپت (Prompt Caching) — شبیه به یادداشتبرداری از بخشهای تکراری یک کتاب برای نخواندن دوباره آنها — اثرگذارترین ابزار برای کاهش هزینه است. وقتی ابتدای یک درخواست از نظر بایتی دقیقاً با درخواست قبلی یکسان باشد، سرور از وضعیت داخلی قبلی استفاده کرده و فقط بخش جدید (دم یا Tail) را پیشپُر میکند.
قیمت عملیات حافظه پنهان نسبت به ورودی استاندارد متفاوت است:
- خواندن از حافظه (Cache read): ۰.۱ برابر (در Fable 5.1 این رقم حتی کمتر و ۰.۰۲۵ برابر است)
- نوشتن در حافظه (Cache write - ۵ دقیقه TTL): ۱.۲۵ برابر
- نوشتن در حافظه (Cache write - ۱ ساعت TTL): ۲ برابر
در مدل Fable 5.1، هزینه خواندن از حافظه تنها ۰.۲۵ دلار به ازای هر میلیون توکن است که بسیار ارزانتر از ۰.۵۰ دلار در مدل Opus 5 است. این یک سیگنال واضح است که Fable برای جلسات طولانی طراحی شده است که در آنها زمینههای حجیم بهطور مکرر خوانده میشوند.
در یک جلسه بهینه، میانگین حلقههای عامل ۸۴٪ ورودیهای خود را از حافظه پنهان میخوانند و در پیادهسازیهای برتر، این عدد به ۹۴٪ میرسد. در این حالت، وقتی مدل در عمق یک تسک است، برای کمتر از ۱٪ ورودیهای خود قیمت کامل را میپردازد.
چه چیزهایی حافظه پنهان را میشکنند؟
برخی اقدامات باعث میشوند مدل مجبور شود کل گفتگو را از ابتدا بخواند (Re-prefill) و هزینهها ناگهان جهش کنند. چون حافظه پنهان از اولین بایت تطبیق داده میشود، هر تغییری در ابتدای درخواست، تمام حافظه بعدی را نابود میکند.
عملیات مخرب حافظه پنهان:
- تغییر مدل (
/model): هر مدل حافظه پنهان خود را دارد. تغییر مدل در میان گفتگو یعنی مدل جدید هرگز تاریخچه را ندیده است و کل گفتگو باید از نو پیشپُر و نوشته شود. این مورد شاملopusplanنیز میشود که در هر ورود و خروج از حالت برنامهریزی، مدل را تغییر میدهد. - تغییر سطح تلاش (
/effort): سطح تلاش بخشی از کلید حافظه است و تغییر آن دقیقاً همان اثر تغییر مدل را دارد. - حالت سریع (Fast mode): فعالسازی این حالت باعث پیشپُرکردن مجدد با قیمتهای مخصوص حالت سریع میشود.
- فشردهسازی (
/compact): این دستور تاریخچه را با یک خلاصه جایگزین میکند. اگرچه پرامپت سیستمی باقی میماند، اما هر چه بعد از آن است، جدید محسوب میشود. - زمان: در اشتراکها، زمان ماندگاری حافظه (TTL) یک ساعت و در API کلیدها ۵ دقیقه است، مگر اینکه
ENABLE_PROMPT_CACHING_1H=1تنظیم شده باشد. بازگشت به جلسه بعد از استراحت ناهار یعنی اولین درخواست با قیمت کامل پردازش شود.
تغییر مدل یا سطح تلاش در میان گفتگو، هزینه آن خط خاص را ۲۰ برابر میکند. در یک گفتگوی ۱۰۰ هزار توکنی، یک نوبت عادی در Sonnet 5 حدود ۰.۰۲ دلار هزینه دارد، اما بعد از شکست حافظه، این رقم به ۰.۴۰ دلار میرسد. در Fable 5.1 این جریمه شدیدتر است: ۰.۰۲۵ دلار در حالت عادی در برابر ۲ دلار بعد از شکست (جهش ۸۰ برابری).
مدیریت پوسیدگی زمینه
هر چیزی که وارد گفتگو شود — از خروجی ابزارها تا محتوای فایلها و نتایج دستورات — تا پایان جلسه باقی میماند. این منجر به «پوسیدگی زمینه» (Context Rot) میشود؛ جایی که با پر شدن پنجره زمینه (Context Window) — شبیه به میز کاری که از شدت شلوغی دیگر جای تکان خوردن نیست — عملکرد مدل افت میکند. مدلی با ۱۵۰ هزار توکن خروجی ابزار، دستورات اولیه را فراموش کرده و بیشتر از مدلی با ۳۰ هزار توکن اشتباه میکند.
برای مقابله با این وضعیت، استراتژیهای زیر توصیه میشود:
پرامپتنویسی دقیق و استفاده بهینه از ابزار:
- پرامپتنویسی دقیق: استفاده از
@filenameبرای پیوست کردن مستقیم یک فایل، ارزانتر از درخواست از مدل برای یافتن فایل باgrepاست. یک پرامپت مبهم مثل «تستها خطا میدهند» ممکن است باعث چندین جستوجوی بیمورد و خواندن فایلهای غیرضروری شود. در یک مثال عینی، یک پرامپت دقیق ۱.۸ برابر ارزانتر بود چون از ورود ۱۲ هزار توکن داده بیربطه در ابتدای زمینه جلوگیری کرد. - پرچمهای خاموش (Quiet Flags): خروجیهای دستورات زیر ۳۰ هزار کاراکتر (آستانه
BASH_MAX_OUTPUT_LENGTH) در زمینه باقی میمانند. ۴۰۰ خط تست پاس شده میتواند ۵ هزار توکن نویز اضافه کند. افزودن گزارشدهندههای خاموش (مثلاً--reporter=dotبرای Vitest، یاcargo test -qیا./gradlew test --console=plain) به فایلCLAUDE.mdاز این آلودگی جلوگیری میکند. - پاکسازی پایه: با اجرای
/contextدر یک جلسه جدید، خط پایه را بررسی کنید. فایلCLAUDE.mdرا فقط به دستورات جهانی محدود کنید و راهنماییهای خاص هر گردشکار را به بخش skills منتقل کنید. از/mcpبرای غیرفعال کردن سرورهایی که برای تسک فعلی نیاز نیستند استفاده کنید.
فشردهسازی استراتژیک:
دستور /compact تاریخچه را با یک خلاصه جایگزین میکند. انجام این کار زمانی که حافظه «گرم» است (خواندن تاریخچه با ضریب ۰.۱)، بسیار ارزانتر از انتظار برای فشردهسازی خودکار است که وقتی پنجره پر شده و حافظه احتمالاً منقضی شده، رخ میدهد.
فشردهسازی دستی همراه با یک راهنما (مثلاً «روی بازسازی auth تمرکز کن و دیباگ تستها را حذف کن») برتر از فشردهسازی خودکار است. فشردهسازی خودکار زمانی اجرا میشود که زمینه در پرترین حالت خود است، یعنی دقیقاً زمانی که مدل در کمترین توانایی برای نوشتن یک خلاصه باکیفیت قرار دارد.
استراتژی عاملهای فرعی (Subagents)
عاملهای فرعی راهی برای ایزوله کردن کارهای پرنویز هستند. یک عامل فرعی در پنجره زمینه خود با پرامپت سیستمی و ابزارهای مجزا اجرا میشود و فقط نتیجه نهایی را به جلسه اصلی برمیگرداند و تمام خروجیهای میانی ابزارها دور ریخته میشوند.
برای مثال، خواندن یک لاگ ۲۰ هزار توکنی در جلسه اصلی Opus با ۳۰ نوبت باقیمانده، حدود ۰.۵۰ دلار هزینه دارد و نویز دائمی ایجاد میکند. ارسال همان لاگ به یک عامل فرعی Haiku تنها حدود ۰.۰۶ دلار هزینه دارد و جلسه اصلی را پاک نگه میدارد. جالب اینجاست که هزینه ایجاد این عاملهای فرعی در عمل بسیار کمتر از تخمینهای اولیه بود و بهرهوری سیستم را افزایش داد.
پیادهسازی عاملهای فرعی:
این عاملها در مسیر .claude/agents/ با استفاده از YAML frontmatter برای تعیین مدل، سطح تلاش و ابزارها تعریف میشوند. یک اشتباه رایج (Anti-pattern)، استفاده از ارتشی از عاملها برای مدیریت (Orchestration) است؛ چون هر کدام پیشوند خود را بازسازی میکنند، ممکن است هزینه خواندن چندینباره یک کدبیس را بپردازید. عاملهای فرعی باید برای «ایزولهسازی» باشند، نه «مدیریت».
گردشکار بهینه: برنامهریزی بزرگ، اجرا کوچک
مقرونبهصرفهترین الگو این است که «بزرگ برنامهریزی کنید و کوچک اجرا کنید». این شامل برنامهریزی کل تسک در یک جلسه با تلاش بالا و مدل بزرگی مثل Fable برای تولید یک فایل PLAN.md است.
الگوی اجرا:
۱. برنامهریزی: استفاده از مدل بزرگ با تلاش بالا برای ایجاد PLAN.md. این فایل باید کار را به زیر-تسکها تقسیم کرده، فایلهای درگیر را لیست کند، نکات حساس (Gotchas) کشف شده را یادداشت کند و برای هر زیر-تسک یک مدل و سطح تلاش پیشنهاد دهد.
۲. اجرا: هر زیر-تسک را در یک جلسه تازه (/clear) شروع کنید. به @PLAN.md ارجاع دهید و مدل و تلاش را در همان لحظه اول — که «لحظه ارزان» است — تنظیم کنید.
۳. نقطه بازرسی: در هر «نقطه سبز» (زمانی که تستها پاس میشوند) کامیت کنید. فایل PLAN.md را با آنچه تکمیل شده و هرگونه انحراف از برنامه بهروزرسانی کنید.
این روش از رشد درجهدوم هزینههای جلسات طولانی جلوگیری میکند. یک تسک ۴۰ مرحلهای، اولین نوبت را ۴۰ بار ارسال میکند؛ تقسیم آن به دو جلسه ۲۰ مرحلهای حدود ۱۵٪ ارزانتر است (بهطور تقریبی).
ارزیابی ابزارهای کاهش توکن
برخی ابزارهای جامعه توسعهدهندگان ادعای کاهش هزینه دارند، اما بنچمارکهای JetBrains در اواسط ۲۰۲۶ هشدار میدهند. فرمول ارزیابی هر نوبت این است: تاریخچه × ۰.۱ × قیمت ورودی + توکنهای جدید × ۲ × قیمت ورودی + خروجی × قیمت خروجی.
بنچمارک ابزارها:
- rtk: این پروکسی CLI نوشته شده با Rust، خروجی Bash را فشرده میکند. JetBrains دریافت در تلاش بالا تفاوتی ایجاد نمیکند و در تلاش پایین، جلسات ۷.۶٪ گرانتر شدند چون مدل برای بازیابی دادههای فیلتر شده توسط rtk، دستورات را دوباره اجرا میکرد. همچنین ریسک حذف مارکرهای
git pushرا دارد که منجر به حلقههای تکرار بینهایت میشود. - caveman: این مهارت مدل را مجبور به استفاده از نثر بسیار کوتاه (Terse) میکند. در پرسوپاسخهای متنی تا ۵۰٪ توکن خروجی را کم میکند، اما در کدنویسی که خروجیها عمدتاً کد یا فراخوانی ابزار هستند، هزینه دستورات اضافی (حدود ۱۲۵۰ توکن ورودی در هر نوبت) میتواند تبادلات کوتاه را گرانتر کند.
- سرورهای MCP ایندکس کدبیس: اینها از بردار معنایی (Embedding) — شبیه به کارت معرفی عددی برای هر واژه که همسایگانش را میگوید — برای بازیابی تکههای کد استفاده میکنند. ادعای ۹۰٪ کاهش هزینه دارند، اما طرح ابزارها (Tool Schemas) را در هر نوبت به زمینه پایه اضافه میکنند. ارجاع مستقیم با
@اغلب موثرتر و ارزانتر است.
چکلیست نهایی برای توسعهدهندگان
برای حفظ یک بودجه بهینه، توسعهدهندگان باید این عادتها را دنبال کنند:
شروع جلسه:
- اجرای
/contextبرای پاکسازیCLAUDE.mdو غیرفعال کردن سرورهای MCP بلااستفاده. - تایید آگاهانه
/modelو/effortو سپس دست نزدن به آنها. - ارجاع به فایلهای شناخته شده با
@فقط یکبار.
در طول جلسه:
- استفاده از پرچمهای خاموش در
CLAUDE.mdبرای دستورات پرنویز. - هدایت خروجیهای حجیم به یک عامل فرعی.
- در پایان هر نوبت تصمیمگیری: ادامه، بازگشت (Rewind)، پاکسازی (Clear)، فشردهسازی (Compact) یا استفاده از عامل فرعی.
- کامیت در نقاط سبز و ثبت پیشرفت در یک فایل
PROGRESS.md.
قبل از استراحت یا تغییر:
- اجرای
/compactدر حالی که حافظه گرم است، همراه با دستورات صریح درباره آنچه باید حفظ شود. - تنها پس از آن، تغییر مدل یا سطح تلاش.
- بین تسکها، تغییر نام جلسه با
/renameو سپس اجرای/clear.
در نهایت، هدف این است که اطمینان حاصل شود هر توکنی که برایش هزینه پرداخت میشود، صرف تسک واقعی شود، نه صرف پرامپتهای سیستمی، لاگهای قدیمی یا شکستهای تصادفی حافظه پنهان.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو