چگونه Statnive را با Claude Code بدون سوزاندن توکن عرضه می‌کنیم

اولین باری که `/context` را اجرا کردیم، 12% باقی داشتیم

Statnive یک تیم کوچک است که یک plugin تحلیلی حریم‌خصوصی‌محور WordPress عرضه می‌کند. codebase ما دو git submodule دارد (plugin و سایت بازاریابی)، 80+ مهارت Claude Code، 24 connector MCP و یک گیت release که قبل از عرضه هر چیزی 141 آزمون و 31 بررسی انطباق را اجرا می‌کند.

برای دو ماه اول، توسعه با کمک AI جادویی به نظر می‌رسید. سپس شروع به احساس گران شدن کرد. نشست‌ها در میانه وظیفه timeout می‌شدند. به نظر می‌رسید مدل چیزهایی را که پنج دقیقه قبل خوانده بود فراموش می‌کرد. صورت‌حساب Anthropic ما برای یک مهندس از $6 در روز فراتر رفت.

ما برای اولین بار /context را اجرا کردیم و دلیل را فهمیدیم. قبل از اینکه یک prompt تایپ کنیم، از قبل 88% پنجره context را استفاده می‌کردیم. دوازده درصد برای کار واقعی باقی مانده بود.

این پست این است که چگونه آن سربار را تقریباً دو-سوم کاهش دادیم — بدون از دست دادن هیچ مهارت یا connector — و چهار عددی که اکنون هر عرضه را گیت می‌کنند.

اعداد سرتیتر: حدود 54 هزار توکن سربار baseline (پایین آمده از حدود 175 هزار)، حدود 73% پنجره context برای کار واقعی در دسترس، و خرج روزانه از حدود $6 به حدود $2 تا 3 کاهش یافت.

چه چیزی واقعاً در آن 200 هزار توکن زندگی می‌کند

Claude Code یک پنجره context 200 هزار توکنی به شما می‌دهد. این تا زمانی که بفهمید قبل از اولین پیام شما چه چیزی آن را می‌خورد سخاوتمندانه به نظر می‌رسد.

مؤلفه	چیست	بهینه نشده	هدف ما
System prompt	دستورات داخلی Claude Code	حدود 3,200	حدود 3,200
ابزارهای داخلی	Read، Write، Bash، Grep، Glob، Edit	حدود 11,600	حدود 11,600
CLAUDE.md ریشه	دستورات پروژه، همیشه بارگذاری شده	8,000+	حداکثر 1,500
metadata مهارت	ورودی‌های `<available_skills>`	4,000+	حداکثر 2,500
schemaهای ابزار MCP	24 connector × ابزارهای زیاد	48,000–120,000	حداکثر 3,000
بافر auto-compact	فضای رزرو شده	32,000	32,000

سه ردیف از این‌ها کل مبارزه است: CLAUDE.md همیشه-بارگذاری-شده، رجیستری metadata مهارت، و dump schema ابزار MCP. هر چیز دیگر توسط harness ثابت است.

مکانیزم زیربنایی افشای تدریجی است. سیستم مهارت Claude Code فقط فیلدهای name و description هر مهارت را در راه‌اندازی بارگذاری می‌کند — حدود 30 تا 50 توکن به ازای هر مهارت — و بدنه کامل SKILL.md را تا زمانی که مهارت واقعاً فراخوانی شود موکول می‌کند. همان ترفند برای schemaهای ابزار MCP و مستندات مرجع کار می‌کند، اگر آن را پیکربندی کنید. اگر نکنید، هر تعریف ابزار، هر قاعده، هر دستور تا ابد در context می‌نشیند.

سربار ابزار MCP بزرگ‌ترین نشت ما بود

اجرای /context برای اولین بار یک تجربه فروتن کننده است. اینجا آنچه قبل از لمس هر چیزی دیدیم:

connector MCP	ابزار	توکن مصرف شده
GitHub	35	حدود 26,000
Playwright (browser automation)	21	حدود 13,647
Slack	11	حدود 21,000
Context7 (library docs)	حدود 15	حدود 8,000
سایر 20 connector	حدود 200	حدود 60,000+

این پنج ردیف به‌تنهایی حدود 60% پنجره context را قبل از باز کردن یک فایل مصرف کردند. مشکل معماری است: هر schema ابزار MCP — نام، توضیح، تعاریف کامل JSON پارامتر — به‌طور پیش‌فرض در شروع نشست به context تزریق می‌شود. سرور MCP Docker با 135 ابزار و حدود 126,000 توکن به‌تنهایی عرضه می‌شود.

راه‌حلی که برای ما 85% کار را انجام داد روشن کردن MCP Tool Search بود. عرضه شده در Claude Code v2.1.7، Tool Search یک شاخص سبک حدود 5 هزار توکنی از نام و توضیحات ابزار می‌سازد و schema کامل برای یک ابزار را فقط زمانی بارگذاری می‌کند که Claude واقعاً آن را فراخوانی کند. آزمون داخلی Anthropic کاهش از 134 هزار به حدود 5 هزار توکن — یک کاهش 85% را نشان داد — در حالی که دقت در ارزیابی‌های MCP بالا رفت (Opus 4: 49% به 74%).

فعال‌سازی به‌طور خودکار زمانی اتفاق می‌افتد که توضیحات ابزار از حدود 10% پنجره context فراتر می‌روند، اما ما از طریق /context راستی‌آزمایی می‌کنیم در هر نشست فعال است و خط «tool search enabled» را تماشا می‌کنیم.

ما درباره اعداد قبل/بعد و سه connector که eager-loaded نگه داشتیم در یک پست اختصاصی روی MCP Tool Search بیشتر نوشتیم.

CLAUDE.md: 162 خط، نه 800

برخلاف مهارت‌ها و ابزارهای MCP، هر بایت از CLAUDE.md در شروع هر نشست بدون بارگذاری lazy وارد context می‌شود. این شامل فایل ریشه، هر import از طریق نحو @path/to/file (بازگشتی تا 5 سطح) و همه فایل‌های سراسری و enterprise است.

اولین CLAUDE.md ما 820 خط بود. هر مهارت، هر workflow، هر استاندارد کدنویسی، هر گیت release، هر تفاوت پیکربندی استانداردهای کدنویسی WordPress ما را مستند می‌کرد. کامل بود. همچنین در هر نشست منفرد حدود 12% پنجره context را مصرف می‌کرد، از جمله نشست‌هایی که هیچ ربطی به بیشتر آنچه توصیف می‌کرد نداشتند.

ما آن را به 162 خط کاهش دادیم با خارج کردن پروتکل‌ها و جایگزین کردن آن‌ها با یک جدول راه‌انداز — یک الگوی جستجوی مهارت فشرده که جایگزین متن مهارت‌به‌مهارت verbose می‌شود:

## Skill triggers
| Trigger keywords | Skill | Domain |
|------------------|-------|--------|
| sprint, backlog, iteration | pm-sprint-plan | PM |
| deploy, release, ship | statnive-release | Dev |
| security, audit | sec-audit-remediate | Security |

این الگو حدود 800 توکن به جای 3,000+ برای مستندات verbose هزینه دارد. پروتکل‌های دقیق در فایل‌های منفرد SKILL.md زندگی می‌کنند، فقط زمانی بارگذاری می‌شوند که Claude به آن‌ها مسیریابی کند. قواعد path-scoped زیر .claude/rules/ محدودیت‌های خاص دامنه (قراردادهای React، استانداردهای کدنویسی PHP، قواعد گیت release) را فقط زمانی که Claude با فایل‌های منطبق کار می‌کند برمی‌دارند.

قبل/بعد کامل در پست بازطراحی CLAUDE.md ما مستند است، اما بزرگ‌ترین ضد الگوی منفردی که حذف کردیم @-import کردن فایل‌های مرجع بزرگ به CLAUDE.md ریشه بود. هر @import فایل کامل هدف را در هر نشست بارگذاری می‌کند — ما سه عدد داشتیم که حدود 6,000 توکن سربار دائمی برای محتوایی که مدل به‌ندرت نیاز داشت اضافه می‌کرد.

tier کردن مهارت: چهار سطل، یک قاعده

ما بیش از 80 مهارت داریم که مدیریت محصول، scaffolding بک‌اند، QA، ممیزی امنیتی، الگوهای خاص WordPress، بسته‌بندی release و موارد بیشتر را پوشش می‌دهند. به‌طور ساده بارگذاری شده، 80 مهارت × حدود 50 توکن metadata هر کدام، 4,000 توکن سربار دائمی است. رشد به 141 مهارت (مثل framework jaan.to که روی آن می‌سازیم) می‌تواند آن را از 14,000 فراتر ببرد.

راه‌حل مدل tier کردن چهار سطلی تعریف شده توسط سیستم مهارت Claude Code است:

سطل	Frontmatter	هزینه metadata	چه زمانی استفاده شود
Always-on	(پیش‌فرض)	حدود 40 توکن	workflowهای اصلی که مدل باید به‌طور خودکار به آن‌ها مسیریابی کند
Auto-invocable	(پیش‌فرض، توضیح فشرده)	حدود 40 توکن	مهارت‌های دامنه با کلمات کلیدی راه‌انداز قوی
Manual-only	`disable-model-invocation: true`	0 توکن	مهارت‌های فقط slash-command — نادر یا مخرب
Fork / subagent	`context: fork`	حدود 40 توکن	بازبینی، ممیزی، تحلیل چندمرحله‌ای که نباید context اصلی را آلوده کند

آزمون یک سؤال: آیا مکالمه اصلی نیاز به دیدن خروجی دارد؟ اگر نه — اگر مهارت خودکفا است و خلاصه برمی‌گرداند — یک کاندیدای fork/subagent است و استفاده توکن داخلی آن از context اصلی ناپدید می‌شود. Anthropic مستند می‌کند subagentها حدود 500 تا 1,000 توکن از 10,000+ کار داخلی برمی‌گردانند — تقریباً یک کاهش 37% در context اصلی روی وظایف پیچیده.

ما تقریباً نیمی از مهارت‌های خود را به‌عنوان disable-model-invocation: true علامت می‌زنیم — آن‌ها فقط از طریق slash command قابل دسترس هستند. این به‌تنهایی حدود 2,000 توکن metadata baseline را صرفه‌جویی کرد، و در واقع کیفیت مسیریابی برای مهارت‌های auto-invocable باقی‌مانده را بهبود بخشید زیرا Claude بین تقریباً تکراری‌ها انتخاب نمی‌کرد.

تجزیه کامل سطل‌به‌سطل — از جمله نحوه دسته‌بندی کتابخانه مهارت واقعی Statnive — در پست tier کردن مهارت است.

ایزولاسیون subagent برای کار سنگین

سه دسته از کار دیگر هرگز context اصلی ما را لمس نمی‌کنند: بازبینی کد، ممیزی امنیتی و تحقیق اکتشافی. آن‌ها در subagent اجرا می‌شوند — نمونه‌های جداگانه Claude با پنجره context 200 هزار توکنی خودشان — و یک پیام خلاصه برمی‌گردانند.

اقتصاد ظریف است. نشست‌های subagent در مجموع توکن بیشتری از کار inline مصرف می‌کنند: Anthropic مستند می‌کند تیم‌های agent تقریباً 7 برابر توکن کلی بیشتری استفاده می‌کنند زیرا هر agent یک نمونه Claude جدید با بارگذاری system-prompt و سربار راه‌اندازی ابزار خودش راه‌اندازی می‌کند.

اما کل خرج توکن چیزی نیست که برای آن بهینه می‌کنیم. ما بهینه می‌کنیم برای:

پاکی context اصلی. یک ممیزی امنیتی که 40 فایل می‌خواند و 3 مسئله می‌یابد یک خلاصه 600 توکنی برمی‌گرداند. بدون ایزولاسیون، حلقه read کامل 40 هزار توکن از context اصلی را می‌خورد، و ما را به‌سمت ناحیه «گم شده در میانه» می‌کشاند که در آن کیفیت بازیابی 15 تا 47% تنزل می‌یابد.
مسیریابی مدل. subagentها می‌توانند روی Haiku 4.5 ($1/$5 به ازای MTok) اجرا شوند در حالی که نشست اصلی از Sonnet یا Opus استفاده می‌کند. اکتشاف فقط-خواندنی به مدل برتر نیاز ندارد — مزیت هزینه 3 برابری Haiku روی ممیزی‌هایی که صدها فایل می‌خوانند سریع جمع می‌شود.

یک روز عرضه عادی الان به چه شکل است

در یک روز عرضه معمولی Statnive، ما حدود 400 هزار تا 600 هزار توکن از کار واقعی می‌سوزانیم. اینجا جایی است که می‌روند:

کار	مدل	الگو
بازبینی کد صبحگاهی روی یک PR باز	Sonnet (اصلی) + Haiku (subagent fork)	بازبینی را fork کن، خلاصه را برگردان
نوشتن یک ویژگی جدید در داشبورد React	Sonnet (اصلی)	مهارت auto-invocable `frontend-scaffold`، مراجع on demand بارگذاری می‌شوند
اجرای گیت release	Sonnet (اصلی)	مهارت `statnive-release`، bash-driven — بدون context اضافه
نوشتن یکی از این پست‌های وبلاگ	Sonnet (اصلی)	پیش‌نویس inline، یک پاس بازبینی fork کن

prompt caching بقیه را مدیریت می‌کند. Claude Code prefix پایدار را cache می‌کند — system prompt، تعاریف ابزار، metadata مهارت، CLAUDE.md ریشه — که در هر نوبت تکرار می‌شود. خواندن‌های cache 0.1 برابر قیمت پایه هزینه دارند، که حدود 90% کاهش هزینه روی آن prefix پایدار ارائه می‌دهد. مرتب کردن محتوای static-first و dynamic-last cache hits را به حداکثر می‌رساند، بنابراین CLAUDE.md ریشه را بالای هر context پویا تزریق شده نگه می‌داریم.

آنچه بهینه نکردیم

شفافیت درباره محدودیت‌ها، نه فقط قابلیت‌ها:

به context پویای heavy hook-driven منتقل نشدیم. تحقیق نشان می‌دهد hookهای SessionStart می‌توانند context پویا تزریق کنند (شاخه فعلی، فایل‌های تغییر یافته، سرویس‌های در حال اجرا) تا جایگزین محتوای CLAUDE.md ایستا شوند — مطالعات موردی جامعه کاهش بیشتر حدود 62% را نشان می‌دهند. ما آن را امتحان کردیم، برگرداندیم. ریسک exit code 2 که متن خطا را در context جمع کند ما را ترساند. پس از بلوغ تشخیص hook Claude Code دوباره بررسی خواهیم کرد.
ما هنوز برای برخی وظایف معماری از Opus استفاده می‌کنیم. تحقیق می‌گوید برای 80% کار به Sonnet پیش‌فرض دهید و Opus را برای استدلال پیچیده ذخیره کنید. ما این کار را برای ویژگی‌ها انجام می‌دهیم، اما برای release بیش از حد روی Opus سرمایه‌گذاری می‌کنیم زیرا هزینه یک release شکست خورده از صورت‌حساب حاشیه‌ای Anthropic بیشتر است.
هنوز گیت‌های CI برای بودجه‌های توکن نساخته‌ایم. کتاب بازی تحقیقاتی — شکست PR اگر CLAUDE.md ریشه از حدود 1,500 توکن، قواعد unscoped از 400 یا هر SKILL.md از 500 خط فراتر برود — از پسرفت جلوگیری می‌کند. در roadmap است. در حال حاضر با بررسی‌های دستی /context در هر نشست اعمال می‌کنیم.
اعداد ما خود-گزارش شده هستند. ما یک تیم کوچک هستیم. اعداد عمومی Anthropic (134 هزار به 5 هزار برای Tool Search، 37% برای ایزولاسیون subagent، 90% برای prompt caching) در اندازه‌گیری‌های ما برقرار است، اما ما یک benchmark دقیق به روشی که برای عملکرد plugin تحلیلی WordPress منتشر کردیم منتشر نکرده‌ایم.

اثر مرکب واقعی است

چهار بهینه‌سازی — prompt caching، مسیریابی مدل، ایزولاسیون subagent و موکول کردن ابزار MCP — ضربی هستند، نه جمعی. هر یک به‌تنهایی متوسط به نظر می‌رسد. روی هم انباشته، یک پنجره context 200K را از فشرده به راحت تبدیل می‌کنند، و یک عادت $6 در روز را به یک ابزار حدود $2 تا 3 در روز تبدیل می‌کنند. راهنمای کامل حسابداری هزینه در پست اقتصاد است.

این برای کاربران Statnive چه معنایی دارد: همان تیمی که یک plugin تحلیلی حریم‌خصوصی‌محور را عرضه می‌کند می‌تواند در دامنه یک تیم بسیار بزرگ‌تر کار کند، بدون مبادله روی پوشش آزمون یا سختگیری انطباق. هر release همچنان از همان 141 آزمون و 31 بررسی انطباق عبور می‌کند. workflow AI ساختار است، نه میان‌بر.

چرا این را منتشر کردیم

ما پست‌هایی مثل چگونه سریع‌ترین tracker WordPress را ساختیم و چگونه Statnive را آزمون می‌کنیم می‌نویسیم زیرا فکر می‌کنیم اکوسیستم WordPress سزاوار روایت‌های مهندسی صادقانه‌تر است. همان برای توسعه با کمک AI اعمال می‌شود: محتوای زیادی ادعا می‌کند Claude Code تیم شما را متحول خواهد کرد، تقریباً هیچ‌کدام حسابداری توکن را نشان نمی‌دهد.

اگر یک تیم plugin WordPress، یا هر تیم مهندسی کوچک هستید که Claude Code را در مقیاس اجرا می‌کند: امروز /context را اجرا کنید. ببینید چه چیزی پنجره شما را می‌خورد. چهار عددی که اکنون هر یک از release های ما را گیت می‌کنند، سربار baseline زیر 30%، CLAUDE.md ریشه زیر 1,500 توکن، MCP Tool Search تأیید شده فعال، و صفر @-import در پیکربندی ریشه است. این‌ها در یک عصر قابل دستیابی هستند.

Statnive را امتحان کنید

plugin تحلیلی حریم‌خصوصی‌محور WordPress ساخته شده با این workflow رایگان روی WordPress.org است. منبع کامل روی GitHub — از جمله CLAUDE.md ما، مهارت گیت release ما و مجموعه آزمون کامل. داده‌های شما روی سرور شما باقی می‌ماند. ما روی سرور خودمان.