تصور کنید بودجه‌ی هوش مصنوعی شما ناگهان جهش می‌کند، اما ابزارهای رسمی فقط یک عدد کلی به شما می‌دهند و نمی‌گویند کدام ابزار باعث این هزینه شده است. اگر می‌خواهید بدانید دقیقاً کدام قابلیت در پروژه شما «پول‌سوز» است، باید نگاهی به لایه‌های پنهان داده‌ها بیندازید.
به گزارش منابع توسعه‌دهندگان، دستور /usage در Claude Code صرفاً یک جعبه سیاه است که هزینه را گزارش می‌کند اما ابزارهای محرک آن را مخفی می‌دارد. این دستور نرخ مصرف را در بازه‌های ۵ ساعته یا ۷ روزه در کنار تعداد توکن‌های هر جلسه گزارش می‌دهد، اما نمی‌تواند به سؤال ساده‌ای مثل «کدام مهارت (Skill) بیشترین توکن را در این هفته مصرف کرده است؟» پاسخ دهد. حالا یک اسکریپت پایتونی می‌تواند دقیقاً جایگاه هر توکن در بودجه شما را مشخص کند.
در ۲۳ ژوئیه ۲۰۲۴، توسعه‌دهنده‌ای به نام لی (Lily) روشی را برای افشای این هزینه‌ها از طریق تحلیل مستقیم فایل‌های transcript.jsonl در مسیر ~/.claude/projects/ معرفی کرد. این رویکرد، تمرکز را از «میزان کل توکن‌های مصرف‌شده» به «تجزیه مصرف به تفکیک هر آیتم» از رفتار عامل (Agent) تغییر می‌دهد. با خواندن مستقیم رکوردهای JSONL، کاربران می‌توانند میزان مصرف را در لایه‌ای مشاهده کنند که دستور /usage هرگز آن را فاش نمی‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم، شفافیت در لایه‌ی ابزارها تنها راه کاهش هزینه‌های عملیاتی در مقیاس بزرگ است. از سوی دیگر، مدیریت این حجم از داده‌های ترنسکریپت چالش‌های خاص خود را دارد؛ چنان‌که برخی تحلیل‌ها نشان می‌دهند دسترسی بیش از حد به متن جلسات پیشین می‌تواند عملکرد عامل‌های کدنویسی را تخریب کند.
فرض کنید در حال مدیریت یک محیط پیچیده هوش مصنوعی هستید و با جهشی در هزینه‌ها مواجه می‌شوید. ابزار استاندارد به شما می‌گوید که این هفته ۱۰ دلار بیشتر هزینه کرده‌اید، اما نمی‌تواند بگوید آیا یک «مهارت» (Skill) آزمایشی خاص دچار حلقه تکرار (Looping) شده است، یا اینکه عامل-همه-منظوره (General-purpose Agent) نیمی از تمام فراخوانی‌های عامل‌ها را به خود اختصاص داده، و یا اینکه یک سرور MCP خاص بیش از حد فراخوانی می‌شود. با خواندن رکوردهای JSONL، شما بالاخره می‌توانید لیست دقیقی از موارد مصرف توکن‌ها داشته باشید و ببینید «توکن‌ها دقیقاً صرف چه چیزی شده‌اند».
ساختار داده‌های ترنسکریپت
هر جلسه در Claude Code در مسیر ~/.claude/projects/ و در قالب JSONL ذخیره می‌شود؛ به این معنی که هر خط یک رکورد مجزا است. هر Turn (نوبت) ارسال شده یا دریافت‌شده به یک رکورد تبدیل می‌شود. طبق مستندات این روش، یک رکورد معمولی شامل موارد زیر است:
- شناسه مدل: برای مثال
claude-sonnet-4-6. - بلاک‌های ابزار: آرایه‌ای در
message.contentکه شامل بلاک‌های استفاده از ابزار (tool_use) با شناسه‌های منحصربه‌فرد است (مثلاًtoolu_01M5Rw...). - معیارهای مصرف: مقدار دقیق توکن (Token) در ورودی (مثلاً ۱۲,۰۴۳ توکن) و خروجی (مثلاً ۴۲۱ توکن) به ازای هر Turn.
- جزئیات ابزار: نام ابزار (مانند Read) و آرگومان‌های ورودی (مانند
file_path).
سازوکار فنی و منطق شمارش
قلب این راهکار، یک اسکریپت Bash به نام usage-breakdown.sh در مسیر ~/.claude/scripts/ است که یک کد پایتون را در قالب heredoc در دل خود جای داده است. Bash دایرکتوری و بازه زمانی (که به صورت پیش‌فرض روی 7d یا ۷ روز است) را دریافت می‌کند و سپس پایتون یک اسکن کامل روی فایل‌ها انجام می‌دهد.
اسکریپت به‌طور مشخص به دنبال بلاک‌هایی می‌گردد که در آرایه message.content دارای مقدار type == "tool_use" باشند. شمارش مصرف بر اساس مکانیزم‌های زیر انجام می‌شود:
- مهارت‌ها (Skills): داده‌ها از فیلد
input.skillاستخراج می‌شوند. اسکریپت همچنین متن را بر اساس کاراکتر:تجزیه می‌کند تا فضای نام (Namespace) را به‌طور جداگانه بشمارد (مثلاًhookify:configure). این کار به کاربران اجازه می‌دهد بفهمند کدام پکیج افزونه سنگین‌ترین مصرف را دارد. - عامل‌ها (Agents): از طریق فیلد
input.subagent_typeرصد می‌شوند. اگر این فیلد موجود نباشد، اسکریپت به صورت پیش‌فرض مقدار?را جایگزین می‌کند. - سرورهای MCP: با تجزیه فیلد
nameشناسایی می‌شوند. از آنجایی که ابزارهای MCP از فرمتmcp__<server>__<tool>پیروی می‌کنند، اسکریپت بخش دوم (اندیس [1]) را برمی‌دارد تا نام سرور را ایزوله کند و مشخص شود کدام سرور پروتکل زمینه مدل (MCP) فعال‌تر است.
تحلیل داده‌های واقعی
در یک تست عملی روی ۵۱ ترنسکریپت در بازه ۷ روزه، این اسکریپت ۴۲۳۰ فراخوانی ابزار (tool_use) را پردازش کرد. نتایج نشان‌دهنده وابستگی شدید به ابزارهای خاص بود:
- ابزارهای برتر: Bash با ۶۱٪ فراخوانی‌ها (۲۵۸۳ مورد) در صدر بود و پس از آن Read (۵۶۷ مورد)، Edit (۴۰۲ مورد) و Write (۱۵۱ مورد) قرار داشتند.
- اکوسیستم MCP: سرور
claude-in-chromeبا ۲۶۱ فراخوانی، به‌سراسر دیگران پیشی گرفت، در حالی که سرورclaude_ai_Google_Calendarتنها ۳ فراخوانی وclaude_ai_Gmailتنها ۲ فراخوانی داشت. - تیپ عامل‌ها: عامل
general-purposeبا ۲۰ مورد، رایج‌ترین نوع بود و پس از آن Explore (۷ مورد) و reviewer (۲ مورد) قرار داشتند. - مهارت‌ها و افزونه‌ها: تنها ۲ مهارت منحصربه‌فرد فراخوانی شده بود:
harness-auditوsuperpowers:brainstorming(که متعلق به فضای نامsuperpowersاست).
لی اشاره کرد که یک مورد خاص (Edge Case) در رابطه با مهارت‌های «AutoTrigger» وجود دارد. چون این مهارت‌ها به جای فراخوانی دستی، از طریق تطبیق کلمات کلیدی در فایل CLAUDE.md فعال می‌شوند، اغلب تعداد فراخوانی دستی کمتری نشان می‌دهند؛ اما چون همچنان به عنوان بلاک‌های tool_use در ترنسکریپت ظاهر می‌شوند، تعداد کم آن‌ها به‌دقت منعکس شده و ثبت می‌گردد.
علاوه بر این، ظهور نوع عامل ? نشان‌دهنده فراخوانی‌هایی است که subagent_type آن‌ها مشخص نشده است. لی پیشنهاد می‌کند وقتی تعداد این موارد افزایش می‌یابد، محدود کردن جست‌وجو به جلسات (Sessions) خاص می‌تواند برای کشف مشخصات گم‌شده‌ی subagentها مفید باشد.
چالش‌های پیاده‌سازی
این روش بدون نقص نیست و دارای چهار نقطه ضعف فنی است:
۱. دقت زمانی: فیلتر mtime در سطح فایل عمل می‌کند. اگر یک جلسه چندین روز طول بکشد، تمام Turnهای قدیمی آن فایل به عنوان بخشی از یک «فایل اخیر» محاسبه می‌شوند. برای دقت سخت‌گیرانه، نیاز به فیلترینگ در سطح خط از طریق rec.get("timestamp") است.
۲. عمق دایرکتوری: اسکریپت از glob.glob(f"{tr_dir}/*.jsonl") استفاده می‌کند و فقط یک سطح تخت را جست‌وجو می‌کند. این یعنی ترنسکریپت‌های زیرمجموعه که در مسیر <session-uuid>/subagents/agent-*.jsonl ذخیره شده‌اند را نادیده می‌گیرد. یک اسکن بازگشتی (Recursive) با **/*.jsonl این مشکل را حل می‌کند اما به دلیل مسائل مربوط به سرعت (Performance) حذف شده است.
۳. تداخل نام‌گذاری: استفاده از بخش دوم در تجزیه __ برای مواردی مثل mcp__claude-in-chrome__computer درست کار می‌کند، اما اگر نام خود سرور شامل __ باشد، استخراج نام دچار خطا می‌شود.
۴. عملکرد: اسکن یک پنجره ۳۰ روزه می‌تواند چندین دقیقه زمان ببرد چون باید بیش از ۸۹۰ فایل را به‌طور کامل اسکن کند. لی توصیه می‌کند برای مانیتورینگ روزانه از بازه 7d یا پرچم --short استفاده کنید.
یکپارچه‌سازی عملیاتی
برای کاربردی‌تر شدن این داده‌ها، لی پرچم --short را اضافه کرد. این پرچم گزارش مفصل را به یک خط خلاصه تبدیل می‌کند؛ مثلاً: 4235 tool_use across 51 sessions (7d).
با لوله‌کشی (Piping) این خروجی به یک خط وضعیت سفارشی در کنار یک اسکریپت مشاور بودجه توکن (token-budget-advisor.sh)، توسعه‌دهندگان می‌توانند سلامت بودجه خود را به‌صورت لحظه‌ای رصد کنند. یک نمونه از این هوک (Hook) به این شکل است:
BUDGET=$(~/.claude/scripts/token-budget-advisor.sh --short)USAGE=$(~/.claude/scripts/usage-breakdown.sh --short)echo "💰 $BUDGET | 🔧 $USAGE"
این ترکیب، رصد هزینه را با تحلیل رفتاری ادغام می‌کند تا به جای حدس و گمان، بر اساس شواهد سخت، محیط خود را بهینه کنید و دیدی با رزولوشن بالا از نحوه مصرف توکن‌ها به‌دست آورید.
گام بعدی شما
- فایل‌های
transcript.jsonlخود را در مسیر~/.claude/projects/بررسی کنید تا حجم داده‌های ذخیره‌شده را ببینید. - اگر از ابزارهای MCP استفاده می‌کنید، نام سرورهای فعال را با یک دستور
grepساده در این فایل‌ها جست‌وجو کنید. - اسکریپت‌های تحلیل مصرف را با ابزارهای مانیتورینگ سیستم خود (مانند zsh status line) ادغام کنید تا از شوک صورت‌حساب توکن‌ها جلوگیری کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو