سلام رفقا!
اگر از ابزارهای کدنویسی هوشمند (Code Agents) مثل Claude Code یا OpenCode استفاده میکنید، احتمالاً این حس را داشتهاید که «چرا قبل از اینکه حتی یک کلمه از دستورم بفرستم، انگار کلی توکن مصرف میشه؟»
خبر/گزارش اخیر Systima یک نمونهی عددی خیلی واضح داده: در Claude Code ممکن است قبل از اینکه اولین Prompt واقعی شما ارسال/پردازش شود، یک سربار آمادهسازی (Initialization/Pre-run) در حد ~۳۳ هزار توکن رخ دهد. همان سناریو در OpenCode حدود ~۷ هزار توکن گزارش شده است؛ و اگر از instruction fileها، MCP و زنجیرهی ابزارها/ساباِیجنتها استفاده کنید، این عدد حتی میتواند به ~۷۵ هزار توکن هم برسد.
در این پست میخواهیم دقیقتر ببینیم:
- این سربار توکنی معمولاً چه چیزهایی است؟
- چرا روی هزینه و latency اثر میگذارد؟
- با چه رویکردهایی میشود هزینه را کم کرد (بدون اینکه کیفیت کار نابود شود)؟
1) «قبل از اولین دستور» یعنی چه؟
وقتی میگوییم «۳۳ هزار توکن قبل از اولین دستور»، معمولاً منظور این است که سیستم شما (Agent/Orchestrator) قبل از اینکه پیام کاربر را به عنوان «کار اصلی» ارسال کند، چند مرحلهی مهندسی/هماهنگی انجام میدهد؛ مثل:
- ساخت پیام اولیهی سیستم (System/Developer prompts): قالببندی دقیق قوانین، style، محدودیتها و…
- جمعآوری و تزریق context: فایلهای instruction، دستورالعملهای پروژه، راهنمای ابزارها، چکلیستهای مجوز/سیاستها
- نمایش/ثبت ابزارها (Tool schemas): خیلی از agentها لیست ابزارها + فرم پارامترها را در پیام میچسبانند
- ساخت حافظه یا نقشهی پروژه: بعضی فریمورکها بخشی از فایلها را برای «آشنایی اولیه» خلاصه/استخراج میکنند
- راهاندازی MCP / اتصال به external tools: حتی اگر شما چیزی نخواستید، orchestrator ممکن است در آغاز Handshake یا آمادهسازی انجام دهد
نتیجه: بخشی از این محتوا به شکل tokenها وارد مدل میشود، حتی پیش از اینکه شما اولین «دستور واقعی» را ارسال کرده باشید.
2) چرا این سربار مهم است؟ (Cost × Latency)
این صرفاً یک عدد عجیب نیست—دو اثر عملی دارد:
الف) هزینهی مستقیم
در سرویسهایی که هزینه را بر اساس تعداد توکن محاسبه میکنند، initialization heavy یعنی:
- برای هر session، یک «کف هزینه» دارید.
- اگر جلسات زیاد و کوتاه دارید (مثلاً هر بار ۱-۲ تغییر)، نسبت هزینه به خروجی بد میشود.
ب) تأخیر (Latency)
حتی اگر هزینه خیلی بد نباشد، حجم پیام اولیه بزرگ است:
- زمان آمادهسازی بالا میرود (read/merge/tool schemas)
- زمان پردازش مدل برای prompt بزرگتر میشود
- ممکن است به صف/محدودیتهای rate هم برخورد کنید
ج) اثر زنجیرهای در agentهای چندمرحلهای
اگر agentها از sub-agent ها یا ابزارهای چندمرحلهای استفاده کنند، هرکدام ممکن است initialization مشابهی داشته باشند. یعنی یک بار “شروع سنگین” میتواند چندبار تکرار شود.
3) چه چیزهایی معمولاً سربار توکنی را زیاد میکند؟
اگر با سیستمهای مبتنی بر instruction file / MCP کار کنید، معمولاً این عوامل بیشترین سهم را دارند:
- زیاد بودن حجم instruction/Policyها
- فایلهای راهنما یا قوانین متعدد
- Tooling metadata زیاد
- schema طولانی ابزارها
- context جمعآوری گسترده در شروع
- چند فایل بزرگ که فقط برای «شروع» لازماند
- چند بار رخ دادن initialization
- restart داخل همان session
- یا فراخوانی زیر-عاملها که هرکدام prompt خودشان را دارند
4) راهکارهای عملی برای کاهش هزینه (بدون از دست دادن کیفیت)
در این قسمت، چند تکنیک «قابل اجرا» میدهم که در عمل بیشترین اثر را دارند.
راهکار 1: instructionها را کوچک و ماژولار کنید
- قوانین و استانداردها را ماژولار نگه دارید.
- برای شروع، فقط «حداقل لازم» را تزریق کنید.
- چیزهایی مثل چکلیستهای طولانی را به صورت «در صورت نیاز» فعال کنید.
مثال رویکرد:
- Session start: فقط قوانین کلیدی (۵-۱۰ خط)
- مرحلهی اجرای واقعی: قوانین تخصصی مرتبط با آن task
راهکار 2: MCP/tool schema را محدود کنید
اگر ابزارهای زیادی دارید:
- در شروع، فقط ابزارهای لازم برای آن task را expose کنید.
- از toolهای غیرضروری در init جلوگیری کنید.
راهکار 3: context اولیه را “اقتصادی” کنید
- به جای تزریق مستقیم چند فایل بزرگ، از خلاصههای از پیش آمادهشده استفاده کنید.
- اگر فریمورک اجازه میدهد، فایلها را بر اساس relevance انتخاب کنید.
راهکار 4: از sessionهای کوتاه زیاد جلوگیری کنید (اگر امکانش هست)
اگر هر بار برای یک تغییر کوچک session جدید باز میکنید، با initialization heavy، هزینه میترکد.
- در پروژههای واقعی، بهتر است چند task مرتبط را در یک session انجام دهید.
- یا یک Orchestrator لایه داشته باشید که initialization را reuse کند.
راهکار 5: کنترل کنید sub-agentها “cold start” نخورند
- بررسی کنید هر sub-agent دوباره prompt کامل را میسازد یا از حافظه/زمینهی مشترک استفاده میکند.
- اگر میشود، sub-agentها را با context مشترک راهاندازی کنید.
5) چکلیست سریع برای تیمها
قبل از اینکه هزینه ماهانه بالا برود، این موارد را اندازهگیری کنید:
- میانگین توکن initialization در هر session
- نسبت initialization به tokenهای “task واقعی”
- تعداد sessionهای کوتاه در روز/هفته
- تعداد ابزارهای فعال در ابتدای session
اگر این چهار مورد را داشته باشید، میتوانید تصمیم بگیرید:
- کجا prompt را کوچک کنیم
- کجا session reuse کنیم
- کدام agent pipeline را تغییر دهیم
6) جمعبندی
عدد ~۳۳k توکن در Claude Code (طبق گزارش Systima) احتمالاً نشان میدهد orchestrator این ابزار در ابتدای کار، مقدار قابل توجهی از metadata/context/tooling را وارد prompt میکند—حتی قبل از اینکه شما دستور اصلی را بدهید.
درس مهم این است:
- سربار initialization میتواند هزینه و latency را به صورت نمایی بدتر کند
- بهترین راهحل همیشه “کم کردن کیفیت” نیست؛ معمولاً با ماژولار کردن instructionها، محدود کردن toolها، اقتصاد در context و جلوگیری از cold starts میشود آن را کاهش داد.
منابع (برای مطالعه بیشتر)
- گزارش Systima درباره Claude Code
- بحثهای فنی در مورد Code Agents و MCP/tool schemas
اگر دوست دارید، در پست بعدی میتونم یک قالب عملی (Template) برای “Instruction file سبک” و یک روش اندازهگیری token budget برای sessionها هم پیشنهاد بدم.