VPS پر AI ایجنٹ کے اخراجات کو کنٹرول کرنے کا طریقہ

ہمیشہ چلنے والے AI ایجنٹ کے اخراجات کو کنٹرول میں رکھنے کا طریقہ

VPS پر AI ایجنٹ کے اخراجات کو کنٹرول کرنے کا مطلب ہے کہ ایجنٹ شروع کرنے سے پہلے ہی حدیں مقرر کر دی جائیں، کیونکہ اس کے چلنے کے دوران کوئی بھی میٹر کی نگرانی نہیں کر رہا ہوتا۔ ہر response کو max_tokens کے ساتھ محدود کریں، اپنے کوڈ میں loop iterations کی حد مقرر کریں، prompt کے اس حصے کو cache کریں جو کبھی تبدیل نہیں ہوتا، اور ہر response کے استعمال کے اعداد و شمار کو log کریں تاکہ معلوم ہو سکے کہ کون سا کام خرچ بڑھا رہا ہے۔ سرور کا کرایہ ماہانہ ایک مقررہ قیمت پر ہوتا ہے۔ ماڈل API ٹوکنز کے حساب سے چارج کرتا ہے، اور ایک غیر نگرانی شدہ loop خاموشی سے ٹوکنز خرچ کرنے میں بہت ماہر ہوتی ہے۔

یہ فرض کرتا ہے کہ ایک ایجنٹ پہلے سے موجود ہے اور آپ کے اپنے سرور سے Messages API کو کال کرتا ہے۔ VPS پر Claude کے ساتھ AI ایجنٹ بنانا اس کے بنیادی ڈھانچے کا احاطہ کرتا ہے۔

غیر متوجہ (unattended) ایجنٹ کی لاگت کا ڈھانچہ مختلف کیوں ہے

انٹرایکٹو سیشن میں ایک انسان موجود ہوتا ہے۔ جب ماڈل غلط راستے پر جاتا ہے یا 40,000 لائنوں پر مشتمل لاگ پڑھتا ہے، تو اسے دیکھنے والا شخص اسے روک دیتا ہے۔ غیر متوجہ ایجنٹ کے پاس ایسی کوئی بریک نہیں ہوتی: یہ تب تک چلتا ہے جب تک لوپ ختم نہ ہو جائے، پھر ایک ٹائمر اسے دوبارہ شروع کر دیتا ہے۔

تکرار (frequency) وہ ضرب ہے جسے لوگ نظر انداز کر دیتے ہیں۔ 5 منٹ کے شیڈول پر چلنے والا کام دن میں 288 بار اور مہینے میں تقریباً 8,640 بار چلتا ہے۔ ایک بار چلنے کی جو بھی لاگت ہو، اسی کو آپ ضرب دیتے ہیں۔ بہت سے "always-on" ایجنٹس کو ہر وقت چلنے کی ضرورت نہیں ہوتی۔ انہیں صرف چند منٹوں کے اندر جواب دینے کی ضرورت ہوتی ہے، جو کہ ایک شیڈول ہے۔

ایک ایجنٹ ایسی چیزوں کی قیمت بھی ادا کرتا ہے جو چیٹ ونڈو میں نہیں ہوتی۔

• ٹول کی تعریفیں ہر درخواست کے ساتھ شامل ہوتی ہیں۔ ٹول استعمال کرنے والا سسٹم پرامپٹ Claude Opus 4.8 پر tool_choice کے auto یا none کے ساتھ 290 ٹوکنز، اور any یا tool کے ساتھ 410 ٹوکنز خرچ کرتا ہے۔ bash ٹول مزید 325 کا اضافہ کرتا ہے۔ ہر MCP server جسے آپ منسلک کرتے ہیں اس وزن میں اپنے اسکیماز کا اضافہ کرتا ہے، کیونکہ MCP ماڈل کانٹیکسٹ پروٹوکول ہے۔
• ٹول کے نتائج ان پٹ ٹوکنز ہوتے ہیں۔ ایک کمانڈ جو 8,000 لائنیں پرنٹ کرتی ہے، وہ اگلی درخواست میں 8,000 لائنیں شامل کر دیتی ہے، اور اس ٹرن میں اس کے بعد آنے والی ہر درخواست میں بھی۔
• حاصل کردہ صفحات ان پٹ ٹوکنز ہوتے ہیں۔ ایک اوسط 10 kB کا ویب صفحہ تقریباً 2,500 ٹوکنز اور 500 kB کی ریسرچ PDF تقریباً 125,000 ٹوکنز پر مشتمل ہوتی ہے۔ max_content_tokens صرف ٹیکسٹ والے مواد کو ٹرنکیٹ (truncate) کرتا ہے، کیونکہ یہ "ٹیکسٹ مواد پر لاگو ہوتا ہے، نہ کہ بائنری مواد جیسے کہ PDFs پر"۔ اس کے بجائے PDF کو max_uses اور allowed_domains کے ساتھ محدود کریں۔
• ویب سرچ کی قیمت فی سرچ وصول کی جاتی ہے، جو کہ 10 ڈالر فی 1,000 سرچز ہے، قطع نظر اس کے کہ کتنے نتائج واپس آتے ہیں۔ ایسی سرچ جس میں خرابی (error) آئے، اس کا بل نہیں بنایا جاتا۔

ان میں سے کوئی بھی چیز ایک بار میں مہنگی نہیں ہے۔ یہ سب کچھ 8,640 بار ہونے پر مہنگا ہو جاتا ہے۔

Hard ceilings اور soft ceilings مختلف مسائل کا حل پیش کرتے ہیں

max_tokens کا نفاذ کیا جاتا ہے۔ یہ ایک درخواست کے کل آؤٹ پٹ، بشمول سوچنے کے عمل اور جوابی متن، پر ایک سخت حد (hard cap) ہے۔ Claude اس سے آگے کبھی کچھ جنریٹ نہیں کرتا، اور ماڈل اس نمبر کو دیکھ نہیں سکتا۔ اس حد تک پہنچنے پر stop_reason: "max_tokens" موصول ہوتا ہے اور جواب ادھورا رہ جاتا ہے۔ ایجنٹس کے لیے اہم نکتہ: ٹول استعمال کرنے والے لوپ میں ہر درخواست اپنے ساتھ ایک max_tokens رکھتی ہے، لہذا یہ ایک جواب کو محدود کرتا ہے، نہ کہ پورے ٹاسک کو۔ 4,000 ٹوکنز پر دس ٹول کالز کا مطلب ہے کہ اس ٹرن کے لیے 40,000 ٹوکنز کی حد ہے۔

ٹاسک بجٹ ایک مشاورتی حد ہے۔ 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 کو کم کرتا ہے، تو تبدیل شدہ ویلیو اس میں موجود کسی بھی cached prefix کو غلط قرار دے دیتی ہے۔ اسے صرف ایک بار، پہلی درخواست پر سیٹ کریں۔

ٹاسک بجٹ Claude Fable 5، Claude Opus 4.8 اور Claude Opus 4.7 پر بیٹا میں دستیاب ہیں۔ Claude Sonnet 5 اور Claude Haiku 4.5 کو Not supported کے طور پر درج کیا گیا ہے، اور ٹاسک بجٹ Claude Code پر لاگو نہیں ہوتے، لہذا ایک Claude Code session detached in tmux کا انحصار سیشن کی صفائی پر ہوتا ہے۔

تیسری حد Claude Console میں موجود ہے: ایجنٹ کو اس کا اپنا ورک اسپیس دیں، پھر اس پر ماہانہ خرچ کی حد اور فی منٹ ریٹ کی حدود سیٹ کریں۔ "آپ Default Workspace پر حدود سیٹ نہیں کر سکتے"، اور "تنظیم کی سطح پر عائد حدود ہمیشہ لاگو رہتی ہیں، چاہے ورک اسپیس کی حدود کا مجموعہ اس سے زیادہ ہی کیوں نہ ہو"۔ خرچ کے نوٹیفکیشنز شامل کریں تاکہ حد تک پہنچنے سے پہلے ہی آپ کو الرٹ مل جائے۔

فی جاب ماڈل کا انتخاب، اور اصل کوشش میں تبدیلی

ماڈل کا انتخاب ہر جاب کے لیے الگ فیصلہ ہوتا ہے۔ جولائی 2026 تک، فی ملین ٹوکنز، ان پٹ اور پھر آؤٹ پٹ کی قیمتیں یہ ہیں: Claude Fable 5 کے لیے $10 اور $50، Claude Opus 4.8 اور Opus 4.7 کے لیے $5 اور $25، Claude Sonnet 5 کے لیے $3 اور $15، اور Claude Haiku 4.5 کے لیے $1 اور $5۔ Sonnet 5 فی الحال اپنی درج شدہ قیمت سے کم پر دستیاب ہے، کیونکہ "31 اگست 2026 تک $2/$10 فی ملین ان پٹ/آؤٹ پٹ ٹوکنز کی تعارفی قیمت نافذ ہے"۔ ایسا مرحلہ جو صرف لاگ لائنز کی درجہ بندی کرتا ہے اسے Opus کی ضرورت نہیں ہوتی۔ مصروف شیڈول کو سنبھالنے کے لیے کوئی مفت الاؤنس بھی نہیں ہے، کیونکہ Claude API کا کوئی مفت ٹائر نہیں ہے، سوائے سائن اپ پر ملنے والے چھوٹے کریڈٹ کے۔

کوشش (effort) دوسرا اہم عنصر ہے۔ output_config.effort میں low، medium، high، xhigh اور max قبول کیے جاتے ہیں، اور ڈیفالٹ high ہے، لہذا high کو واضح طور پر سیٹ کرنا اسے چھوڑ دینے کے مترادف ہے۔ کم کوشش صرف استدلال کی لمبائی کو ہی کم نہیں کرتی: دستاویزات کے مطابق اس سے Claude کم ٹول کالز کرتا ہے اور آپریشنز کو ایک میں ضم کر دیتا ہے۔ ایک ایجنٹ پر یہ بڑی بچت ہے، کیونکہ ایک ٹول کال سے بچنا دراصل ایک پوری درخواست سے بچنا ہے جو کبھی ہوتی ہی نہیں۔

اس میں خطرہ یہ ہے کہ کوشش کا پیرامیٹر کیشے (cache) کے ساتھ ٹکراؤ پیدا کرتا ہے۔ درخواستوں کے درمیان اس کی ویلیو تبدیل کرنے سے پرامپٹ کیشنگ (prompt caching) غیر مؤثر ہو جاتی ہے۔ دستاویزی مثال میں، دوسری درخواست نے cache_read_input_tokens: 3546 رپورٹ کیا؛ تیسری درخواست میں، جب کوشش کو ہائی سے میڈیم کیا گیا، تو cache_creation_input_tokens کی تعداد 3546 اور cache_read_input_tokens کی تعداد 0 رپورٹ ہوئی۔ لہذا کوشش کو ورک لوڈز کے درمیان تبدیل کریں، کبھی بھی ایک کیش شدہ گفتگو کے اندر نہیں۔ کیشے کو توڑے بغیر گہرائی کو کنٹرول کرنے کے لیے، اسے پرامپٹ میں تبدیل کریں: تازہ ترین صارف پیغام پر "بغیر سوچے براہ راست جواب دیں" جیسی لائن لکھنے سے پہلے کے بریک پوائنٹس برقرار رہتے ہیں۔

سوچنے والے ٹوکنز (thinking tokens) آؤٹ پٹ ریٹس پر بل کیے جاتے ہیں اور max_tokens کے خلاف شمار ہوتے ہیں، یہی وجہ ہے کہ نامکمل جواب کا اکثر مطلب یہ ہوتا ہے کہ سوچنے کے عمل نے بجٹ ختم کر دیا ہے۔ تعداد کے لیے usage.output_tokens_details.thinking_tokens پڑھیں۔ Claude ٹوکن بل میں اصل میں کیا شامل ہوتا ہے اس میٹر کی تفصیلات بیان کرتا ہے۔

مستقل پریفکس کو کیش کریں، اور اسے حادثاتی طور پر خراب کرنا بند کریں

کیش میں لکھنا (write) پانچ منٹ والے کیش پر بنیادی ان پٹ قیمت کا 1.25 گنا اور ایک گھنٹے والے کیش پر 2 گنا خرچ ہوتا ہے۔ کیش سے پڑھنا (read) 0.1 گنا خرچ ہوتا ہے، لہذا "کیشنگ 5 منٹ کے دورانیے (1.25x رائٹ) کے لیے صرف ایک بار پڑھنے کے بعد، یا 1 گھنٹے کے دورانیے (2x رائٹ) کے لیے دو بار پڑھنے کے بعد فائدہ مند ثابت ہوتی ہے"۔

ایک جملہ وضاحت کرتا ہے کہ یہ ہمیشہ آن رہنے والے ایجنٹ کے لیے کیوں موزوں ہے: "ہر بار جب کیش شدہ مواد استعمال ہوتا ہے تو کیش بغیر کسی اضافی قیمت کے ریفریش ہو جاتی ہے۔" ہر دو منٹ بعد چلنے والا جاب پانچ منٹ والے کیش کے خلاف اپنے پریفکس کو ایک بار لکھنے سے سارا دن گرم (warm) رکھتا ہے۔

کیش کو بغیر جانے کھونے کے تین طریقے۔

ایک پریفکس جو تبدیل ہوتا ہے۔ "کیش پریفکس درج ذیل ترتیب میں بنائے جاتے ہیں: tools، system، پھر messages۔" اس ترتیب میں پہلے آنے والی کسی بھی بائٹ کی تبدیلی اس کے بعد کی ہر چیز کو غلط (invalidate) کر دیتی ہے، اور ٹول کی تعریفوں میں ترمیم کرنے سے پوری کیش غلط ہو جاتی ہے۔ خود کو پہنچایا جانے والا کلاسک نقصان سسٹم پرامپٹ میں ٹائم اسٹیمپ یا رن آئی ڈی کا ہونا ہے: ہر درخواست پھر ایک مختلف پریفکس لے کر چلتی ہے، 1.25x پر ایک نئی انٹری لکھتی ہے، اور کچھ بھی واپس نہیں پڑھتی۔ اس کی نشانی یکساں نظر آنے والی کالز پر usage.cache_read_input_tokens کا 0 ہونا ہے۔ غیر مستحکم ٹیکسٹ کو تازہ ترین یوزر میسج میں منتقل کریں۔

ایک پریفکس جو بہت چھوٹا ہے۔ ہر ماڈل کی ایک کم از کم کیش ایبل لمبائی ہوتی ہے، اور اس سے نیچے درخواست بغیر کیشنگ کے پروسیس ہوتی ہے اور "کوئی ایرر واپس نہیں آتا"۔ اعداد و شمار میں Claude Opus 4.8 اور Claude Sonnet 5 پر 1,024 ٹوکنز، اور Claude Haiku 4.5 پر 4,096 ٹوکنز شامل ہیں، لہذا جاب کو Sonnet سے Haiku پر منتقل کرنے سے کیشنگ خاموشی سے بند ہو سکتی ہے۔

ایک گفتگو جو لک بیک (lookback) سے باہر نکل جاتی ہے۔ "لک بیک ونڈو 20 بلاکس کی ہے۔" سسٹم ہر بریک پوائنٹ پر زیادہ سے زیادہ 20 پوزیشنز چیک کرتا ہے، پھر رک جاتا ہے۔ دستاویزی مثال میں، 35 بلاکس پر مشتمل ایک ٹرن جس میں بلاک 35 پر بریک پوائنٹ ہو، بلاک 35 سے 16 تک چیک کرتا ہے، اور پچھلے ٹرن کی بلاک 15 پر موجود انٹری ونڈو سے باہر ہو جاتی ہے، لہذا کوئی ہٹ (hit) نہیں ہوتی۔ ایک ایجنٹ جو فی ٹرن کئی ٹول-یوز اور ٹول-رزلٹ بلاکس شامل کرتا ہے، دو یا تین ٹرنز میں 20 کی حد پار کر لیتا ہے۔ آپ کو فی درخواست چار بریک پوائنٹس ملتے ہیں، لہذا ایک حالیہ پیغامات پر خرچ کریں۔

جو کام فوری نہیں ہیں انہیں Batches API پر بھیجیں

تمام استعمال پر معیاری API قیمتوں کا 50 فیصد چارج کیا جاتا ہے، یہ ان پٹ اور آؤٹ پٹ دونوں پر لاگو ہوتا ہے۔ Batch پروسیسنگ غیر مطابقت پذیر (asynchronous) ہوتی ہے، "زیادہ تر بیچز 1 گھنٹے سے کم وقت میں مکمل ہو جاتے ہیں"، اور نتائج تب ملتے ہیں جب ہر درخواست مکمل ہو جائے یا 24 گھنٹے گزر جائیں، جو بھی پہلے ہو۔ یہ ایک عام صورتحال ہے، اس کی ضمانت نہیں ہے۔

processing_status کو تب تک پول (poll) کریں جب تک وہ ended نہ پڑھ لے۔ errored، canceled یا expired واپس کرنے والی درخواستوں کا بل نہیں بنایا جاتا۔ اگر آپ اخراجات کی حد (spend cap) پر انحصار کرتے ہیں تو ایک انتباہ یہ ہے: "بیچز آپ کے ورک اسپیس کی مقرر کردہ اخراجات کی حد سے تھوڑا تجاوز کر سکتے ہیں۔"

ڈسکاؤنٹس جمع ہوتے ہیں، اور چونکہ ایک بیچ پانچ منٹ سے زیادہ وقت لے سکتا ہے، اس لیے دستاویزات سیاق و سباق (context) شیئر کرنے والے بیچز کے لیے ایک گھنٹے کی کیش (cache) استعمال کرنے کی تجویز دیتی ہیں۔ لہذا کام کو تقسیم کریں: جس چیز کا انتظار کوئی شخص یا webhook کر رہا ہو اسے لائیو پاتھ پر رکھیں، اور رات کا خلاصہ (nightly digest) یا گزشتہ روز کے لاگز کی درجہ بندی کو آدھی قیمت پر بیچ میں ڈال دیں۔

ہر رسپانس کے استعمال کے فیلڈز کو اپنے اسٹور میں لاگ کریں

آپ اس اخراجات کا حساب نہیں لگا سکتے جنہیں آپ نے ریکارڈ ہی نہیں کیا۔ ہر رسپانس آپ کو بتاتا ہے کہ اس کی قیمت کیا ہے۔

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 فائل میں شامل کریں، جس پر آپ کے جاب کا نام ٹیگ ہو۔ ایک ہفتے بعد آپ بتا سکیں گے کہ کون سا جاب خرچ کر رہا ہے اور کون سا صرف مصروف دکھائی دے رہا ہے۔ cache_read پر نظر رکھیں: سیلف ہوسٹڈ ایجنٹ میں صفر (zeros) کا کالم اخراجات کی سب سے عام غلطی ہے۔

ایک فیلڈ کو غلط سمجھنا آسان ہے۔ input_tokens صرف آخری کیش بریک پوائنٹ کے بعد کے ٹوکنز کو گنتا ہے، لہذا اصل پرامپٹ کا سائز total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens ہے۔ ایک ایجنٹ جو بڑے پرامپٹ پر input_tokens: 400 رپورٹ کر رہا ہے وہ سستا نہیں ہے: باقی حصہ کیش سے آیا ہے۔

بھیجنے سے پہلے گنتی کریں۔ ٹوکن گننا مفت ہے اور اس کی ریٹ لمٹس میسج بنانے سے الگ ہیں، لہذا count_tokens کا استعمال کریں تاکہ بہت بڑی فائل بھیجنے کے بجائے اسے پہلے ہی مسترد کر دیں اور ادائیگی سے بچ سکیں۔ نتیجہ ایک تخمینہ ہوتا ہے، لہذا ہر ماڈل کے لیے دوبارہ پیمائش کریں اور کبھی بھی کسی دوسرے وینڈر کے ٹوکنائزر کی گنتی دوبارہ استعمال نہ کریں۔ Claude Opus 4.7 اور اس کے بعد کے Opus ماڈلز، Claude Fable 5 اور Claude Sonnet 5 ایک نیا ٹوکنائزر استعمال کرتے ہیں جو "ایک ہی متن کے لیے تقریباً 30 فیصد زیادہ ٹوکنز پیدا کرتا ہے"۔ Claude Sonnet 4.6 اور اس سے پرانے ماڈلز، جن میں Claude Haiku 4.5 شامل ہے، پچھلا والا استعمال کرتے ہیں۔

مستند معلومات کے لیے، Admin API استعمال کی رپورٹ 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[]= کو قبول کرتے ہیں۔ ایک حد یہ ہے: "Admin API انفرادی اکاؤنٹس کے لیے دستیاب نہیں ہے۔"

آخری پیرامیٹر اخراجات کی تقسیم کا ایک سستا طریقہ ہے: ہر جاب کو اپنی API کی دیں، api_key_ids[] کے ساتھ فلٹر کریں، اور رپورٹ کو group_by[]=api_key_id کے ذریعے کی کے مطابق الگ کریں۔ فلٹر جمع (plural) ہے، جبکہ گروپنگ ڈائمینشن واحد (singular) ہے۔ کیز کو کوڈ کے بجائے انوائرمنٹ میں رکھیں، جس طرح VPS پر پہلی Claude API ایپ انہیں ہینڈل کرتی ہے۔

لوپ کو محدود کریں، کیونکہ کوئی اور چیز ایسا نہیں کرے گی

یہاں محدود تکرار (iteration count) کا ہونا اختیاری نہیں ہے۔ لوپ آپ کا ہے، لہذا کاؤنٹر بھی آپ کا ہی ہونا چاہیے:

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's cap on tool calls within a single turn ایک ایسے سیشن کو روک دیتا ہے جس میں بہت زیادہ کالز کی گئی ہوں، لیکن آپ کا لکھا ہوا لوپ اس وقت تک کسی ایسے بیک اسٹاپ کے بغیر کام کرتا ہے جب تک آپ خود اسے شامل نہ کریں۔

عمل کے باہر ایک دوسرا بریک لگائیں۔ جاب کو مستقل پروسیس کے بجائے systemd timer سے چلائیں، اور اس کی سروس یونٹ پر RuntimeMaxSec= سیٹ کریں۔ RuntimeMaxSec=600 کے ساتھ، ایک پھنسا ہوا رن دس منٹ بعد ختم کر دیا جاتا ہے بجائے اس کے کہ وہ تب تک چلتا رہے جب تک آپ کو اس کا علم نہ ہو۔ Running a program as a systemd service and timer میں یونٹ فائلز کے بارے میں تفصیل موجود ہے۔ journalctl -u triage-agent.service --since "1 hour ago" کے ذریعے دیکھیں کہ رن نے کیا کام کیا ہے۔

دوبارہ کوششوں (retries) کو بھی محدود کریں، کیونکہ جو ہینڈلر ہمیشہ دوبارہ کوشش کرتا ہے وہ ہر کوشش کا بل بناتا ہے۔ 429 یا 500 ایرر کوڈز کے لیے بیک آف (backoff) کے ساتھ چند کوششیں مناسب ہیں۔ 400 ایرر کوڈ کے لیے کوئی کوشش نہیں کرنی چاہیے، کیونکہ وہی درخواست ہر بار اسی طرح ناکام ہوگی۔

AI ایجنٹ کے اخراجات پر قابو پانے کا آغاز اپنے اعداد و شمار کو پڑھنے سے ہوتا ہے

کوئی بھی آپ کو یہ نہیں بتا سکتا کہ ایک ہمہ وقت چلنے والے (always-on) ایجنٹ کی قیمت کیا ہے، کیونکہ لاگت کا انحصار فی رن ٹوکنز (tokens per run) کو یومیہ رن کی تعداد سے ضرب دینے پر ہے، اور یہ دونوں عوامل آپ کے اپنے ہیں۔ اسے ایک بار چلائیں، اپنے لاگ کردہ usage row کو پڑھیں، اور اسے اپنے شیڈول کے مطابق ضرب دیں۔ دو دن بعد لاگت کی رپورٹ کا اس حساب کتاب سے موازنہ کریں۔ جب یہ دونوں آپس میں نہ ملیں، تو اس کا مطلب تقریباً ہمیشہ ایک ٹوٹا ہوا کیش (broken cache) یا کوئی ایسا لوپ ہے جو آپ کے اندازے سے زیادہ دیر تک چلا۔

یہ مفروضہ ایک API key پر مبنی ہے، کیونکہ ایجنٹ آپ کا اپنا پروگرام ہے جو Messages API کو کال کر رہا ہے۔ اپنے ذاتی انٹرایکٹو کام کے لیے، کون سا Claude پلان آپ کے کام کے انداز کے مطابق ہے سبسکرپشن کے پہلو کا احاطہ کرتا ہے۔ یہاں دی گئی ہر قیمت اور حد کو جولائی 2026 میں Anthropic کی دستاویزات کے مطابق چیک کیا گیا تھا، لہذا بجٹ بنانے سے پہلے پرائسنگ پیج کو دوبارہ پڑھ لیں۔

FAQ

VPS پر ہر وقت چلنے والے AI ایجنٹ کو چلانے پر کتنا خرچ آتا ہے؟

اس کے دو بل ہوتے ہیں اور صرف ایک کی پیش گوئی کی جا سکتی ہے۔ سرور کی قیمت ماہانہ مقرر ہوتی ہے۔ ماڈل API کا بل ٹوکنز کے حساب سے ہوتا ہے، لہذا کل خرچ ایک رن کی کھپت کو اس کے چلنے کی تعداد سے ضرب دے کر نکلتا ہے۔ Anthropic خود سے ہوسٹ کیے گئے ہر وقت چلنے والے ایجنٹ کے لیے کوئی مخصوص قیمت نہیں بتاتا، لہذا کسی بھی بتائی گئی قیمت کو صرف ایک اندازہ سمجھیں۔ ایک حقیقی رن سے usage لاگ لیں اور اسے اپنے شیڈول کے مطابق ضرب دیں۔

max_tokens اور ٹاسک بجٹ میں کیا فرق ہے؟

max_tokens کو نافذ کیا جاتا ہے اور یہ ماڈل کے لیے غیر مرئی ہوتا ہے۔ یہ ایک درخواست کی آؤٹ پٹ کو محدود کرتا ہے (جس میں سوچنے کا عمل بھی شامل ہے)، اور اس حد تک پہنچنے پر stop_reason: "max_tokens" کا سامنا ہوتا ہے۔ ٹاسک بجٹ اس کے برعکس ہے: ماڈل کو یہ نمبر بتا دیا جاتا ہے اور وہ ایجنٹک لوپ کو اس کے مطابق ترتیب دیتا ہے، لیکن "ٹاسک بجٹ ایک نرم اشارہ ہے، سخت حد نہیں" اور نافذ شدہ حد اب بھی max_tokens ہی رہتی ہے۔

میرے ایجنٹ کے لیے cache_read_input_tokens ہمیشہ صفر کیوں ہوتے ہیں؟

اس کی وجہ یہ ہے کہ کالز کے درمیان پریفکس (prefix) تبدیل ہو جاتا ہے، یا یہ کیش کرنے کے لیے بہت چھوٹا ہوتا ہے۔ عام وجہ سسٹم پرامپٹ میں شامل ٹائم اسٹیمپ یا رن آئی ڈی ہے: کیش پریفکس کی بنیاد پر کام کرتا ہے، لہذا کسی بھی بائٹ کی تبدیلی اس کے بعد کی ہر چیز کو غیر مؤثر کر دیتی ہے۔ ٹول کی تعریفیں یا effort کی ویلیو تبدیل کرنے سے بھی یہی ہوتا ہے۔ اس کے علاوہ وجہ سائز بھی ہو سکتی ہے، کیونکہ چھوٹے پرامپٹس کیش نہیں کیے جاتے اور اس پر کوئی ایرر بھی نہیں دیا جاتا۔

میں AI ایجنٹ کو ہمیشہ کے لیے لوپ میں پھنسنے سے کیسے روکوں؟

اپنے لوپ کوڈ میں تکرار (iterations) کو گنیں اور ایک مقررہ حد پر اسے روک دیں، کیونکہ max_tokens صرف ایک رسپانس کو محدود کرتا ہے جبکہ ایجنٹ بہت سے رسپانس بناتا ہے۔ پروسیس کے باہر ایک وال کلاک لمٹ شامل کریں: جاب کو systemd ٹائمر سے شروع کریں جس میں RuntimeMaxSec= سیٹ ہو، تاکہ پھنس جانے والا رن شیڈول کے مطابق ختم ہو جائے۔ دوبارہ کوششوں (retries) کو بھی محدود کریں، کیونکہ ری ٹرائی لوپ ہر کوشش کا بل بناتا ہے۔

کیا میں ایک ہی Claude API کی (key) پر خرچ کی حد مقرر کر سکتا ہوں؟

دستاویزی خرچ کی حد فی ورک اسپیس ہوتی ہے نہ کہ فی کی، لہذا ایجنٹ کو اس کی اپنی الگ ورک اسپیس دیں اور وہاں اس کا ماہانہ خرچ محدود کریں۔ "آپ ڈیفالٹ ورک اسپیس پر حد مقرر نہیں کر سکتے"۔ خرچ کے نوٹیفکیشن شامل کریں تاکہ ایک حد تک پہنچنے پر آپ کو پہلے الرٹ مل جائے۔ انتساب (attribution) کے لیے، ہر جاب کو اپنی الگ کی (key) جاری کریں، پھر استعمال کی رپورٹ کو group_by[]=api_key_id کے ساتھ گروپ کریں۔