مدیریت هزینه‌های AI Agent روی VPS و جلوگیری از شارژ اضافه

چگونه از افزایش هزینه‌های یک AI agent همیشه فعال جلوگیری کنیم

کنترل هزینه AI agent روی یک VPS (سرور مجازی) به سقف‌هایی بستگی دارد که پیش از شروع کار عامل تعیین می‌کنید، زیرا در حین اجرا کسی کنتور را چک نمی‌کند. هر پاسخ را با max_tokens محدود کنید، تعداد تکرار حلقه‌ها را در کد خود محدود نمایید، بخشی از prompt که تغییر نمی‌کند را کش کنید و میزان مصرف هر پاسخ را لاگ کنید تا متوجه شوید کدام عملیات هزینه ایجاد می‌کند. اجاره سرور یک هزینه ماهانه ثابت است. API مدل بر اساس توکن محاسبه می‌شود و یک حلقه بدون نظارت به‌راحتی می‌تواند توکن‌ها را به‌طور بی‌صدا مصرف کند.

این راهنما فرض می‌کند عاملی دارید که از قبل وجود دارد و از روی سروری که مالک آن هستید، با Messages API تماس می‌گیرد. ساخت یک AI agent با Claude روی یک VPS به جزئیات فنی خودِ این ساختار می‌پردازد.

چرا یک عامل (agent) بدون نظارت، ساختار هزینه‌ای متفاوتی دارد

یک نشست تعاملی دارای یک کاربر انسانی است. زمانی که مدل مسیر اشتباهی را طی می‌کند یا یک لاگ 40,000 خطی را می‌خواند، فرد ناظر آن را متوقف می‌کند. یک عامل بدون نظارت چنین ترمز بازدارنده‌ای ندارد: تا پایان حلقه اجرا می‌شود و سپس یک تایمر، آن را دوباره شروع می‌کند.

تکرار، همان ضریبی است که افراد از آن غافل می‌شوند. کاری که طبق برنامه هر پنج دقیقه اجرا می‌شود، 288 بار در روز و حدود 8,640 بار در ماه اجرا خواهد شد. هزینه هر بار اجرا، عددی است که باید آن را در این تعداد ضرب کنید. بسیاری از عامل‌های «همیشه روشن» نیازی به روشن بودن دائمی ندارند. آن‌ها فقط باید در بازه زمانی مشخصی پاسخ دهند که این خود یک زمان‌بندی است.

یک عامل همچنین هزینه‌هایی را متحمل می‌شود که یک پنجره چت شامل آن‌ها نمی‌شود.

• تعریف ابزارها در هر درخواست همراه هستند. پرامپت سیستمی استفاده از ابزار در Claude Opus 4.8 با tool_choice از auto یا none، معادل 290 توکن و با any یا tool معادل 410 توکن هزینه دارد. ابزار bash نیز 325 توکن دیگر اضافه می‌کند. هر سرور MCP که متصل می‌کنید، شمای خود را به این وزن می‌افزاید؛ MCP همان پروتکل زمینه مدل (Model Context Protocol) است.
• نتایج ابزارها، توکن‌های ورودی محسوب می‌شوند. دستوری که 8,000 خط خروجی چاپ می‌کند، 8,000 خط را به درخواست بعدی و به تمام درخواست‌های پس از آن در همان نوبت وارد می‌کند.
• صفحات دریافت‌شده، توکن‌های ورودی هستند. یک صفحه وب معمولی 10 کیلوبایتی تقریباً 2,500 توکن و یک فایل PDF تحقیقاتی 500 کیلوبایتی تقریباً 125,000 توکن است. max_content_tokens فقط متن‌ها را کوتاه می‌کند، زیرا این قابلیت «برای محتوای متنی اعمال می‌شود، نه محتوای باینری مانند PDFها». برای محدود کردن PDF از max_uses و allowed_domains استفاده کنید.
• جستجوی وب به ازای هر جستجو قیمت‌گذاری می‌شود و هزینه آن 10 دلار به ازای هر 1,000 جستجو است، فارغ از اینکه چه تعداد نتیجه بازگردانده شود. جستجویی که با خطا مواجه شود، مشمول هزینه نخواهد بود.

هیچ‌کدام از این موارد در یک بار اجرا گران نیستند. اما همه آن‌ها در 8,640 بار اجرا، هزینه‌بر خواهند بود.

سقف‌های سخت و سقف‌های نرم مشکلات متفاوتی را حل می‌کنند

max_tokens اعمال می‌شود. این یک سقف سخت برای مجموع خروجی یک درخواست، شامل متن تفکر و متن پاسخ است. Claude هرگز از این حد فراتر نمی‌رود و مدل نمی‌تواند این عدد را ببیند. رسیدن به این سقف منجر به stop_reason: "max_tokens" و پاسخ ناقص می‌شود. نکته مهم برای عامل‌ها (agents): هر درخواست در یک حلقه استفاده از ابزار، max_tokens خاص خود را دارد، بنابراین این سقف یک پاسخ را محدود می‌کند و نه کل وظیفه را. ده فراخوانی ابزار با 4,000 توکن، به معنای سقفی برابر با 40,000 توکن برای آن نوبت است.

بودجه وظیفه (task budget) توصیه‌ای است. task_budget در داخل output_config قرار دارد و به مدل می‌گوید که برای کل حلقه عامل، شامل تفکر، فراخوانی ابزار، نتایج ابزار و خروجی، چه تعداد توکن در اختیار دارد.

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["task-budgets-2026-03-13"],
    output_config={"task_budget": {"type": "tokens", "total": 64000}},
    messages=messages,
)

"بودجه‌های وظیفه یک راهنمای نرم هستند، نه یک سقف سخت." Claude ممکن است در میانه یک عملیات از آن فراتر رود، اما محدودیت اعمال‌شده بر خروجی همچنان max_tokens است. حداقل task_budget.total پذیرفته‌شده 20,000 توکن است و مقادیر کمتر، خطای 400 برمی‌گردانند. بودجه‌ای که برای کار بسیار کوچک باشد، رفتاری شبیه به امتناع ایجاد می‌کند، بنابراین مدل دامنه وظیفه را محدود کرده یا زودتر متوقف می‌شود.

یک جزئیات خاص به جای صرفه‌جویی، هزینه ایجاد می‌کند. اگر کلاینت شما task_budget.remaining را در هر درخواست پیگیری کاهش دهد، مقدار تغییریافته باعث ابطال هرگونه پیشوند کش‌شده‌ای می‌شود که آن را در بر دارد. آن را فقط یک بار، در اولین درخواست تنظیم کنید.

بودجه‌های وظیفه در نسخه بتا برای Claude Fable 5.1، Claude Fable 5، Claude Opus 5.5، Claude Opus 5، Claude Opus 4.8، Claude Opus 4.7، Claude Sonnet 5.5 و Claude Haiku 5.5 در دسترس هستند. مدل‌های Claude Sonnet 5 و Claude Haiku 4.5 به عنوان Not supported فهرست شده‌اند و بودجه‌های وظیفه برای Claude Code اعمال نمی‌شوند، بنابراین یک نشست Claude Code جدا شده در tmux به رعایت بهداشت نشست بستگی دارد.

سقف سوم در Claude Console قرار دارد: به عامل فضای کاری (workspace) اختصاصی خود را بدهید، سپس یک محدودیت هزینه ماهانه و محدودیت نرخ در هر دقیقه برای آن تعیین کنید. شما نمی‌توانید برای Default Workspace محدودیت هزینه تعیین کنید و محدودیت‌های کل سازمان همیشه اعمال می‌شوند. اعلان‌های هزینه را اضافه کنید تا یک آستانه، پیش از رسیدن به سقف، به شما هشدار دهد.

انتخاب مدل برای هر وظیفه و عواملی که واقعاً تلاش را تغییر می‌دهند

انتخاب مدل یک تصمیم برای هر وظیفه است. تا اکتبر 2026، به ازای هر میلیون توکن (ورودی و سپس خروجی): Claude Fable 5.1 و Fable 5 با قیمت 10 و 50 دلار، Claude Opus 5.5 با قیمت 4 و 20 دلار، Claude Opus 5، Opus 4.8 و Opus 4.7 با قیمت 5 و 25 دلار، Claude Sonnet 5.5 و Sonnet 5 با قیمت 2 و 10 دلار، Claude Haiku 5.5 با قیمت 0.10 و 0.50 دلار برای پرامپت‌های تا 100,000 توکن (0.50 و 2.50 دلار برای مقادیر بالاتر، توکن‌های کش‌شده در شمارش لحاظ می‌شوند) و Claude Haiku 4.5 با قیمت 1 و 5 دلار عرضه می‌شوند. Anthropic ابتدا Sonnet 5 را با آن قیمت به عنوان نرخ مقدماتی فروخت، سپس آن را به قیمت استاندارد تبدیل کرد و افزایش برنامه‌ریزی‌شده به 3 و 15 دلار را لغو نمود. وظیفه‌ای که فقط خطوط لاگ را دسته‌بندی می‌کند، نیازی به Opus ندارد.

روی استفاده رایگان برای پوشش یک برنامه کاری شلوغ حساب نکنید. جدا از اعتبار اندکی که Claude API هنگام ثبت‌نام اعطا می‌کند، طرح‌های Claude Max، Ultra و Team شامل اعتبار ماهانه API هستند: 100 دلار در Max، 200 دلار در Ultra و تا 500 دلار به صورت اشتراکی در Team که در هر چرخه صورت‌حساب تمدید می‌شود. می‌توانید آن را پس از 7 روز در یک طرح واجد شرایط مطالبه کنید و نیازی به روش پرداخت نیست. این اعتبار Claude API، Managed Agents، Agent SDK و playground را پوشش می‌دهد اما شامل Claude Code نمی‌شود و در پایان هر چرخه بدون انتقال به دوره بعد منقضی می‌شود. مصرف آن در سقف هزینه شما لحاظ می‌شود و پس از اتمام، درخواست‌های پیش‌پرداخت متوقف می‌شوند مگر اینکه سازمان دارای اعتبارات خریداری‌شده نیز باشد. سازمان‌هایی که از طریق فروش Anthropic صورت‌حساب دریافت می‌کنند، برای استفاده بیش از اعتبارات به روال معمول صورت‌حساب دریافت می‌کنند.

تلاش (effort) اهرم دوم است. output_config.effort از low، medium، high، xhigh و max پشتیبانی می‌کند، هرچند همه مدل‌ها از تمام سطوح پشتیبانی نمی‌کنند. مقدار پیش‌فرض در اکثر مدل‌ها high و در Claude Opus 5.5 و Claude Haiku 5.5 برابر با medium است و تنظیم صریح مقدار پیش‌فرض مدل، تفاوتی با حذف آن ندارد. تلاش کمتر، فراتر از کاهش طول استدلال عمل می‌کند: مستندات می‌گویند این کار باعث می‌شود Claude فراخوانی‌های ابزار (tool calls) کمتری انجام دهد و چندین عملیات را در فراخوانی‌های کمتری ترکیب کند. در یک عامل (agent)، این صرفه‌جویی بزرگ‌تری است، زیرا یک فراخوانی ابزارِ حذف‌شده، یک درخواست کامل است که هرگز انجام نمی‌شود.

دام اینجاست که تلاش با کش (cache) تداخل دارد. تغییر مقدار سطح بالا بین درخواست‌ها، prompt caching را باطل می‌کند. در مثال مستندشده برای Claude Opus 5.5، درخواست 2 مقدار cache_read_input_tokens: 3546 را گزارش کرد. درخواست 3 تلاش را از medium (پیش‌فرض آن مدل) به low تغییر داد و cache_creation_input_tokens از 3546 و cache_read_input_tokens از 0 را گزارش کرد. بنابراین تلاش سطح بالا را در بارهای کاری مختلف تغییر دهید، نه در یک مکالمه کش‌شده. دو مسیر برای تغییر عمق بدون شکستن کش وجود دارد. در Claude Fable 5.1، Opus 5.5، Opus 5، Sonnet 5.5 و Haiku 5.5، تغییر تلاش برای هر پیام (نسخه بتا، هدر mid-conversation-output-config-2026-07-01) سطح جدیدی را تعیین می‌کند و پیشوند کش‌شده را دست‌نخورده باقی می‌گذارد. در هر مدلی می‌توانید در پرامپت هدایت کنید: خطی مانند "Answer directly without deliberating." در جدیدترین پیام کاربر، نقاط شکست قبلی را دست‌نخورده باقی می‌گذارد. اگرچه در Claude Haiku 5.5، این عبارت به طور قابل اعتمادی تفکر را کاهش نمی‌دهد.

توکن‌های تفکر با نرخ خروجی محاسبه می‌شوند و در max_tokens لحاظ می‌گردند، به همین دلیل است که پاسخ ناقص اغلب به این معنی است که تفکر بودجه را مصرف کرده است. برای مشاهده عدد، usage.output_tokens_details.thinking_tokens را بخوانید. آنچه واقعاً صورت‌حساب توکن Claude را پر می‌کند این متریک را کالبدشکافی می‌کند.

پیشوند پایدار را کش کنید و از شکستن تصادفی آن جلوگیری کنید

هزینه نوشتن در کش برای کش 5 دقیقه‌ای 1.25 برابر قیمت ورودی پایه و برای کش 1 ساعته 2 برابر است. در اکثر مدل‌ها، هزینه خواندن از کش 0.1 برابر است؛ بنابراین «کش کردن پس از یک بار خواندن برای مدت 5 دقیقه (1.25 برابر نوشتن) یا پس از دو بار خواندن برای مدت 1 ساعت (2 برابر نوشتن) صرفه اقتصادی دارد». هزینه خواندن در جدیدترین مدل‌ها حتی کمتر است: 0.05 برابر در Claude Opus 5.5 و Claude Sonnet 5.5، و 0.025 برابر در Claude Fable 5.1.

یک جمله دلیل مناسب بودن این روش برای یک ایجنت همیشه فعال را توضیح می‌دهد: «کش هر بار که محتوای کش‌شده استفاده می‌شود، بدون هزینه اضافی تازه می‌شود.» شغلی که هر دو دقیقه یک‌بار روی کش 5 دقیقه‌ای اجرا می‌شود، پیشوند خود را در تمام طول روز تنها با یک بار نوشتن، فعال نگه می‌دارد.

سه روش برای از دست دادن کش بدون اینکه متوجه شوید:

پیشوندی که تغییر می‌کند. «پیشوندهای کش به ترتیب زیر ایجاد می‌شوند: tools، system، سپس messages.» هرگونه تغییر بایت در ابتدای این ترتیب، تمام موارد بعدی را باطل می‌کند و ویرایش تعاریف ابزارها کل کش را از بین می‌برد. اشتباه رایج که توسط خود کاربر ایجاد می‌شود، قرار دادن یک timestamp یا run id در system prompt است: در این صورت هر درخواست یک پیشوند متفاوت خواهد داشت، یک ورودی جدید با هزینه 1.25 برابر می‌نویسد و هیچ داده‌ای از کش نمی‌خواند. نشانه این اتفاق، مقدار 0 برای usage.cache_read_input_tokens در فراخوانی‌های مشابه است. متن‌های متغیر را به جدیدترین پیام کاربر منتقل کنید.

پیشوندی که بیش از حد کوتاه است. هر مدل حداقل طول قابل کش شدن دارد و در صورت کمتر بودن از آن، درخواست بدون کش کردن پردازش می‌شود و «هیچ خطایی بازگردانده نمی‌شود». این مقادیر شامل 512 توکن برای Claude Fable 5.1، Fable 5، Opus 5.5، Opus 5، Sonnet 5.5 و Haiku 5.5، تعداد 1,024 برای Claude Opus 4.8 و Claude Sonnet 5، و 4,096 برای Claude Haiku 4.5 است؛ بنابراین انتقال یک کار از Sonnet 5 به Haiku 4.5 می‌تواند کش کردن را به‌طور بی‌صدا غیرفعال کند.

مکالمه‌ای که از محدوده نگاه به عقب (lookback) فراتر می‌رود. «پنجره نگاه به عقب 20 بلوک است.» سیستم حداکثر 20 موقعیت را در هر breakpoint بررسی می‌کند و سپس متوقف می‌شود. در مثال مستند، یک نوبت شامل 35 بلوک با یک breakpoint در بلوک 35، بلوک‌های 35 تا 16 را بررسی می‌کند و ورودی نوبت قبلی در بلوک 15 خارج از این پنجره قرار می‌گیرد، بنابراین هیچ تطابقی (hit) رخ نمی‌دهد. ایجنتی که در هر نوبت چندین بلوک استفاده از ابزار و نتیجه ابزار اضافه می‌کند، در دو یا سه نوبت از مرز 20 عبور می‌کند. شما در هر درخواست چهار breakpoint دارید، پس یکی از آن‌ها را به پیام‌های اخیر اختصاص دهید.

هر کاری که فوریت ندارد را به Batches API بسپارید

«تمام موارد استفاده با 50% قیمت استاندارد API محاسبه می‌شوند»، که این شامل ورودی و خروجی هر دو می‌شود. پردازش دسته‌ای (Batch) به‌صورت غیرهمگام (asynchronous) انجام می‌شود و «بیشتر دسته‌ها در کمتر از 1 ساعت تکمیل می‌شوند». نتایج پس از اتمام تمام درخواست‌ها یا پس از گذشت 24 ساعت، هر کدام که زودتر رخ دهد، در دسترس خواهند بود. این یک وضعیت معمول است، نه یک تضمین.

وضعیت processing_status را تا زمانی که به ended تغییر کند، بررسی (Poll) کنید. درخواست‌هایی که errored، canceled یا expired برمی‌گردانند، مشمول هزینه نمی‌شوند. یک نکته مهم در صورت استفاده از سقف هزینه (spend cap) این است که: «ممکن است دسته‌ها کمی از سقف هزینه تنظیم‌شده برای Workspace شما فراتر بروند.»

تخفیف‌ها با هم جمع می‌شوند و از آنجا که یک دسته ممکن است بیش از 5 دقیقه طول بکشد، مستندات توصیه می‌کنند برای دسته‌هایی که محتوای مشترک دارند، از کش یک‌ساعته استفاده کنید. بنابراین کار را تفکیک کنید: هر چیزی که یک کاربر یا یک webhook منتظر آن است را در مسیر زنده (live path) نگه دارید و پردازش‌هایی مانند گزارش‌های شبانه یا طبقه‌بندی لاگ‌های دیروز را با نصف قیمت به یک دسته (batch) بسپارید.

ثبت فیلدهای مصرف هر پاسخ در ذخیره‌ساز اختصاصی خود

شما نمی‌توانید هزینه‌ای را که ثبت نکرده‌اید، تخصیص دهید. هر پاسخ به شما می‌گوید که چه هزینه‌ای داشته است.

u = resp.usage
row = {
    "job": job_name,
    "model": resp.model,
    "uncached_input": u.input_tokens,
    "cache_write": u.cache_creation_input_tokens,
    "cache_read": u.cache_read_input_tokens,
    "output": u.output_tokens,
    "stop_reason": resp.stop_reason,
}

به ازای هر فراخوانی API، یک ردیف به یک فایل JSON-lines اضافه کنید و آن را با نام job خود برچسب‌گذاری کنید. یک هفته بعد می‌توانید بگویید کدام job هزینه ایجاد کرده و کدام فقط مشغول به نظر می‌رسیده است. cache_read را زیر نظر داشته باشید: ستونی از صفرها، رایج‌ترین باگ هزینه در یک agent خودمیزبان (self-hosted) است.

یک فیلد وجود دارد که به‌راحتی ممکن است اشتباه خوانده شود. input_tokens فقط توکن‌های بعد از آخرین نقطه شکست کش (cache breakpoint) را می‌شمارد، بنابراین اندازه واقعی prompt برابر با total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens است. agentای که برای یک prompt بزرگ، مقدار input_tokens: 400 را گزارش می‌کند، ارزان نیست: بقیه توکن‌ها از کش آمده‌اند.

پیش از ارسال، شمارش کنید. شمارش توکن رایگان است، بنابراین از count_tokens استفاده کنید تا به جای پرداخت هزینه برای کشف یک فایل پیوست بیش‌ازحد بزرگ، از ارسال آن خودداری کنید. نتیجه یک تخمین است، بنابراین برای هر مدل دوباره اندازه‌گیری کنید و هرگز شمارش انجام‌شده توسط tokenizer یک فروشنده دیگر را دوباره استفاده نکنید. مدل‌های Claude 4.7 و بعد از آن، از جمله Claude Fable 5 و Claude Sonnet 5، از tokenizer جدیدتری استفاده می‌کنند که «برای متن یکسان، تقریباً 30 درصد توکن بیشتری تولید می‌کند». مدل‌های Claude Sonnet 4.6 و قدیمی‌تر، از جمله Claude Haiku 4.5، از tokenizer قبلی استفاده می‌کنند.

برای مشاهده دقیق، API قدیمی Usage and Cost، میزان مصرف را در https://api.anthropic.com/v1/organizations/usage_report/messages و هزینه را در https://api.anthropic.com/v1/organizations/cost_report گزارش می‌دهد. هر دو به یک کلید مدیریتی (sk-ant-admin01-...) به عنوان x-api-key: $ANTHROPIC_ADMIN_KEY با anthropic-version: 2023-06-01 نیاز دارند. گزارش مصرف، bucket_width=1d، group_by[]=model و api_key_ids[]= را می‌پذیرد. گزارش هزینه فقط روزانه است و بر اساس workspace_id یا description گروه‌بندی می‌شود. یک محدودیت: «Admin API برای حساب‌های شخصی در دسترس نیست.»

آن پارامتر api_key_ids[] یک ترفند ارزان برای تخصیص هزینه است: به هر job کلید API اختصاصی خود را بدهید، گزارش مصرف را با api_key_ids[] فیلتر کنید و آن را بر اساس کلید با group_by[]=api_key_id تفکیک کنید. فیلتر به صورت جمع است، اما بعد گروه‌بندی به صورت مفرد است. کلیدها را به جای کد، در محیط (environment) نگهداری کنید، همان‌طور که اولین برنامه Claude API روی یک VPS با آن‌ها برخورد می‌کند.

حلقه را محدود کنید، چون هیچ‌چیز دیگری این کار را انجام نمی‌دهد

تعداد تکرار محدود در اینجا اختیاری نیست. حلقه متعلق به شماست، بنابراین شمارنده نیز متعلق به شماست:

for step in range(MAX_STEPS):          # MAX_STEPS = 12, never "while True"
    resp = client.messages.create(...)
    if resp.stop_reason != "tool_use":
        break
else:
    log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)

هیچ‌کدام از سقف‌های تعیین‌شده در بالا این کار را برای شما انجام نمی‌دهند: max_tokens تنها یک پاسخ را محدود می‌کند و به مدل فقط در مورد بودجه وظیفه اطلاع داده می‌شود. برای محدودیت‌های نشست‌های میزبانی‌شده، به محدودیت Claude بر فراخوانی ابزارها در یک نوبت واحد مراجعه کنید. حلقه‌ای که خودتان نوشته‌اید تا زمانی که یک ترمز برای آن اضافه نکنید، فاقد چنین محافظی است.

یک ترمز دوم خارج از فرآیند قرار دهید. کار را به‌جای یک فرآیند دائمی، از طریق یک systemd timer اجرا کنید و برای unit سرویس آن، یک محدودیت زمانی (wall-clock cap) در نظر بگیرید. یک job زمان‌بندی‌شده معمولاً Type=oneshot است و RuntimeMaxSec= «هیچ تأثیری بر سرویس‌های Type=oneshot ندارد»، بنابراین TimeoutStartSec=600 را در آنجا تنظیم کنید. از RuntimeMaxSec=600 فقط در یک unit از نوع Type=simple استفاده کنید. در هر صورت، یک اجرای معلق پس از ده دقیقه متوقف می‌شود، به‌جای اینکه تا زمانی که متوجه شوید به چرخش ادامه دهد. اجرای یک برنامه به عنوان سرویس و تایمر systemd فایل‌های unit را پوشش می‌دهد. آنچه یک اجرا انجام داده است را با journalctl -u triage-agent.service --since "1 hour ago" بررسی کنید.

تعداد تلاش‌های مجدد (retries) را نیز محدود کنید. درخواست‌های API ناموفق هزینه‌ای ندارند، اما درخواستی که در مسیر موفقیت بود، در صورت قطع اتصال یا timeout شدن کلاینت شما، همچنان مشمول هزینه می‌شود. یک خطای 429 یا 500 مستحق چند تلاش مجدد با مکانیزم backoff است. یک خطای 400 مستحق هیچ تلاشی نیست، زیرا همان درخواست به همان شکل شکست می‌خورد.

کنترل هزینه ایجنت‌های هوش مصنوعی با بررسی اعداد و ارقام خودتان آغاز می‌شود

هیچ‌کس نمی‌تواند به شما بگوید هزینه یک ایجنت که همیشه فعال است چقدر خواهد بود، زیرا هزینه برابر است با تعداد توکن در هر اجرا ضرب‌در تعداد دفعات اجرا در روز، و هر دو بخش این معادله متعلق به شماست. ایجنت را یک‌بار اجرا کنید، ردیف مصرفی که ثبت کرده‌اید را بخوانید و آن را در برنامه زمانی خود ضرب کنید. دو روز بعد، گزارش هزینه را با این محاسبات مطابقت دهید. زمانی که این دو با هم همخوانی ندارند، شکاف موجود تقریباً همیشه ناشی از خرابی کش یا حلقه‌ای است که طولانی‌تر از آنچه تصور می‌کردید اجرا شده است.

این موضوع فرض را بر استفاده از API key می‌گذارد، زیرا ایجنت برنامه شخصی شماست که Messages API را فراخوانی می‌کند. برای کارهای تعاملی شخصی خود، کدام طرح Claude با نحوه کار شما متناسب است بخش اشتراک را پوشش می‌دهد. تمام قیمت‌ها و محدودیت‌های ذکر شده در اینجا در اکتبر 2026 با مستندات Anthropic مطابقت داده شده‌اند، بنابراین پیش از تنظیم بودجه، صفحه قیمت‌گذاری را مجدداً مطالعه کنید.

FAQ

هزینه اجرای یک عامل هوش مصنوعی (AI agent) که همیشه روشن است روی یک VPS چقدر است؟

دو صورت‌حساب وجود دارد که فقط یکی از آن‌ها قابل پیش‌بینی است. هزینه سرور یک مبلغ ثابت ماهانه است. API مدل بر اساس تعداد توکن محاسبه می‌شود، بنابراین هزینه نهایی برابر است با حاصل‌ضرب مصرف یک اجرای واحد در تعداد دفعات اجرا. لاگ usage را از یک اجرای واقعی بگیرید و در تعداد دفعات اجرای برنامه‌ریزی‌شده خود ضرب کنید.

تفاوت بین max_tokens و بودجه وظیفه (task budget) چیست؟

مقدار max_tokens اعمال می‌شود و برای مدل نامرئی است. این مقدار خروجی یک درخواست را (شامل فرآیند تفکر) محدود می‌کند و در صورت رسیدن به آن، خطای stop_reason: "max_tokens" دریافت خواهید کرد. بودجه وظیفه برعکس است: این عدد به مدل اعلام می‌شود و عامل، حلقه کاری خود را بر اساس آن تنظیم می‌کند، اما «بودجه‌های وظیفه یک راهنمای نرم هستند، نه یک محدودیت سخت» و محدودیت اعمال‌شده همچنان همان max_tokens است.

چرا مقدار cache_read_input_tokens برای عامل من همیشه صفر است؟

زیرا پیشوند (prefix) بین فراخوانی‌ها تغییر می‌کند یا برای کش شدن بیش از حد کوتاه است. دلیل معمول این اتفاق، وجود یک برچسب زمانی (timestamp) یا شناسه اجرا (run id) است که در system prompt جای‌گذاری می‌شود: کش بر اساس پیشوند کلیدگذاری می‌شود، بنابراین تغییر حتی یک بایت، تمام محتوای پس از آن را نامعتبر می‌کند. تغییر تعاریف ابزارها یا مقدار effort در سطح بالا نیز همین نتیجه را دارد. در غیر این صورت، دلیل آن اندازه است، زیرا پرامپت‌های کوتاه‌تر کش نمی‌شوند و هیچ خطایی هم بازگردانده نمی‌شود.

چگونه از حلقه بی‌نهایت یک عامل هوش مصنوعی جلوگیری کنم؟

تعداد تکرارها را در کد حلقه خود بشمارید و در یک حداکثر مقدار ثابت متوقف شوید، زیرا max_tokens فقط یک پاسخ را محدود می‌کند و یک عامل، درخواست‌های متعددی ایجاد می‌کند. یک محدودیت زمانی (wall-clock) خارج از فرآیند اضافه کنید: کار را از طریق یک systemd timer شروع کنید و برای یک unit از نوع oneshot مقدار TimeoutStartSec=، یا برای یک unit از نوع simple مقدار RuntimeMaxSec= را تنظیم کنید تا اجرای گیرکرده طبق زمان‌بندی کشته شود. تعداد تلاش‌های مجدد (retries) را نیز محدود کنید، زیرا درخواستی که پس از اتمام زمان کلاینت شما با موفقیت انجام شود، همچنان محاسبه هزینه می‌شود.

آیا می‌توانم برای یک کلید API کلود (Claude) محدودیت هزینه تعیین کنم؟

محدودیت هزینه مستندشده، برای هر workspace است نه برای هر کلید؛ بنابراین یک workspace اختصاصی به عامل بدهید و سقف هزینه ماهانه آن را در آنجا محدود کنید. شما نمی‌توانید روی Default Workspace محدودیت هزینه تعیین کنید. اعلان‌های هزینه را فعال کنید تا در صورت رسیدن به یک آستانه، به شما هشدار داده شود. برای انتساب دقیق، برای هر کار یک کلید جداگانه صادر کنید و سپس گزارش مصرف را با استفاده از group_by[]=api_key_id دسته‌بندی کنید.