هزینهٔ استنتاج Claude Code به دلیل کفِ توکنی ۳۳ هزارتایی افزایش یافت

اگر امروز از Claude Code برای کدنویسی استفاده می‌کنید، احتمالاً متوجه شده‌اید که صورت‌حساب API شما سریع‌تر از حد انتظار بالا می‌رود. شما با یک «کف توکنی» (Token Floor) مواجه هستید که پیش از پردازش حتی یک کلمه از درخواست شما، هزاران توکن را می‌بلعد.

طبق تحلیل فنی systima.ai در ۱۲ جولای ۲۰۲۶، یک پاسخ تک‌خطی در Claude Code منجر به مصرف ۳۳,۰۰۰ توکن اولیه می‌شود؛ یعنی تقریباً ۵ برابر بیشتر از رقیبش یعنی OpenCode که برای کارهای ساده تنها به ۷,۰۰۰ توکن نیاز دارد.

این اتفاق در حالی رخ می‌دهد که توسعه‌دهندگان در حال گذار از چت‌های ساده به سمت عامل‌های (Agents) — یا همان دستیارهای هوشمندی که مثل کارمندانی متخصص، خودکار کارهای پیچیده را انجام می‌دهند — پیش می‌روند. همان‌طور که در تحلیل قبلی ما درباره‌ی تلاش‌های Anthropic برای تعامل مستقیم Claude Code با صفحات وب اشاره کردیم، صنعت اکنون با هزینه‌های پنهان «داربست‌های عامل‌محور» (Agentic Scaffolding) دست‌وپنجه نرم می‌کند. این داربست‌ها در واقع دستورالعمل‌های نامرئی و تعریف ابزارهایی هستند که به هوش مصنوعی اجازه می‌دهند واقعاً یک کامپیوتر را کنترل کند. این پیچیدگی در ابزارها، یادآور گسترش سریع اکوسیستم‌های مشابه است، همان‌طور که تراکم ابزارهای فنی در پلتفرم‌هایی مانند Skillselion نشان می‌دهد که چگونه تعداد افزونه‌ی افزونه‌ها می‌تواند بر ساختار عامل‌ها اثر بگذارد.

چرا اندازه‌گیری مرزها اهمیت دارد؟

اضافه‌بار توکنی صرفاً یک نگرانی مالی نیست؛ بلکه مستقیماً بر هزینه، تأخیر (Latency) و فضای باقی‌مانده در پنجرهٔ زمینه (Context Window) — که شبیه میز کاری است که فقط جای چند ورق کاغذ دارد و نه کل کتابخانه — اثر می‌گذارد. هر توکن مصرف‌شده برای داربست، توکنی است از زمینهٔ کاری (Working Context) که نمی‌توان آن را برای کد واقعی استفاده کرد. از آنجا که این مقدار در هر نوبت گفتگو دوباره ارسال یا از کش خوانده می‌شود، هزینه‌ها به‌سرعت انباشته می‌شوند. این موضوع در محیط‌های سازمانی که از سرویس‌های ابری استفاده می‌کنند، بحرانی‌تر است؛ برای مثال هزینه‌های دسترسی به مدل‌های Claude در AWS Bedrock پیش از این نشان داده بود که مقیاس سازمانی می‌تواند هزینه‌های API را به شدت افزایش دهد.

برای سازمان‌هایی که عامل‌های AI را در مقیاس تولیدی اجرا می‌کنند، این شفافیت یک ضرورت عملیاتی است. بر اساس مستندات قانون AI اتحادیه اروپا، به‌ویژه ماده ۱۲، این انتظار وجود دارد که سیستم‌ها رفتار خود را ثبت کرده و آن را درک کنند. درک اینکه «عامل من واقعاً چه چیزی ارسال می‌کند» نیازمند داده‌های سخت از مرز API است، نه بر اساس افسانه‌ها یا حدسیات.

متدولوژی فنی

پژوهشگران برای جداسازی این هزینه‌ها، یک پروکسی ثبت‌کننده (Logging Proxy) بین هر ابزار (Harness) و نقطه اتصال مدل قرار دادند. مسیر جریان داده به این صورت بود: ابزار (Claude Code یا OpenCode) $ \rightarrow $ پروکسی $ \rightarrow $ نقطه اتصال مدل.

این پروکسی دو داده کلیدی را در هر درخواست ثبت می‌کرد:

• پالود JSON دقیق: این شامل بلوک‌های سیستمی، طرح‌های ابزار (Tool Schemas) و پیام‌های ارسال شده توسط ابزار است. این داده به عنوان «حقیقت مطلق» برای آنچه ابزار ارسال می‌کند در نظر گرفته می‌شود.
• بلوک مصرف API: این بخش شامل کل توکن‌های ورودی، نوشتن در کش (Cache Writes)، خواندن از کش (Cache Reads) و توکن‌های خروجی است. این داده به عنوان حقیقت مطلق برای آنچه واقعاً محاسبه و صورت‌حساب شده است، تلقی می‌شود.

پارامترهای آزمایش

• ابزارها: نسخه‌های Claude Code 2.1.207 و OpenCode 1.17.18، که هر دو روی مدل claude-sonnet-4-5 (نسخه جولای ۲۰۲۶) تثبیت شده بودند.
• جداسازی پایه: استفاده از دایرکتوری‌های پیکربندی تازه بدون سرورهای MCP، بدون تنظیمات کاربر و بدون حافظه؛ یک فضای کاری خالی بدون فایل‌های دستورالعمل؛ و دور زدن مجوزها. سپس متغیرهای ضرب‌کننده یکی‌یکی اضافه شدند.
• تسک‌ها:
  • تسک T1: «دقیقاً پاسخ بده: OK» (برای جداسازی اضافه‌بار ثابت؛ سه بار اجرا برای هر ابزار).
  • تسک T2: خواندن یک فایل از پیش تعیین شده و خلاصه‌سازی آن.
  • تسک T3: یک حلقهٔ «نوشتن-اجرا-تست-اصلاح» روی مسئلهٔ FizzBuzz به همراه یک اسکریپت بررسی‌کننده.
• نسخه بدون ابزار: برای جداسازی وزن پرامپت سیستمی از وزن طرح ابزارها، پژوهشگران از --tools "" برای Claude Code و "tools": {"*": false} برای OpenCode استفاده کردند.
• کالیبراسیون: یک درگاه (Gateway) محلی ۶,۲۰۰ توکن ثابت به درخواست‌ها اضافه می‌کرد که از تمامی ارقام کسر شد. تبدیل کاراکتر به توکن با استفاده از نسبت ۴.۱ تا ۴.۴ کاراکتر به ازای هر توکن (متناسب با هر ابزار) انجام شد که از نقاط لنگرِ کش-سرد (Cold-Cache Anchors) — جایی که مقدار نوشتن در کش برابر با کل پالود است — استخراج شده بود.

هزینهٔ «کف» توکنی

در یک تسک ۲۲ کاراکتری (T1)، تفاوت در اولین درخواست تکان‌دهنده بود:

• Claude Code: حدود ۳۲,۸۰۰ توکن (کل پالود).
• OpenCode: حدود ۶,۹۰۰ توکن (کل پالود).

جزئیات اجزای Claude Code شامل ۲۷,۳۴۴ کاراکتر در سه بلوک پرامپت سیستمی، ۹۹,۷۷۸ کاراکتر برای ۲۷ ابزار و ۷,۹۹۷ کاراکتر برای بلوک‌های <system-reminder> بود. در مقابل، OpenCode تنها از یک بلوک سیستمی ۹,۳۲۴ کاراکتری و ۲۰,۸۵۶ کاراکتر برای ۱۰ ابزار استفاده کرد.

در واقع درخواست Claude Code مانند یک بوت‌ستراپ برای پلتفرم عمل می‌کند. ابزارهای آن فقط شامل توابع اصلی کدنویسی نیست، بلکه یک مجموعه ارکستراسیون شامل CronCreate، Monitor، خانواده Task، مدیریت worktree و اعلان‌های push را در بر می‌گیرد. علاوه بر این، پیش از اولین پیام کاربر، سه بلوک <system-reminder> تزریق می‌کند که جزئیات مربوط به انواع عامل‌ها برای تفویض، مهارت‌های موجود و زمینهٔ کاربر را شرح می‌دهند.

حتی وقتی ابزارها کاملاً غیرفعال باشند، شکاف همچنان باقی است. پرامپت سیستمی خالص Claude Code حدود ۲۶,۸۹۱ کاراکتر (تقریباً ۶,۵۰۰ توکن) وزن دارد، در حالی که پرامپت OpenCode حدود ۸,۸۱۱ کاراکتر (تقریباً ۲,۰۰۰ توکن) است. این مقدار باقی‌مانده شامل دکترین رفتاری، یعنی قوانین لحن، راهنمای ایمنی، دستورالعمل‌های مدیریت وظایف و توصیفات محیطی است.

مقیاس‌پذیری پالود در تسک‌های تک‌ابزاری

در تسک خلاصه‌سازی فایل (T2)، هر دو مدل نتایج درستی دادند اما بهره‌وری متفاوت بود. Claude Code به ۶ درخواست HTTP و مجموعاً ۱۹۹,۰۰۰ توکن ورودی محاسبه‌شده نیاز داشت. OpenCode تنها با ۴ درخواست و تقریباً ۴۱,۰۰۰ توکن به هدف رسید، به علاوه یک فراخوانی جانبی مدل Haiku برای نام‌گذاری جلسه.

اگرچه بسیاری از این توکن‌ها از طریق خواندن از کش (که با یک‌دهم قیمت ورودی محاسبه می‌شود) پردازش می‌شوند، اما سه عامل همچنان بدون توجه به تخفیف، مقیاس‌پذیر هستند: اولین نوشتن در کش در نوبت اول، خواندن در هر نوبت و اشغال پنجرهٔ زمینه. یک کف ۳۳ هزار توکنی یعنی هر نوبت گفتگو، پیش از ورود اولین خط کد، یک‌ششم از پنجرهٔ ۲۰۰ هزار توکنی را می‌بلعد. هرچند این اعداد بالا به نظر می‌رسند، اما مدیریت بهینه بستر متن توسط توسعه‌دهندگان می‌تواند در بلندمدت این هزینه‌های API را به‌شدت کاهش دهد.

ضرب‌کننده‌های هزینه

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

۱. فایل‌های دستورالعمل: افزودن یک فایل دستورالعمل در سطح تولید با حجم ۷۲ کیلوبایت (مانند AGENTS.md یا CLAUDE.md) به‌طور متوسط ۲۰,۰۰۰ توکن به هر درخواست اضافه می‌کند.

• OpenCode: مجموع توکن‌های محاسبه‌شده از ۱۳,۱۵۲ به ۳۳,۳۳۶ رسید.
• Claude Code: مجموع توکن‌ها از ۳۹,۰۰۵ به ۵۹,۲۴۳ افزایش یافت.

نکته قابل توجه این است که نسخه ۲.۱.۲۰۷ Claude Code فایل AGENTS.md را نادیده گرفت و تنها زمانی آن را جذب کرد که نامش به CLAUDE.md تغییر یافت و سپس آن را در اولین پیام کاربر تزریق کرد. OpenCode هر دو نام فایل را پذیرفت و آن را در پرامپت سیستمی تزریق کرد. این نشان‌دهنده ریسکی است که در آن یک فایل دستورالعمل نادیده گرفته شده، ساکت می‌ماند اما منجر به رفتارهای غیرمنتظره در عامل می‌شود.

۲. سرورهای MCP: پروتکل زمینهٔ مدل (MCP) برای هر سرور کوچک حدود ۱,۰۰۰ تا ۱,۴۰۰ توکن هزینه در هر درخواست اضافه می‌کند. ۵ سرور، ۴,۹۰۰ توکن به Claude Code و ۶,۹۶۷ توکن به OpenCode اضافه کرد و تعداد ابزارها را از ۲۷ به ۶۹ (در Claude) و از ۱۰ به ۵۲ (در OpenCode) رساند.

یک نکته عملیاتی: Claude Code در حالت print، فایل .mcp.json را که در سطح پروژه بود به‌طور بی‌صدا نادیده گرفت تا زمانی که پرچم صریح --mcp-config ارسال شد. بنابراین تایید در مرز API ضروری است تا مشخص شود آیا سرور واقعاً متصل شده است یا خیر.

۳. قالب‌های چارچوب: چارچوب‌های گردش کار مانند BMAD، دستورات slash را به قالب‌های بزرگی از پرسوناهای تعریف شده، پروتکل‌ها و چک‌لیست‌ها تبدیل می‌کنند. یک قالب نماینده با ۸,۴۰۵ کاراکتر، تقریباً ۲,۱۰۰ توکن اضافه می‌کند. چون این محتوا وارد تاریخچه گفتگو می‌شود، در هر درخواست بعدی دوباره حمل می‌شود. در یک جلسه با ۹ درخواست، این «مالیات چارچوب» نُه بار پرداخت می‌شود.

۴. زیر-عامل‌ها (Subagents): تفویض کار (Delegation) تهاجمی‌ترین ضرب‌کننده است. تسکی که به صورت مستقیم ۱۲۱,۰۰۰ توکن هزینه داشت، هنگام پخش شدن بین دو زیر-عامل به ۵۱۳,۰۰۰ توکن جهش کرد (ضریب ۴.۲ برابر). دلیل آن این است که:
۱. هر زیر-عامل هزینه بوت‌ستراپ خودش را می‌پردازد. زیر-عامل‌های Claude از یک پرامپت سیستمی ۳,۵۵۴ کاراکتری و ۲۴ ابزار از ۲۷ ابزار موجود استفاده کردند.
۲. عامل اصلی باید کل متن و تاریخچه کار زیر-عامل را مصرف کند.

طراحی زیر-عامل در OpenCode سبک‌تر بود و از پرامپت سیستمی ۱,۳۷۹ کاراکتری و تنها ۵ ابزار استفاده می‌کرد. با این حال، تفویض همچنان بزرگ‌ترین ضرب‌کننده توکنی اندازه‌گیری شده است.

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

ناکارآمدی کش: مدرک جرم

کشینگ پرامپت برای کاهش هزینه‌ها طراحی شده است، اما این مطالعه نشان داد که Claude Code بسیار کمتر از رقیبش بهینه است. OpenCode پیشوندهای بایت-به-بایت یکسانی (Byte-identical) در هر اجرا ارسال می‌کرد و تنها یک‌بار هزینه کشینگ پالود خود را در هر جلسه پرداخت می‌کرد و سپس آن را با هزینه‌ای بسیار اندک می‌خواند.

در مقابل، Claude Code «ناپایداری پیشوند» (Prefix Instability) قابل توجهی نشان داد. این ابزار سه کلاس مختلف درخواست در هر جلسه ارسال می‌کرد: یک کاوش گرم‌کن (Warmup Probe)، گفتگوی اصلی و فراخوانی‌های زیر-عامل؛ که هر یک نیاز به ورودی کش جداگانه داشتند. علاوه‌بر این، بایت‌های سیستمی آن بین جلسات در یک فضای کاری یکسان متغیر بود و داربست اولین پیام نیز بین اجراها تغییر می‌کرد.

در تسک خلاصه‌سازی فایل (T2)، نتایج نشان داد:

• OpenCode: ۱,۰۰۳ توکن کش نوشته شد.
• Claude Code: ۵۳,۸۳۹ توکن کش نوشته شد.

Claude Code بازنویسی‌های کاملی از پیشوند خود در اواسط تسک انجام داد (تقریباً ۴۳ هزار توکن در یک اجرا و ۳۶ هزار در اجرای دیگر). بسته به دمای کش، حجم نوشتن Claude Code بین ۵.۹ تا ۵۴ برابر بیشتر از OpenCode بود. از آنجا که نوشتن در کش با قیمت ویژه محاسبه می‌شود (۱.۲۵ برابر برای TTL ۵ دقیقه‌ای و ۲ برابر برای TTL یک ساعته)، این موضوع توضیح می‌دهد که چرا داشبوردهای مصرف در جلسات Claude Code به‌سرعت بالا می‌روند.

کجا Claude Code برنده است؟

یک سناریو وجود دارد که در آن ابزار سنگین‌تر مزیت می‌یابد: تسک‌های پیچیده و چندمرحله‌ای. در حلقه «نوشتن-اجرا-تست-اصلاح» (T3)، نتایج نزدیک شدند:

• Claude Code: ۳۹ درخواست (+۱ فراخوانی عنوان)، مجموعاً حدود ۱۲۱,۰۰۰ توکن ورودی محاسبه‌شده.
• OpenCode: ۴۰ درخواست، مجموعاً حدود ۱۳۲,۰۰۰ توکن ورودی محاسبه‌شده.

Claude Code در اینجا پیروز می‌شود زیرا چندین فراخوانی ابزار (مثلاً دو نوشتن فایل و دو اجرای اسکریپت) را در یک رفت‌وبرگشت موازی دسته‌بندی (Batch) می‌کند. OpenCode دقیقاً یک فراخوانی ابزار در هر نوبت انجام داد و ۹ نوبت زمان برد. چون کف توکنی در هر درخواست دوباره ارسال می‌شود، OpenCode کف ۷ هزار توکنی خود را ۹ بار پرداخت کرد، در حالی که Claude Code کف ۳۳ هزار توکنی خود را تنها ۳ بار پرداخت کرد. این ثابت می‌کند که اگرچه счет‌شمار Claude Code بالاتر شروع می‌شود، اما دسته‌بندی تهاجمی می‌تواند هزینه اولیه را در جلسات طولانی و پیچیده جبران کند.

علاوه‌بر این، داربست Claude Code با افزایش تعداد نوبت‌ها رشد می‌کند و بلوک‌های <system-reminder> اضافی تزریق می‌کند (۳ بلوک در نوبت اول و ۴ بلوک در اولین دور ابزار). پالود حاشیه‌ای OpenCode در هر نوبت ساده‌تر است و صرفاً شامل محتوای گفتگوست (تقریباً ۴۰۰ تا ۲,۲۰۰ کاراکتر در هر نوبت).

«عدد کلی» (The Everything Number)

هنگام اجرای یک پیکربندی کامل کاری، کف توکنی منفجر شد. برای OpenCode، این به معنای ۱۱ سرور MCP (ایمیل، تقویم، وظایف، مرجع و تحلیل محصول) به علاوه فایل دستورالعمل ۷۲ کیلوبایتی بود. اولین درخواست در حالت نوشتن کش-سرد، ۹۰,۸۱۷ توکن ثبت کرد که حامل ۱۷۹ ابزار و ۲۷۷ کیلوبایت طرح (Schema) بود.

برای Claude Code، چهار سرور MCP، پلاگین‌های نصب شده و همان فایل دستورالعمل، پالودی ۳۱۱ کیلوبایتی با حدود ۷۵,۰۰۰ توکن و ۱Tenemos ۱۱۸ ابزار تولید کرد.

این نشان‌دهنده یک ضرب‌کننده پیکربندی تقریباً ۱۲ برابری نسبت به کف اولیه ۷,۰۰۰ توکنی است. ابزار کف را تعیین می‌کند، اما پیکربندی خاص کاربر است که صورت‌حساب نهایی را مشخص می‌کند.

حسابرسی و شفافیت

برای تضمین یکپارچگی این نتایج، پژوهشگران با این بنچمارک مانند یک لاگ حسابرسی برخورد کردند. هر یک از ۱۵۰ رکورد ثبت شده درخواست/پاسخ در یک زنجیره حسابرسی مقاوم در برابر دستکاری با هش SHA-256 با استفاده از کتابخانه متن‌باز @systima/aiact-audit-log نوشته شد.

این زنجیره به عنوان معتبر تایید شد و هیچ شکستگی در آن یافت نشد، که دقیقاً توالی آنچه ارسال و از مدل دریافت شد را بازسازی می‌کند. این همان مک这两نیزمی است که برای لاگینگ ماده ۱۲ قانون AI اتحادیه اروپا جهت ارائه سوابق ساختاریافته و بازسازی رفتار سیستم برای اشخاص ثالث فراهم شده است.

نتیجه‌گیری‌های نهایی و ملاحظات

برای متخصصان، نکته کلیدی این است که «مهندسی پرامپت» اکنون به مدیریت اضافه‌بارهای سیستمی گسترش یافته است. یک بوت‌ستراپ ۸۵ هزار توکنی، بیش از ۴۰٪ از یک پنجرهٔ ۲۰۰ هزار توکنی را اشغال می‌کند و فضای کمتری برای کد باقی می‌گذارد، پیش از آنکه سیستم مجبور شود توکن‌های بیشتری را صرف خلاصه‌سازی و فشرده‌سازی کند.

ملاحظات کلیدی:

• این مطالعه از یک ماشین، یک جفت نسخه و یک خانواده مدل (اسنپ‌شات جولای ۲۰۲۶) استفاده کرده است.
• یک درگاه محلی به‌طور بی‌صدا یک اسنپ‌شات جدیدتر از مدل را جایگزین مدل تثبیت شده کرد، که تاکید می‌کند بدون لاگینگ در مرز API، شما ممکن است ندانید دقیقاً کدام مدل در حال اجراست.
• همگرایی در T3 مربوط به یک شکل خاص از تسک بود؛ تسک‌های صرفاً متوالی دوباره هزینه‌های Claude Code را بالا می‌برند.
• مسیرهای بدون ابزار و زیر-عامل در OpenCode استریم‌های ناقصی را از طریق درگاه بازگرداندند، بنابراین فقط اندازه پالودهای ثبت شده برای آن شرایط گزارش شده است.

اگر شما سیستم‌های عامل‌محور را در محیط تولید اجرا می‌کنید و نمی‌توانید دقیقاً پاسخ دهید که سه‌شنبه گذشته چه چیزی به مدل ارسال شده است، شما یک شکاف در دیدبانی (Visibility Gap) دارید. با پیاده‌سازی یک پروکسی ثبت‌کننده در مرز API، حسابداری توکن‌ها — و به دنبال آن بهینه‌سازی هزینه — به‌طور رایگان حاصل می‌شود.

گام بعدی شما

• اگر از ابزارهای عامل‌محور استفاده می‌کنید، یک پروکسی ساده برای ثبت توکن‌های ورودی/خروجی (Input/Output) در مرز API قرار دهید تا هزینه واقعی داربست‌ها را بسنجید.
• برای کاهش هزینه‌ها، تعداد سرورهای MCP فعال را به حداقل مورد نیاز برسانید.
• در تسک‌های پیچیده، از قابلیت Batching برای کاهش دفعات ارسال پرامپت سیستمی استفاده کنید.

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