جلوگیری از کندی و هزینه بالای Claude Code

چگونه از کند و پرهزینه شدن یک نشست طولانی Claude Code جلوگیری کنیم

یک نشست طولانی Claude Code به این دلیل کند و پرهزینه می‌شود که در هر نوبت، کل محتوا (context) مجدداً ارسال می‌شود و این محتوا دائماً در حال افزایش است. راه‌حل، رعایت بهداشت نشست در یک ترتیب مشخص است. دستور /context را اجرا کنید تا ببینید چه چیزی پنجره محتوا را پر کرده است، سپس مواردی که بابت هر درخواست برای آن‌ها هزینه می‌پردازید را حذف کنید. پس از آن، بین وظایف نامرتبط از /clear و در طول یک وظیفه طولانی از /compact به همراه یک دستورالعمل استفاده کنید. کار را به صورت پیوسته انجام دهید، زیرا سرد شدن حافظه پنهان (prompt cache) باعث می‌شود یک خواندن ارزان، به بازنویسی کامل تمام گفته‌های شما تبدیل شود.

دلیل اینکه چرا کنتور هزینه در تمام مدت فعال است، در کنتور توکن در پشت یک نشست عامل توضیح داده شده است.

پیش از هر تغییری، /context را بخوانید

حدس نزنید که چه چیزی پنجره را پر می‌کند. Claude Code به شما خواهد گفت.

/context [all] وضعیت فعلی مصرف context را به صورت یک شبکه رنگی نمایش می‌دهد، همراه با پیشنهادهایی برای بهینه‌سازی ابزارهای سنگین و کاهش اشغال حافظه؛ all جزئیات هر مورد را در حالت تمام‌صفحه باز می‌کند. نتیجه را به عنوان پنج دسته در نظر بگیرید.

• پرامپت سیستم. دستورالعمل‌های اصلی Claude Code. برای کل نشست ثابت است.
• تعریف ابزارها. طرحواره (schema) برای هر ابزاری که عامل می‌تواند فراخوانی کند، شامل تمام سرورهای متصل MCP (پروتکل زمینه مدل).
• فایل‌های حافظه. CLAUDE.md و حافظه خودکار که در شروع نشست بارگذاری می‌شوند.
• فایل‌ها و نتایج ابزارها. هر فایلی که خوانده شده و هر خروجی که دستورات شما چاپ کرده‌اند.
• تاریخچه پیام‌ها. نوبت‌های شما و پاسخ‌های مدل.

سه مورد اول، هزینه‌ای ثابت هستند که در هر درخواست در طول عمر نشست پرداخت می‌شوند. دو مورد آخر رشد می‌کنند. هزینه ثابت را یک‌بار در ابتدا کاهش دهید؛ بخش در حال رشد را به‌طور مداوم مدیریت کنید.

دو رشته متنی به شما می‌گویند که پنجره پر شده است:

Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue.
Context is 94k tokens past the 200k-token compaction window — run /compact to reduce usage.

اولی یک محدودیت سخت است و درخواست رد می‌شود؛ خطای API (رابط برنامه‌نویسی کاربردی) مربوطه Prompt is too long است. دومی یک پنجره فشرده‌سازی است که می‌تواند در مدل‌های 1 میلیون توکنی، پایین‌تر از پنجره واقعی مدل قرار بگیرد. درخواست‌ها پس از آن همچنان موفق هستند، بنابراین این مورد بیشتر یک هشدار است تا یک رد درخواست.

در طرح‌های پولی، /usage نیمه دیگر را اضافه می‌کند و رفتارهایی مانند context طولانی یا cache miss را علامت‌گذاری کرده و استفاده اخیر را به مهارت‌ها، زیر-عامل‌ها و سرورهای MCP خاص نسبت می‌دهد. اگر به شما اعلام کرد که سهمیه مصرف شده است، اینکه منتظر کدام پنجره محدودیت هستید تعیین می‌کند که آیا کاهش context در حال حاضر به شما کمک می‌کند یا نیاز به مسیر متفاوتی برای ادامه کار دارید.

فایل CLAUDE.md یک هزینهٔ دائمی است، پس آن را مختصر نگه دارید

فایل CLAUDE.md شما در شروع نشست بارگذاری شده و در آنجا باقی می‌ماند. اگر این فایل شامل یک دستورالعمل استقرار مفصل باشد، آن توکن‌ها حتی زمانی که در حال اصلاح یک غلط تایپی در یک فایل تست هستید، در حافظه باقی می‌مانند. توصیه Anthropic این است که فقط موارد ضروری را در آن بگنجانید و فایل را زیر 200 خط نگه دارید.

دستورالعمل‌ها را به مهارت‌ها (Skills) منتقل کنید. یک مهارت فقط هنگام فراخوانی بارگذاری می‌شود، بنابراین گردش کاری که دو بار در هفته اجرا می‌کنید، در روزهای دیگر هزینه‌ای ندارد. مهارت‌ها پس از فشرده‌سازی (Compaction) بودجهٔ خاص خود را دارند: بدنهٔ آن‌ها دوباره تزریق می‌شود، با سقف 5,000 توکن برای هر مهارت و 25,000 توکن در مجموع، که قدیمی‌ترین‌ها ابتدا حذف می‌شوند. برش (Truncation) ابتدای فایل را حفظ می‌کند، بنابراین مهم‌ترین دستورالعمل‌ها را در بالای SKILL.md قرار دهید.

آنچه از فشرده‌سازی جان سالم به در می‌برد، تعیین می‌کند که یک دستورالعمل به کجا تعلق دارد.

• پرامپت سیستم و سبک خروجی بدون تغییر باقی می‌مانند، زیرا بخشی از تاریخچه پیام نیستند.
• فایل CLAUDE.md در ریشه پروژه، قوانین بدون محدوده (unscoped) و حافظه خودکار از روی دیسک دوباره تزریق می‌شوند.
• قانونی که دارای فراداده paths: باشد، تا زمانی که فایل منطبق دوباره خوانده نشود، از دست می‌رود.
• یک CLAUDE.md تو در تو در یک زیرپوشه، تا زمانی که فایلی در آن زیرپوشه دوباره خوانده نشود، از دست می‌رود.
• هوک‌ها (Hooks) همچنان اجرا می‌شوند، زیرا یک هوک به عنوان کد اجرا می‌شود؛ تنها متنی که یک هوک قبلاً اضافه کرده است، همراه با بقیه گفتگو خلاصه‌سازی می‌شود.

بنابراین قانونی که به آن وابسته‌اید، به CLAUDE.md در ریشه پروژه تعلق دارد: Claude Code ابتدا خروجی‌های قدیمی‌تر ابزارها را پاک کرده و سپس خلاصه‌سازی می‌کند، بنابراین دستورالعمل‌های ابتدای گفتگو ممکن است از دست بروند. حافظه را با /memory ویرایش کنید. Claude Code نسخه‌ای را که در شروع نشست بارگذاری کرده نگه می‌دارد، بنابراین برش (trim) در میانه نشست، حافظه پنهان پرامپت (prompt cache) را حفظ کرده و تا /clear، /compact یا راه‌اندازی مجدد بعدی اعمال نمی‌شود. از دست رفتن محتوا تنها یکی از دلایلی است که یک قانون دیگر رعایت نمی‌شود، بنابراین زمانی که قانون به‌وضوح در پنجره محتوا وجود دارد و همچنان نادیده گرفته می‌شود، پیش از بازنویسی آن، سایر دلایل را بررسی کنید.

پاک‌سازی بین وظایف، فشرده‌سازی در حین یک وظیفه

این دو دستور مشابه به نظر می‌رسند اما هزینه‌های بسیار متفاوتی دارند.

/clear [name] یک گفتگوی جدید با کانتکست خالی شروع می‌کند. چون هیچ درخواستی ارسال نمی‌شود، هزینه‌ای ندارد. یک نام برای برچسب‌گذاری گفتگوی قبلی در انتخابگر /resume وارد کنید؛ /reset و /new جایگزین‌های آن هستند. به محض تغییر به یک وظیفه نامرتبط از آن استفاده کنید، زیرا در غیر این صورت، وظیفه قدیمی در هر پیام جدید مجدداً ارسال و محاسبه هزینه می‌شود.

/compact [instructions] کانتکست را در حین ادامه همان گفتگو آزاد می‌کند: تاریخچه را تا آن لحظه خلاصه کرده و جایگزین می‌کند. از این دستور در یک وظیفه طولانی که نیاز به تداوم دارید استفاده کنید.

همیشه به /compact یک دستورالعمل بدهید. یک /compact خالی بر اساس یک پرامپت پیش‌فرض خلاصه می‌کند که نمی‌داند کدام بخش از کار را هنوز نیاز دارید. دستورالعمل‌دار بودن آن، محتوا را حفظ می‌کند:

/compact focus on the auth bug fix
/compact keep only the plan and the diff

اگر همیشه به یک دلیل فشرده‌سازی می‌کنید، یک دستورالعمل ثابت در CLAUDE.md پروژه خود تحت یک عنوان # Compact instructions قرار دهید. در یک نشست جدید، /compact عبارت Not enough messages to compact. را چاپ می‌کند که به این معنی است که گفتگو برای خلاصه شدن نوبت‌های بسیار کمی دارد؛ این اتفاق حتی با کانتکست کامل هم ممکن است رخ دهد، زمانی که یک جای‌گذاری (paste) بزرگ آن را پر کرده باشد.

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

دو دستور ارزان‌تر وجود دارد. /rewind کد و گفتگو را به یک نقطه بازرسی (checkpoint) برمی‌گرداند؛ برای مسیری که می‌خواهید کاملاً رها کنید، این کار بهتر از فشرده‌سازی است، زیرا آن را تا پیشوندی که از قبل کش شده است، کوتاه می‌کند. /recap یک خلاصه را به عنوان خروجی دستور اضافه می‌کند به جای اینکه جایگزین تاریخچه شود، بنابراین پیشوند کش‌شده دست‌نخورده باقی می‌ماند.

فشرده‌سازی خودکار که مکرراً اجرا شود، این پیام را چاپ می‌کند:

Autocompact is thrashing: the context refilled to the limit...

فشرده‌سازی موفقیت‌آمیز بود، اما یک فایل یا خروجی ابزار، پنجره را چندین بار پشت سر هم پر کرد، بنابراین Claude Code از تلاش مجدد دست کشید. با خواندن فایل حجیم در بازه‌های خطی، اجرای /compact با تمرکزی که خروجی بزرگ را حذف کند، انتقال آن کار به یک subagent، یا /clear اگر گفتگوی قبلی تمام شده است، مشکل را برطرف کنید.

سرویس‌های MCP دارای سربار ثابت هستند

هر سرویس MCP که به آن متصل می‌شوید، به تمام درخواست‌های کل نشست (session) اضافه می‌شود. شما هزینهٔ آن را می‌پردازید، چه از آن استفاده کنید و چه نکنید.

Claude Code این موضوع را تعدیل می‌کند. تعریف ابزارهای MCP به‌صورت پیش‌فرض به تعویق می‌افتد، بنابراین تا زمانی که Claude از یک ابزار خاص استفاده نکند، فقط نام ابزارها وارد context می‌شود. دستور /context را اجرا کنید تا ببینید سرویس‌های شما واقعاً چه هزینه‌ای دارند و از /mcp disable <name> برای حذف سرویسی که امروز به آن نیاز ندارید، استفاده کنید. اگر سرویس‌های MCP خود را روی یک VPS اجرا می‌کنید، همین محاسبات تعیین می‌کند که هر سرور باید حداکثر چند ابزار را ارائه دهد.

این کار را در ابتدای نشست انجام دهید. در حالی که تعاریف به تعویق می‌افتند، اتصال یا قطع اتصال یک سرویس فقط به گفتگو اضافه می‌شود و cache باقی می‌ماند. در مواردی که تعاریف به‌دلیل غیرفعال بودن جستجوی ابزار، در دسترس نبودن آن، یا پایین بودن از آستانه auto مستقیماً در prefix بارگذاری می‌شوند، همین تغییر باعث می‌شود که در درخواست بعدی، همه چیز دوباره خوانده شود.

فیلتر کردن خروجی پرحجم ابزار پیش از ورود به کانتکست

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

فیلتر را در مبدأ انجام دهید. استفاده از یک hook که اجرای آزمایشی را پیش از مشاهده توسط Claude به موارد شکست (failures) محدود می‌کند، آن حجم عظیم خروجی را به چند صد توکن تبدیل می‌کند؛ هم در این نوبت و هم در هر بار ارسال مجدد آن:

npm test 2>&1 | grep -E "FAIL|Error:" | head -40

خودِ hookها هرگز وارد کانتکست نمی‌شوند، زیرا به عنوان کد اجرا می‌گردند. این کار را برای هر ابزاری که خروجی آن از یک صفحه فراتر می‌رود، انجام دهید. همین منطق برای یک فایل 3,000 خطی نیز صادق است: محدوده خطوط مورد نیاز خود را درخواست کنید، زیرا کل فایل پس از دریافت، در پنجره کانتکست باقی می‌ماند.

محدود کردن دامنه خواندن ایجنت و واگذاری کارهای پرحجم

پرامپتی که نام فایل و مشکل را مشخص می‌کند، فقط همان فایل را می‌خواند. در مقابل، یک درخواست کلی برای مرتب‌سازی پروژه، هر فایلی را که ایجنت مرتبط تشخیص دهد می‌خواند و تمام این خواندن‌ها در پنجره context باقی می‌مانند.

کارهای پرحجم را به یک subagent واگذار کنید. اجرای تست‌ها و پردازش لاگ‌ها، بخش قابل‌توجهی از context را مصرف می‌کنند؛ یک subagent این خروجی‌ها را در پنجره اختصاصی خود نگه می‌دارد و فقط یک خلاصه به شما بازمی‌گرداند. نکته مهم: یک subagent کش اختصاصی خود را می‌سازد که در اولین فراخوانی هیچ hit ندارد و حتی در حالت subscription نیز از عمر کش 5 دقیقه‌ای استفاده می‌کند. واگذاری کارها به‌طور مطمئن از context اصلی شما محافظت می‌کند، اما لزوماً همیشه باعث کاهش مجموع توکن‌های مصرفی نمی‌شود.

ساعت کش: کار در بازه‌های زمانی مشخص

کش کردن پرامپت (Prompt caching) همان چیزی است که ارسال مجدد را مقرون‌به‌صرفه می‌کند. نوشتن پیشوند (prefix) هزینه‌ای معادل 1.25 برابر نرخ ورودی پایه، یا در صورت انتخاب طول عمر یک‌ساعته، 2 برابر آن دارد. خواندن مجدد آن 0.1 برابر برای Haiku 5.5، 0.05 برابر برای Opus 5.5 و Sonnet 5.5 (به ترتیب 0.20 دلار و 0.10 دلار به ازای هر میلیون توکن) و 0.025 برابر برای Fable 5.1 (0.25 دلار به ازای هر میلیون توکن) هزینه دارد. هر بار استفاده، ورودی را بدون هزینه اضافی تمدید می‌کند، بنابراین ساعت از زمان آخرین استفاده شروع به کار می‌کند. این ضرایب شکل صورت‌حساب را نشان می‌دهند اما مقدار آن را خیر؛ بنابراین آن‌ها را با هزینه واقعی یک میلیون توکن ترکیب کنید تا یک پنجره متنی کامل را به مبلغ دلاری تبدیل کنید.

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

• در اشتراک Claude، درخواست‌های Claude Code به‌طور خودکار طول عمر یک‌ساعته را دریافت می‌کنند.
• هنگامی که از سقف طرح خود عبور می‌کنید و از اعتبار مصرف (usage credits) استفاده می‌کنید، هزینه آن مصرف از شما کسر می‌شود، بنابراین طول عمر به پنج دقیقه کاهش می‌یابد.
• در استفاده از API key یا ارائه‌دهنده ابری، طول عمر روی پنج دقیقه باقی می‌ماند. تنظیم promptCacheTtl روی 1h یا ENABLE_PROMPT_CACHING_1H=1، طول عمر یک‌ساعته را فعال می‌کند و FORCE_PROMPT_CACHING_5M=1 آن را به حالت قبل بازمی‌گرداند.

توصیه مربوط به ریتم کار در هر دو حالت یکسان است: در بازه‌های زمانی پیوسته کار کنید، زیرا وقفه غیرفعال بیش از طول عمر باعث می‌شود در نوبت بعدی، کل پیشوند انباشته‌شده دوباره نوشته شود. یک نشست جداشده Claude Code در tmux در زمان بیکاری هیچ هزینه‌ای ندارد، اما کش گرم همان چیزی است که با سپری شدن زمان بیکاری از دست می‌رود.

برخی اقدامات باعث می‌شوند کش در حین کار از بین برود: تغییر مدل، تغییر سطح تلاش (effort level) در مدل‌های قدیمی‌تر، روشن کردن حالت سریع (fast mode)، اتصال یا قطع اتصال یک سرور MCP یا رد کردن یک ابزار کامل هنگام بارگذاری تعاریف ابزار در ابتدا، فعال یا غیرفعال کردن افزونه‌ای که ابزار اضافه می‌کند، فشرده‌سازی، حذف تصاویر قدیمی هنگامی که تعداد آن‌ها در یک گفتگو زیاد می‌شود، و ارتقای Claude Code. در Opus 5.5، Sonnet 5.5، Haiku 5.5 و Fable 5.1 با استفاده از API key یا اشتراک، تغییر سطح تلاش اکنون کش را حفظ می‌کند. /model معمولاً غافلگیرکننده است، زیرا هر مدل کش مخصوص به خود را دارد، بنابراین درخواست بعدی کل تاریخچه را بدون استفاده از کش می‌خواند، حتی اگر محتوا یکسان باشد. آن خواندن مجدد با نرخ‌های مدل مقصد به عنوان یک نوشتن کش جدید محاسبه می‌شود، بنابراین تغییر مدل به Fable در میانه نشست، کل تاریخچه انباشته‌شده شما را با نرخ‌های منتشرشده نوشتن کش Fable محاسبه می‌کند: 12.50 دلار به ازای هر میلیون توکن در طول عمر پنج‌دقیقه‌ای یا 20 دلار در طول عمر یک‌ساعته، که برای Fable 5 و Fable 5.1 یکسان است.

ویرایش فایل‌ها، ویرایش CLAUDE.md، فراخوانی مهارت‌ها و دستورات، اجرای /recap، بازگشت به عقب (rewind) و ایجاد یک subagent همگی کش را حفظ می‌کنند. دامنه کش به یک ماشین و یک دایرکتوری محدود است، بنابراین دو نشست در دایرکتوری‌های متفاوت از کش یکدیگر استفاده نمی‌کنند. این دامنه از CLI پیروی می‌کند نه حساب کاربری شما، بنابراین هیچ‌کدام از این موارد به برنامه دسکتاپ Claude منتقل نمی‌شود، که در لینوکس یک نصب بتای جداگانه در کنار CLI است.

برای اینکه ببینید آیا کش کردن کار می‌کند یا خیر، current_usage را بخوانید. cache_creation_input_tokens با نرخ نوشتن کش نوشته شده است؛ cache_read_input_tokens با نرخ خواندن کش مدل ارائه شده است که بسته به مدل، بین 2.5٪ تا 10٪ نرخ ورودی استاندارد است. نسبت بالای خواندن به ایجاد، وضعیت مطلوبی است. اگر نرخ ایجاد در نوبت‌های متوالی بالا باقی بماند، چیزی در پیشوند شما مدام در حال تغییر است.

آیا پنجره کانتکست بزرگ‌تر این مشکل را حل می‌کند؟

تا حدی. تمام مدل‌های فعلی (Fable 5.1، Opus 5.5، Sonnet 5.5 و Haiku 5.5) از پنجره کانتکست 1 میلیون توکنی استفاده می‌کنند و فشرده‌سازی در محدوده‌های بزرگ‌تر نیز به همان شیوه عمل می‌کند. صرفه اقتصادی تغییر نمی‌کند، زیرا کل پرامپت در هر نوبت دوباره ارسال شده و هزینه آن محاسبه می‌شود. پنجره بزرگ‌تر فقط تعیین می‌کند که چه زمانی مجبور به اقدام هستید؛ اما رعایت بهداشت داده‌ها (hygiene) تعیین‌کننده هزینه است. اگر مشکل صورت‌حساب است و نه سقف محدودیت، کدام طرح Claude با نحوه کار شما متناسب است مشخص می‌کند که آیا در حال پرداخت هزینه دلاری هستید یا از سهمیه طرح خود استفاده می‌کنید.

ویرایش کانتکست و فشرده‌سازی در API دو مقوله متفاوت هستند

اگر در حال ساخت ایجنت خود بر روی Messages API هستید، هیچ دستور اسلش (slash command) وجود ندارد و باید خودتان آن را پیاده‌سازی کنید. از همان ابتدا برای آن کار بودجه در نظر بگیرید، زیرا کمک‌هزینه‌های رایگان API هزینه توکن‌های شما را پرداخت نمی‌کنند. کاربران جدید مقدار کمی اعتبار رایگان برای تست API دریافت می‌کنند و کمک‌هزینه ثابتی که Anthropic فهرست کرده است (50 ساعت رایگان در روز برای هر سازمان در صفحه قیمت‌گذاری، 1550 ساعت در ماه در مستندات) زمان کانتینر اجرای کد را پوشش می‌دهد که جدا از توکن‌ها محاسبه می‌شود. هر نوبت، تاریخچه کوتاه نشده را دوباره ارسال می‌کند و هزینه تمام آن را دریافت می‌کند: با نرخ خواندن کش زمانی که پیشوند کش شده است، و با نرخ ورودی کامل یا حق بیمه نوشتن در کش زمانی که کش نشده است. اینکه از کدام ارائه‌دهنده استفاده می‌کنید، این محاسبات را پیش از هرگونه کوتاه کردن تعیین می‌کند، بنابراین اگر انتخاب هنوز باز است، هزینه همان حجم کاری را در هر دو API محاسبه کنید و به نرخ‌های اسمی هر توکن اکتفا نکنید. دو ویژگی سمت سرور این کار را انجام می‌دهند و یکسان نیستند.

ویرایش کانتکست (Context editing) به صورت انتخابی محتوای خاصی را از تاریخچه گفتگو با رشد آن پاک می‌کند و هر نتیجه پاک‌شده را با متن جای‌گیر (placeholder) عوض می‌کند تا Claude بداند چیزی حذف شده است. این یک نسخه بتا است: anthropic-beta: context-management-2025-06-27 را ارسال کنید و استراتژی‌ها را تحت context_management.edits پیکربندی کنید. clear_tool_uses_20250919 نتایج ابزار را پاک می‌کند و clear_thinking_20251015 بلوک‌های تفکر را مدیریت می‌کند. مقدار پیش‌فرض trigger آن 100,000 توکن ورودی، keep آخرین 3 استفاده از ابزار، و clear_tool_inputs برابر با false است، بنابراین ورودی‌ها باقی می‌مانند و فقط نتایج حذف می‌شوند.

فشرده‌سازی (Compaction) یک خلاصه تولید کرده و کل تاریخچه گفتگو را با آن جایگزین می‌کند. این ویژگی در دو نسخه بتا ارائه می‌شود. فشرده‌سازی آستانه‌ای (Threshold compaction) در داخل درخواست‌های عادی شما اجرا می‌شود: anthropic-beta: compact-2026-01-12 را ارسال کنید و از نوع ویرایش compact_20260112 استفاده کنید. محرک آن به‌طور پیش‌فرض {"type": "input_tokens", "value": 150000} است و مقدار آن باید حداقل 50,000 باشد. فشرده‌سازی درخواستی (On-demand compaction) به کد شما اجازه می‌دهد تصمیم بگیرد چه زمانی این کار انجام شود: anthropic-beta: compact-2026-09-04 را با یک "compaction": {"type": "summarize"} سطح بالا ارسال کنید و پاسخ فقط شامل بلوک خلاصه است. مستندات فشرده‌سازی Anthropic توصیه می‌کند هر جا که ممکن است از فشرده‌سازی درخواستی استفاده کنید.

فشرده‌سازی آستانه‌ای یک قانون انتقال دارد که ایجنت‌ها را بی‌سروصدا مختل می‌کند. پاسخ با یک بلوک محتوای compaction حاوی خلاصه شروع می‌شود و به دنبال آن بلوک متن عادی می‌آید. شما باید آن بلوک را در درخواست‌های بعدی بازگردانید و API سپس تمام بلوک‌های محتوای قبل از آن را حذف می‌کند. در عمل: کل response.content را ضمیمه کنید، نه فقط متن را. فشرده‌سازی درخواستی برعکس عمل می‌کند: شما پیام‌های خلاصه‌شده را خودتان حذف می‌کنید، بلوک بازگردانده شده را در ابتدای messages قرار می‌دهید و آن را دقیقاً همان‌طور که بازگردانده شده، شامل امضا، ارسال می‌کنید.

مستندات Anthropic فشرده‌سازی سمت سرور را استراتژی اصلی برای مدیریت کانتکست در گفتگوهای طولانی‌مدت و ویرایش کانتکست را گزینه‌ای برای کنترل دقیق‌تر بر آنچه پاک می‌شود، می‌نامد. ابتدا پشتیبانی مدل را بررسی کنید. تمام مدل‌های فعلی از هر دو نوع فشرده‌سازی پشتیبانی می‌کنند، از جمله Haiku 5.5؛ مدل قدیمی claude-haiku-4-5 این‌طور نیست و هر صفحه فشرده‌سازی فهرست زنده خود را دارد. هیچ‌کدام از این نسخه‌های بتا، /compact اختصاصی Claude Code را هدایت نمی‌کنند، که مستندات آن را به عنوان یک درخواست خلاصه‌سازی جداگانه که کلاینت با تاریخچه شما ارسال می‌کند، توصیف کرده است.

FAQ

چرا با طولانی‌تر شدن نشست Claude Code، سرعت آن کاهش یافته و هزینه‌اش بیشتر می‌شود؟

زیرا در هر نوبت، کل مکالمه مجدداً ارسال می‌شود؛ بنابراین یک پرسش تک‌خطی در نشستی که تمام روز باز بوده، کل تاریخچه آن روز را به همراه دارد. قابلیت Prompt caching باعث می‌شود تا زمانی که حافظه کش (cache) فعال است، هزینه پایین بماند: هزینه خواندن در مدل Haiku 5.5 برابر 0.1x نرخ ورودی پایه، در مدل‌های Opus 5.5 و Sonnet 5.5 برابر 0.05x و در مدل Fable 5.1 برابر 0.025x است. هنگامی که یک نوبت از کش استفاده نکند، همان پیشوند با نرخ 1.25x و در صورت گذشتن از عمر یک‌ساعته، با نرخ 2x محاسبه می‌شود. دستور /context را اجرا کنید تا ببینید چه چیزی پنجره زمینه (context window) را پر کرده است، و برای درک سازوکار آن، مواردی که Claude Code برای آن‌ها صورت‌حساب صادر می‌کند را مطالعه کنید.

تفاوت /clear و /compact در Claude Code چیست؟

دستور /clear یک مکالمه جدید با زمینه خالی آغاز می‌کند. این دستور هیچ درخواستی ارسال نمی‌کند، بنابراین هزینه‌ای ندارد و برای جابه‌جایی بین کارهای نامرتبط، گزینه مناسبی است. دستور /compact مکالمه فعلی را حفظ کرده و تاریخچه را با یک خلاصه جایگزین می‌کند؛ بنابراین برای یک کار طولانی، گزینه مناسبی است. برای آن یک تمرکز مشخص کنید، مانند /compact keep only the plan and the diff، زیرا دستورالعمل شما تعیین می‌کند چه چیزی باقی بماند.

چگونه بفهمم چه چیزی در حال پر کردن پنجره زمینه Claude Code من است؟

دستور /context یا برای مشاهده جزئیات کامل به تفکیک هر آیتم، دستور /context all را اجرا کنید. این دستورات، پرامپت سیستم، تعاریف ابزارها، سرورهای MCP، فایل‌های حافظه و تاریخچه را به صورت یک شبکه رنگی نمایش می‌دهند و پیشنهاداتی برای ابزارهای سنگین و فایل‌های حجیم حافظه ارائه می‌کنند. در طرح‌های پولی، دستور /usage همچنین استفاده اخیر را به مهارت‌ها، زیر-عامل‌ها (subagents) و سرورهای MCP اختصاصی نسبت می‌دهد.

آیا باید به‌جای فشرده‌سازی (compaction) از پنجره زمینه 1 میلیون توکنی استفاده کنم؟

پنجره بزرگ‌تر فقط مشکل را به تعویق می‌اندازد و آن را حل نمی‌کند. تمام مدل‌های فعلی (Fable 5.1، Opus 5.5، Sonnet 5.5 و Haiku 5.5) از پنجره زمینه 1 میلیون توکنی پشتیبانی می‌کنند و فشرده‌سازی در آن‌ها به همان شکل عمل می‌کند. در هر نوبت، کل پرامپت همچنان بازنشر شده و هزینه آن محاسبه می‌شود؛ بنابراین یک مکالمه 400,000 توکنی، فارغ از اینکه در پنجره جا شود یا نه، گران‌قیمت است.

تفاوت ویرایش زمینه (context editing) و فشرده‌سازی (compaction) در Claude API چیست؟

ویرایش زمینه به‌صورت انتخابی محتوای قدیمی، عمدتاً نتایج ابزارها، را پاک می‌کند و متن جایگزینی در محل آن‌ها قرار می‌دهد تا Claude بداند که حذف شده‌اند. فشرده‌سازی یک خلاصه تولید کرده و کل تاریخچه را با آن جایگزین می‌کند. مستندات Anthropic، فشرده‌سازی را استراتژی اصلی برای مکالمات طولانی‌مدت می‌داند و ویرایش زمینه را به عنوان گزینه‌ای با دقت بالا (fine-grained) معرفی می‌کند. هر دو در مرحله بتا هستند، هدرهای خاص خود را دارند و هر دو از دستور /compact در Claude Code مجزا هستند.