«اتلاف شدید توکن»؛ نقطه ضعف Claude Code در پردازش فایل‌های حجیم

اگر امروز از Claude Code برای مدیریت پروژه‌های بزرگ استفاده می‌کنید، احتمالاً متوجه شده‌اید که حافظهٔ مدل به‌سرعت پر می‌شود و هزینه‌های استنتاج بالا می‌رود. یک خوانش ساده از یک فایل در Claude Code می‌تواند تا ۵ برابر بیشتر از مقدار مورد نیاز توکن مصرف کند و محدودیت‌های جلسه را به‌سرعت به پایان برساند. طبق گزارشی که در ۱۲ اکتبر ۲۰۲۶ منتشر شد، یک بررسی فنی عمیق فاش کرد که عامل‌های هوش مصنوعی اغلب برای یافتن یک تابع کوچک، کل فایل منبع را می‌بلعند. این اتفاق یک «مالیات توکنی» سنگین ایجاد می‌کند که در تمام درخواست‌های بعدی همان جلسه، همراه با متن ارسال می‌شود و فضای مدل را اشغال می‌کند.

این ناکارآمدی درست زمانی رخ می‌دهد که توسعه‌دهندگان برای گسترش قابلیت‌های AI به سرورهای پروتکل زمینهٔ مدل (MCP) — که شبیه به یک رابط استاندارد برای اتصال مدل به ابزارهای خارجی است — متکی شده‌اند. همان‌طور که در تحلیل قبلی ما درباره‌ی OmniForce MCP Server اشاره کردیم، ابزاری که به Claude و Cursor اجازه می‌دهد رویت‌پذیری جست‌وجوی AI را حسابرسی کنند، صنعت را به سمت الگوهای پیچیده‌تر از ابزارها می‌برد. اما با افزایش ابزارها، حجم داده‌هایی که وارد پنجرهٔ زمینه (Context Window) — یعنی میز کاری مدل که تعیین می‌کند چه مقدار اطلاعات را هم‌زمان در ذهن نگه دارد — می‌شود، بدون کنترل رشد می‌کند.

هزینه پنهان نتایج ابزارها

به نقل از گزارشی در dev.to، مدل Claude Code تاریخچه کامل گفتگو را با هر درخواست جدید ارسال می‌کند. وقتی مدل از ابزاری مثل «خواندن فایل» استفاده می‌کند، متن حاصل به جلسه اضافه می‌شود. این داده‌ها تا زمانی که کاربر دستور /clear را اجرا کند یا جلسه فشرده شود، در حافظه باقی می‌مانند. این سازوکار با منطق مدیریت جلسات و سیستم کشینگ در Claude Code پیوند خورده است تا تا حد امکان هزینه‌های تکراری کاهش یابد.

این سازوکار در مستندات هزینه خود Anthropic تایید شده است. چون کل گفتگو در هر درخواست ارسال می‌شود، یک فایل حجیم که یک‌بار خوانده شده، در تمام درخواست‌های بعدی «سوار» بر متن می‌شود و هر بار هزینه یا فضای پنجره را می‌بلعد.

اگرچه سیستم کشینگ (Caching) شرکت آنتروپیک هزینه خواندن مجدد را کم می‌کند، اما رایگان نیست. در طرح‌های Pro یا Max، این توکن‌ها همچنان از سقف کل پنجرهٔ زمینه کم می‌کنند. دستورات داخلی /context و /usage نشان می‌دهند چه چیزی فضا را اشغال کرده، اما در شناسایی اینکه کدام فراخوانی ابزار یا کدام فایل خاص مقصر اصلی است، ناتوان هستند.

محدودیت‌های نظارت داخلی

کاربران طرح‌های Pro یا Max می‌توانند با دستور /usage فعالیت‌های اخیر را بر اساس مهارت‌ها، زیر-عامل‌ها، پلاگین‌ها و هر یک از سرورهای MCP به‌صورت تفکیک شده بررسی کنند. این ابزار مواردی را که بیش از ۱۰٪ مصرف اخیر را اشغال کرده‌اند، به عنوان مشکلاتی نظیر «زمینه طولانی» (Long Context) یا «خطای کش» (Cache Miss) علامت‌گذاری می‌کند.

با این حال، هیچ‌کدام از دستورات /context یا /usage فاش نمی‌کنند که دقیقاً کدام فراخوانی ابزار یا کدام فایل باعث ورود آن متن به پنجره شده است. برای یافتن پاسخ، توسعه‌دهندگان باید مستقیماً به لاگ‌های جلسه که روی دیسک محلی آن‌ها ذخیره شده است، مراجعه کنند.

اندازه‌گیری اتلاف توکن

برای حل این مشکل، اسکریپتی پایتونی به نام toolcost.py توسعه یافته تا لاگ‌های JSONL موجود در مسیر ~/.claude/projects/ را تحلیل کند. این اسکریپت بلوک‌های tool_use (که حاوی یک شناسه و نام ابزار هستند) را با بلوک‌های متناظر tool_result (که همان شناسه را دارند) تطبیق می‌دهد تا ابزارها را بر اساس میزان مصرف توکن رتبه‌بندی کند.

برای اجرای این تحلیل، کاربران باید توکن‌ساز (Tokenizer) مورد نیاز را نصب کرده و اسکریپت را روی آخرین جلسه اجرا کنند:

pip install tiktoken
python toolcost.py

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

یافته‌های رایج از تحلیل لاگ‌ها عبارتند از:

• خروجی Bash: مصرف بالای توکن اغلب ناشی از خروجی‌های مفصل تست‌ها یا لاگ‌های بیلد است. این‌ها باید قبل از رسیدن به مدل فیلتر شوند یا به یک زیر-عامل سپرده شوند تا فقط خلاصه آن‌ها بازگردد.
• ابزارهای MCP: برخی سرورها «دیوارهایی از متن» برمی‌گردانند. توسعه‌دهندگان باید بررسی کنند آیا می‌توان از سرور داده‌های کمتری خواست یا اینکه آیا لازم است سرور در تمام طول روز متصل باشد.
• ابزار Read: متهم اصلی؛ جایی که عامل‌ها برای یافتن بخش‌های کوچک کد، کل فایل‌ها را می‌خوانند.

جریمهٔ «کل فایل»

برای نمایش این شکاف، نویسنده خواندن کامل یک فایل را با خواندن هدفمند یک تابع در CPython 3.12.4 مقایسه کرد. فایل json/decoder.py دارای ۳,۰۲۴ توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — است (اندازه‌گیری شده با tiktoken cl100k_base). اما تابع py_scanstring در این فایل تنها ۵۵۷ توکن دارد.

عاملی که کل فایل را برای دسترسی به یک تابع می‌خواند، بیش از ۵ برابر داده‌ی اضافی مصرف می‌کند. این فاصله با بزرگ‌تر شدن فایل‌ها بیشتر می‌شود و اسکن‌های گسترده را به عادتی گران‌قیمت برای عامل‌های AI تبدیل می‌کند. برای یک فایل ۳۵۶ خطی، این اتلاف از همین حالا قابل توجه است و برای فایل‌های بزرگ‌تر، جریمه بسیار شدیدتر می‌شود. این چالش در حالی رخ می‌دهد که Claude Code در بازسازی‌های چندفایلی و مدیریت پروژه‌های پیچیده عملکردی پیشتاز دارد، اما همچنان با مشکل اتلاف توکن در سطح فایل دست‌وپنجه نرم می‌کند.

استراتژی‌های کاهش توکن

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

• پرس‌وجوی محدودتر: به‌جای درخواست کلی مثل «بهبود کدبیس» (که باعث اسکن‌های گسترده می‌شود)، نام دقیق فایل و تابع را ذکر کنید.
• مدیریت جلسه: هنگام تغییر موضوع به تسک‌های نامرتبط، از /clear استفاده کنید تا داده‌های قدیمی دوباره ارسال نشوند.
• هوش کدنویسی: نصب پلاگین‌های زبان‌های Typed. آنتروپیک اشاره می‌کند که یک فراخوانی 'go-to-definition' می‌تواند جایگزین چرخه گران‌قیمت جست‌وجو (grep) و خواندن شود. این یک قابلیت رایگان و رسمی از طرف آنتروپیک است.

برای راهکاری سیستمی، سرور MCP به نام jCodeMunch یک نمایه نمادها (Symbol Index) ارائه می‌دهد. به‌جای خواندن کل فایل، این ابزار مخزن را یک‌بار نمایه‌سازی کرده و تابع یا کلاس مورد نظر را با استفاده از آفست بایت (Byte Offset) به عامل می‌دهد. نصب آن تنها با دو دستور و بدون نیاز به API Key انجام می‌شود:

pip install jcodemunch-mcp
jcodemunch-mcp init

در بنچمارکی روی ۱۵ تسک در سه مخزن واقعی، این روش میانگین ۹۵٪ از توکن‌های خواندن کد را کاهش داد. در یک مورد شدید در مخزن fastapi/fastapi، این نمایه خواندن احتمالی ۲۱۴,۳۱۲ توکن از درخت منبع را به تنها ۴۸۰ توکن کاهش داد. این رویکرد در واقع نوعی فشرده‌سازی زمینه برای کاهش هزینه‌های توکنی است که می‌تواند بهره‌وری عامل‌های AI را به شدت افزایش دهد.

اعتبارسنجی راهکار

برای اطمینان از اثرگذاری نمایه، توسعه‌دهندگان باید دوباره toolcost.py را روی جلسه‌ای که همان کارها را انجام می‌دهد اجرا کنند. نتایج نمایه در ردیف‌های mcp__jcodemunch__ ظاهر می‌شوند. اگر کاهش در ردیف Read بیشتر از افزایش در ردیف‌های نمایه نباشد، ابزار سود خالص ایجاد نکرده و باید حذف شود.

تحلیل تحریریه

این کشف، نقش توسعه‌دهنده را از یک «مهندس پرامپت» به یک «مدیر زمینه» (Context Manager) تغییر می‌دهد. گلوگاه در AI عامل‌محور دیگر فقط قدرت استدلال مدل نیست، بلکه کارایی خط لوله داده‌ای است که مدل را تغذیه می‌کند. وقتی یک عامل ۲۰۰ هزار توکن را برای یافتن ۵۰۰ توکن می‌خواند، این فقط یک مسئله هزینه نیست، بلکه یک ریسک عملکردی است؛ زیرا نویز بیش از حد می‌تواند تمرکز مدل را کاهش دهد.

برای یک توسعه‌دهنده حرفه‌ای، این بدان معناست که «جعبه سیاه» استفاده از ابزارهای AI باید باز شود. اندازه‌گیری محلی هزینه‌های ابزار به کاربران اجازه می‌دهد تصمیم بگیرند کدام سرورهای MCP ارزش افزوده‌ ایجاد می‌کنند و کدام‌ها صرفاً باعث حجیم شدن جلسه می‌شوند. توانایی حسابرسی لاگ‌های JSONL، کاربر را از یک مصرف‌کننده غیرفعالِ محدودیت‌های اشتراکی، به یک بهینه‌ساز فعال در پشته AI خود تبدیل می‌کند.

توسعه‌دهندگان اکنون باید toolcost.py را روی آخرین جلسات خود اجرا کنند تا متهمان اصلی مصرف توکن را شناسایی کنند. مرز بحرانی بعدی این خواهد بود که آیا ارائه‌دهندگان AI قابلیت «برش هوشمند» (Smart-cropping) خودکار نتایج ابزارها را قبل از ورود به پنجره زمینه پیاده‌سازی می‌کنند یا خیر.

گام بعدی شما

• اسکریپت toolcost.py را روی آخرین جلسات خود اجرا کنید تا متهمان اصلی مصرف توکن را شناسایی کنید.
• برای پروژه‌های بزرگ، سرور jCodeMunch را نصب کنید تا از خواندن کورکورانه فایل‌ها جلوگیری شود.
• عادت کنید هنگام تغییر تسک در Claude Code، حتماً از دستور /clear استفاده کنید.

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