«رشد درجه دوم هزینه‌ها»؛ اثر مخرب طول جلسه بر مصرف توکن

اگر امروز از عامل‌های کدنویسی برای پروژه‌های بزرگ استفاده می‌کنید، احتمالاً متوجه شده‌اید که صورت‌حساب API شما بسیار سریع‌تر از حد انتظار رشد می‌کند. حقیقت این است که یک گفتگوی طولانی با یک عامل هوش مصنوعی، می‌تواند به‌دلیل یک منحنی هزینه درجه‌دوم (Quadratic Cost)، مخفیانه بودجه شما را ببلعد. دلیل این اتفاق ساختار فنی این ابزارهاست. به نقل از مستندات فنی Claude Code، این عامل به‌صورت بدون وضعیت (Stateless) عمل می‌کند؛ یعنی در هر بار فراخوانی ابزار، تمام تاریخچه گفتگو از ابتدا ارسال می‌شود. در این ساختار، هیچ چیزی رایگان نیست، حتی اگر قبلاً آن را گفته باشید. توکنی که در ابتدای جلسه تولید شده، در هر نوبت جدید که پس از آن می‌آید، دوباره پرداخت می‌شود. بنابراین، طول جلسه — و نه یک اقدام خاص و «گران‌قیمت» — محرک واقعی هزینه‌هاست.

این سازوکار یک «مالیات پنهان» بر بهره‌وری ایجاد می‌کند. اکثر توسعه‌دهندگان بر اساس شهود خود حدس می‌زنند که کدام عادت‌ها گران هستند، اما واقعیت متفاوت است. طبق گزارش یک تحلیل اخیر روی مجموعه‌ای شامل ۲۳۳۵ فایل و ۵۲۹ جلسه، سه مورد از چهار فرضیه اولیه توسعه‌دهندگان درباره علت اتلاف توکن کاملاً اشتباه بود. این یعنی تکیه بر شهود برای حدس زدن اقدامات گران‌قیمت استراتژی نامعتبری است. تنها راه شناخت واقعیت و درک آنچه در پس‌زمینه رخ می‌دهد، اندازه‌گیری یک مجموعه داده (Corpus) واقعی است. این چالش درک هزینه‌ها، ریشه در ساختار قیمت‌گذاری مدل‌ها دارد که در تحلیل ما پیرامون گمراه‌کننده بودن مدل‌های پرداخت توکنی به تفصیل بررسی شده است.

همان‌طور که در تحلیل‌های قبلی ما درباره مدیریت پنجره متنی اشاره کردیم، درک نحوه ذخیره‌سازی داده‌ها در حافظه مدل برای بهینه‌سازی هزینه حیاتی است. برای مقابله با این اتلاف، مخزن agentic-ways-of-working (به نشانی github.com/nino-chavez/agentic-ways-of-working) دو ابزار خودکار فوری ارائه داده است تا پیش از آنکه حتی داده‌های خود را اندازه‌گیری کنید، جلوی خروج سرمایه را بگیرید.

اولین ابزار، read-guard.py است که یک قلاب (Hook) از نوع PreToolUse برای کنترل خواندن فایل‌هاست. این ابزار دو الگوی تکراری خاص را مسدود می‌کند و در همان پاسخ، راهکار اصلاحی را ارائه می‌دهد. نخست، خواندن تصاویر بیش از حد بزرگ را می‌بندد؛ هر تصویری که ضلع بلندتر آن بیش از ۱۴۰۰ پیکسل باشد، مسدود شده و به‌جای آن نسخه‌ای با ۱۰۰۰ پیکسل جایگزین می‌شود. دوم، بازخوانی فایلی که در ۱۰ دقیقه اخیر تغییر نکرده است را متوقف کرده و کاربر را یادآور می‌شود که به آنچه پیش‌تر در زمینه (Context) قرار گرفته است استناد کند. تلاش مجدد (Retry) بلافاصله پس از این هشدار همیشه با موفقیت انجام می‌شود؛ این یعنی ابزار بدون ایجاد یک دیوار سخت، برای عادت‌های بازتابی و ناخودآگاه توسعه‌دهنده اصطکاک ایجاد می‌کند تا او را به بهینه‌سازی وادارد. این ابزار کمک می‌کند تا کاربر به جای بازخوانی کل کتابخانه، از محتوای موجود در پنجره زمینه (Context Window) — که شبیه میز کاری است که جا برای چند ورق دارد، نه برای کل کتابخانه — استفاده کند.

دومین ابزار، statusline.py است؛ یک نمایشگر در ترمینال که مدل، توکن‌های زمینه و مسیر جاری (cwd) را نشان می‌دهد. این ابزار با کدهای رنگی در آستانه‌های ۵۰ و ۸۰ درصد طراحی شده است. به این ترتیب، «چاق شدن» جلسه فراتر از یک نقطه معقول، به‌صورت لحظه‌ای و در زمان واقعی دیده می‌شود، نه اینکه کاربر سه فراخوانی ابزار بعد متوجه این موضوع شود.

برای نصب این ابزارها، کسانی که پیش از این کارگاه /doctor را گذرانده‌اند، می‌توانند این ابزارها را از طریق همان مخزن متصل کنند. نصب‌کننده این ابزارها به‌صورت Idempotent است؛ به این معنا که ابتدا از فایل settings.json شما نسخه پشتیبان می‌گیرد و تنها ثبت‌های قلابی (Hook Registrations) را اضافه می‌کند که هنوز وجود ندارند. این تضمین می‌کند که پیکربندی‌های موجود در statusline هرگز بازنویسی یا پاک نشوند.

کاربران می‌توانند مجموعه کامل را با مراحل زیر نصب کنند:

cd ~/agentic-ways-of-working
./install.sh

به‌طور جایگزین، می‌توان کلون کردن و نصب را در یک مرحله انجام داد:

git clone https://github.com/nino-chavez/agentic-ways-of-working.git ~/agentic-ways-of-working
cd ~/agentic-ways-of-working
./install.sh

پس از اجرای نصب‌کننده، جلسه Claude Code خود را بازراه‌اندازی کنید. باید نوار وضعیت را در پایین ترمینال ببینید که مدل، میزان استفاده فعلی از زمینه و دایرکتوری کاری شما را نمایش می‌دهد. برای تست کردن قلاب، فایلی را که در چند دقیقه اخیر تغییر نداده‌اید بخوانید و سپس بلافاصله همان فایل را دوباره بخوانید. خوانش دوم باید یک بار با یک یادآور مسدود شود و تلاش مجدد بلافاصله پس از آن باید بدون مشکل انجام شود. این موضوع تأیید می‌کند که قلاب طبق طراحی عمل می‌کند.

برای اندازه‌گیری دقیق اتلاف، به‌جای حدس زدن، توسعه‌دهندگان می‌توانند از ابزار token-audit.py برای تحلیل جریان لاگ‌های جلسات که در مسیر ~/.claude/projects/**/*.jsonl قرار دارند استفاده کنند. این ابزار قادر است مجموعه‌های چند گیگابایتی را در کمتر از دو دقیقه پردازش کرده و گزارش دهد که توکن‌ها واقعاً کجا هزینه شده‌اند، نه جایی که شما حدس می‌زنید. این رویکرد داده‌محور برای ردیابی هزینه‌ها، مشابه آنچه در ابزار Tokscale برای تبدیل حس هزینه‌ها به رسیدهای دقیق مشاهده می‌کنیم، عمل می‌کند.

این ابزار با پایتون ۳ و چندین پرچم (Flag) اختیاری اجرا می‌شود:

• --days: بازه زمانی بررسی را کنترل می‌کند (پیش‌فرض ۶۰ روز است). کاربران جدید باید این بازه را به ۱۴ روز یا هر مقدار تاریخچه‌ای که واقعاً دارند کاهش دهند تا تصویر پایداری به دست آورند. بازه کوتاه همچنان داده می‌دهد، هرچند پایداری کمتری دارد.
• --projects-dir: به کاربر اجازه می‌دهد اگر داده‌های Claude Code در مسیر پیش‌فرض ~/.claude/projects نیستند، مسیر جایگزین را مشخص کند.
• --top: تعداد متخلفان برتر را در هر دسته کنترل می‌کند.

مثال اجرا:
python3 tools/token-audit.py --days 60

اگر گزارش اساساً خالی بود، بررسی کنید که --projects-dir دقیقاً به مکان واقعی لاگ‌های جلسات شما اشاره می‌کند.

بر اساس گزارش‌های این ابزار، پنج معیار حیاتی وجود دارد که کل داستان اتلاف توکن را روایت می‌کنند. درک این اعداد تنها راه تبدیل یک گزارش به یک برنامه عملیاتی است:

• ضریب بازپخش (Replay Multiplier): این نسبتِ «خوانش‌های حافظه» به «توکن‌های نوشته شده» است. چون API بدون وضعیت است، هزینه واقعی یک بسته داده، اندازه آن ضرب در هر فراخوانی API است که پس از آن می‌آید. در مجموعه داده مرجع، این عدد ۴۱ برابر بود. اعداد بالا در اینجا نشان می‌دهد که هزینه جلسه در تعداد نوبت‌ها به‌صورت درجه‌دوم در حال رشد است. راهکار در اینجا به‌ندرت کاهش حجم داده‌های ارسالی است، بلکه کوتاه‌تر کردن جلسات و واگذاری اکتشافات به عامل‌های فرعی (Subagents) است که زمینه آن‌ها با پایان کارشان می‌میرد.
• نرخ بازخوانی تکراری (Redundant Re-read Rate): این معیار اندازه‌گیری می‌کند که یک فایل در یک جلسه، در حالی که محتوایش تغییر نکرده، چند بار خوانده شده است. این معمولاً نشانه جلسات طولانی است که در آن «فشرده‌سازی زمینه» (Context Compaction) نتایج ابزارها را حذف می‌کند و عامل را مجبور می‌کند آنچه را که گم کرده دوباره بخواند؛ این بازخوانی به نوبه خود زمینه را رشد داده و باعث فشرده‌سازی بیشتر می‌شود. قلاب read-guard به‌عنوان یک ترمز عمل می‌کند، اما راهکار واقعی، کوتاه‌تر کردن جلسات است.
• خوانش تصاویر (Image Reads): هزینه تصاویر بر اساس ابعاد پیکسل محاسبه می‌شود، نه حجم فایل. یک اسکرین‌شات با رزولوشن کامل می‌تواند چندین برابر گران‌تر از یک نسخه برش‌خورده و تغییر اندازه یافته باشد. در داده‌های مرجع، تصاویر ۷۸٪ از کل بایت‌های خوانده شده را تشکیل می‌دادند، که عمدتاً به دلیل بازخوانی ده‌ها بار تصاویر تمام‌صفحه در طول جلسات طراحی (Design-loop) بود.
• نسبت نوشتن حافظه (Cache-write Ratio): این نسبتِ «نوشتن در حافظه» به «ورودی‌های تازه» است. نوشتن حدود ۱.۲۵ برابر گران‌تر از قیمت ورودی است. این اتفاق در هر بار ایجاد یک عامل فرعی و یا هنگام انقضای TTL حافظه (که بعد از حدود ۵ دقیقه بیکاری رخ می‌دهد) می‌افتد. نسبت بالا نشان می‌دهد که یک جلسه «چاق» پس از مدتی بیکاری دوباره باز شده و کل زمینه را با نرخ گران‌قیمت بازنویسی می‌کند.
• توزیع مدل (Per-model Spread): حافظه‌ها (Caches) برای هر مدل مجزا هستند. تغییر مدل در میان یک جلسه، باعث شروع یک حافظه سرد (Cold Cache) برای مدل جدید می‌شود و تمام بهره‌وری نوبت‌های قبلی را پاک می‌کند. در واقع، انتخاب نادرست مدل یا جابجایی‌های بی‌مورد می‌تواند منجر به جهش‌های شدید و غیرمنتظره در هزینه‌های نهایی شود.

هدف نهایی این است که شناسایی یک عدد بالا در گزارش تحلیل، منجر به یک تغییر رفتاری مشخص شود. اندازه‌گیری‌ای که عادتی را تغییر ندهد، صرفاً یک تمرین پژوهشی است، نه یک حسابرسی (Audit). هدف این است که تنها یک ردیف از گزارش که با بزرگ‌ترین عدد شما مطابقت دارد را انتخاب کنید و متعهد شوید که برای جلسه بعدی، یک تغییر عادت مشخص را پیاده کنید.

بسته به یافته‌های گزارش، مداخلات زیر توصیه می‌شود:

• ضریب بازپخش بالا: از جلسات کوتاه‌تر استفاده کنید. به‌جای حفظ یک رشته طولانی، بین تکالیف نامرتبط از دستور /clear استفاده کنید. اکتشافات چندفایلی را به عامل‌های فرعی بسپارید، به‌خصوص زمانی که فقط نتیجه نهایی برای تکلیف اصلی مهم است.
• نرخ بازخوانی تکراری بالا: برای رفع علت اصلی، جلسات را کوتاه‌تر کنید. اگرچه قلاب read-guard به‌عنوان یک پشتیبان عمل می‌کند، اما کاهش طول جلسه از چرخه «فشرده‌سازی-بازخوانی» جلوگیری می‌کند.
• خوانش تصاویر بیش از حد: این مورد به‌طور خودکار توسط قلاب read-guard مدیریت می‌شود. اگر این عدد همچنان بالا بود، احتمالاً بازتابی از تاریخچه قدیمی پیش از نصب قلاب است؛ چند هفته دیگر دوباره بررسی کنید.
• نسبت نوشتن حافظه بالا: از باز کردن دوباره جلساتی که مدتی بیکار بوده‌اند دست بردارید. جلسات را به‌طور کامل ببندید به‌جای اینکه آن‌ها را در پس‌زمینه باز بگذارید.
• تسلط یک ابزار خاص بر گزارش: یک مرحله «خلاصه سازی» (Digest) در منبع اضافه کنید. به‌جای بازخوانی یک اثر خام و بزرگ، تنها ۲۰ فیلدی را که واقعاً نیاز دارید استخراج کنید.

این چارچوب اندازه‌گیری در چهار تمرین مجزا تقسیم شده است تا اطمینان حاصل شود که اندازه‌گیری به یک «نمایش» تبدیل نمی‌شود و واقعاً به تمرین تبدیل می‌گردد:
۱. نصب بخش مکانیکی: اطمینان از اینکه اصلاحات خودکار (قلاب‌ها و نوار وضعیت) در حال اجرا هستند تا از اتلافی که در هر نوبت متوجه آن نمی‌شوید، محافظت کنند.
۲. اندازه‌گیری به‌جای حدس زدن: استفاده از token-audit.py برای جلوگیری از ساختن راهکارهایی برای مشکلاتی که واقعاً ندارید، بر اساس تاریخچه واقعی و نه شهود.
۳. خواندن پنج عدد کلیدی: ترجمه معیارهای خام به درکی از اینکه گام بعدی چیست، تا اطمینان حاصل شود گزارش واقعاً مفید است.
۴. تبدیل یک عدد به یک تغییر: تعهد به یک تغییر عادت واحد برای اطمینان از اینکه حسابرسی منجر به صرفه‌جویی واقعی می‌شود، نه اینکه صرفاً «نمایشِ اندازه‌گیری» باشد.

برای نگهداری بلندمدت، در حالی که نوار وضعیت بازخوردی زنده از جلسه فعلی می‌دهد، ابزار تحلیل یک نگاه به گذشته است. برای تغییر واقعی صورت‌حساب توکن‌ها، توسعه‌دهنده باید هر چند هفته یک‌بار این تحلیل را اجرا کند، مشابه فرآیند پیشنهادی در کارگاه /doctor. یک اندازه‌گیری تنها یک عکس لحظه‌ای است؛ پیروزی واقعی در تأیید این است که تغییر عادت در تمرین چهارم، در دومین بار بررسی اعداد همچنان برقرار است. اگر عدد تغییر نکرد، یعنی راهکار با علت مطابقت نداشته و باید دوباره به معیارها برای ارزیابی مجدد بازگردید.

گام بعدی شما

• ابزار token-audit.py را روی لاگ‌های ماه گذشته اجرا کنید تا متوجه شوید بیشترین هزینه شما مربوط به بازخوانی فایل‌هاست یا تصاویر.
• عادت کنید هر زمان که موضوع گفتگو تغییر می‌کند، جلسه را با /clear پاک کنید تا از رشد درجه‌دوم هزینه‌ها جلوگیری شود.
• نوار وضعیت statusline.py را نصب کنید تا در لحظه از «چاق شدن» پنجره متنی آگاه شوید.

اما داستان سخت‌افزاری این تحول و نحوه مدیریت حافظه در لایه‌های پایین‌تر حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.