تصور کنید یک ابزار خودکارسازی که قرار بود بهره‌وری شما را بالا ببرد، در یک شب تمام بودجه ماهانه شما را ببلعد و هیچ خروجی مفیدی تولید نکند. این کابوس برای توسعه‌دهنده‌ای به نام wartzar-bee تبدیل شد که در ۲۰ جولای ۲۰۲۶ گزارش داد یک تایمر ساده برای زنده نگه داشتن یک عامل (Agent) — ابزاری که می‌تواند به‌طور مستقل برای رسیدن به یک هدف، تصمیم بگیرد و ابزارها را اجرا کند — تبدیل به یک حلقه هزینه مرگبار شده است. ۱۳۶ میلیون توکن؛ این قیمت یک جلسه واحد از یک عامل هوش مصنوعی است که در یک شب تمام بودجه خود را مصرف کرد بدون اینکه هیچ کار معناداری را به پایان برساند. به نقل از گزارش این توسعه‌دهنده در وب‌سایت dev.to، این عامل در ۲۰ ساعت، ۱۲۹۷ مرحله را طی کرد، اما ۹۷.۷٪ از توکن‌های پردازش شده صرفاً بازخوانی تاریخچه گفتگو بودند. در واقع، مدل ۵۰۸ میلیون توکن را برای بازخوانی متون قبلی مصرف کرد، در حالی که تنها ۱۱.۹ میلیون توکن مربوط به کارهای جدید بود.
مکانیسم‌های تخریب
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی مدیریت حافظه در مدل‌های زبانی اشاره کردیم، این اتفاق نتیجه مستقیم سه مکانیزم فنی است که در کنار هم یک «تله توکنی» ایجاد کردند. پیش از هر چیز باید درک کرد که اکثر مدل‌های پیشرو بر اساس APIهای بدون وضعیت (Stateless) عمل می‌کنند؛ به این معنا که مدل تعاملات قبلی را به خاطر نمی‌آورد. برای حفظ یک گفتگو، کل تاریخچه — شامل دستورات سیستمی و هر فراخوانی ابزار در مراحل قبل — باید در هر نوبت جدید دوباره به عنوان ورودی ارسال شود.
این سه مکانیزم دقیق‌تر به شرح زیر هستند:
- بدون وضعیت بودن (Statelessness): هر بار که مدل بیدار می‌شود، باید کل رشته گفتگو را دوباره پردازش کند؛ یعنی در مرحله ۲۰، باید هزینه بازخوانی مراحل ۱ تا ۱۹ را دوباره پرداخت کند.
- انقضای حافظه موقت (Cache Expiration): سرویس‌هایی مثل Claude قابلیت ذخیره موقت پرامپت‌ها (Prompt Caching) را دارند تا بازخوانی‌ها ارزان شود، اما این حافظه سریعاً منقضی می‌شود (تقریباً هر ۵ دقیقه). چون تایمر کاربر در بازه‌هایی طولانی‌تر از ۵ دقیقه فعال می‌شد، هر بیداری منجر به یک «راه‌اندازی سرد» (Cold Start) با قیمت کامل ورودی می‌شد.
- رشد تک‌رو (Monotonic Growth): از آنجا که عامل هر اقدام جدید را به انتهای یک رشته پیوسته اضافه می‌کرد، هر بیداری گران‌تر از بیداری قبلی بود. اجرای اول یک رشته کوچک را بازخوانی کرد، اما اجرای پنجاهم یک رشته عظیم را بازخوانی می‌کرد.
طبق مستندات این گزارش، در یک بازه ۵ ساعته، ۱۶ میلیون توکن مصرف شد که ۷۶٪ از سقف اشتراک کل حساب کاربری را از بین برد. نکته تکان‌دهنده این است که هیچ باگی در کد وجود نداشت و سیستم کرش نکرد؛ مدل دقیقاً طبق دستوراتی که برایش نوشته شده بود عمل کرد. در واقع بسیاری از این خطاهای عملیاتی در عامل‌ها با رویکردهای نوین قابل حل هستند و تحلیل‌های ما نشان می‌دهد که بیش از ۷۰٪ شکست‌های عامل‌های هوش مصنوعی با مکانیزم‌های خودترمیمی قابل جبران‌اند.
اصلاحات معماری
برای کسب‌وکارها و برنامه‌نویس‌ها، این یعنی تغییر مدل به یک گزینه ارزان‌تر، مشکل ساختاری را حل نمی‌کند. راهکار واقعی در جداسازی وضعیت (State) از پنجره متنی (Context Window) — یعنی همان میز کاری که مدل برای پردازش اطلاعات در لحظه در اختیار دارد — نهفته است. استراتژی‌های زیر ریسک این اتفاقات را کم می‌کنند:
- جلسات کوتاه: این مؤثرترین اهرم است. به‌جای رشد دادن یک رشته گفتگو برای ۲۰ ساعت، توسعه‌دهندگان باید وضعیت پایدار را در یک فایل روی دیسک ذخیره کرده و هر بار کار را به یک جلسه تازه (Fresh Session) بسپارند. در همین راستا، استفاده از روش‌های ذخیره‌سازی خارجی نظیر بهره‌گیری از پایگاه‌داده SQLite می‌تواند حافظه عامل‌ها را در برابر کرش و اتلاف وضعیت مقاوم کند.
- حلقه‌های قطعی: مدل‌های پیشرو را روی یک تایمر خودکار قرار ندهید. از یک برنامه‌ریز ارزان + یک کارگر محلی/رایگان + یک دروازه تأیید قطعی (Deterministic Verify-Gate) استفاده کنید. این روش اجازه می‌دهد حلقه با هزینه تقریباً صفر یورو اجرا شود، زیرا مدل پیشرو فقط برای تصمیمات حیاتی فراخوانی می‌شود.
- هوش مصنوعی لایه‌بندی شده: استراتژی «نیروی کار ارزان، تأیید پیشرو» را پیاده کنید. کارهای روتین مثل تحقیق، استخراج داده، پیش‌نویس یا اسکن باید روی مدل‌های محلی یا ارزان‌قیمت اجرا شوند و مدل‌های گران‌قیمت پیشرو فقط برای قضاوت نهایی و تأیید رزرو شوند.
- سقف بودجه سخت: بودجه‌ای که اجباری نباشد، فقط یک آرزوست. یک سقف سخت پیاده کنید که در صورت عبور از آن، کار را به تعویق بیندازد و میزان مصرف هر جلسه را مانیتور کنید.
نحوه تشخیص نشت توکن
برای شناسایی این نشت‌ها، توسعه‌دهنده توصیه می‌کند ترانسکریپت‌های جلسه تحلیل شوند. ابزار Claude Code این گزارشات را در مسیر ~/.claude/projects/**/*.jsonl می‌نویسد، جایی که هر شیء JSON شامل یک بلوک مصرف با جزئیات توکن‌های ورودی، خروجی، ایجاد کش (cache_creation) و خواندن کش (cache_read) است.
مقایسه توکن‌های ورودی جدید در مقابل بازخوانی‌های متنی در هر نوبت، فاش می‌کند که آیا عامل‌ها زمان بیشتری را صرف «به یاد آوردن گذشته» می‌کنند یا «اجرای حال». ابزارهایی مثل npx ccusage مجموعت‌ها را در برابر سقف‌های ۵ ساعته نشان می‌دهند، در حالی که tokenscope (از طریق دستور npx @wartzar-bee/tokenscope) ترانسکریپت‌ها را می‌خواند تا هزینه دقیق کارهای جدید را در مقابل توکن‌های کش‌شده و توکن‌های بازخوانی‌شده سرد (Cold Re-read) نمایش دهد.
گام بعدی شما
- اگر از عامل‌های خودکار در پروژه‌هایتان استفاده می‌کنید، فوراً بازه زمانی انقضای کش (Cache) مدل خود را بررسی کنید.
- برای هر جلسه عامل، یک محدوده حداکثری برای تعداد توکن‌های ورودی تعریف کنید تا از رشد تک‌رو جلوگیری شود.
- جریان کاری خود را به مدل‌های محلی (Local Models) منتقل کنید و مدل‌های ابری را فقط به عنوان لایه نظارتی به کار ببرید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ برای درک اینکه چگونه سخت‌افزارها سعی در کاهش این هزینه‌ها دارند، به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو