AI agent کے اخراجات کو کیسے کنٹرول کریں

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

VPS (virtual private server) پر AI agent کے اخراجات کو کنٹرول کرنے کا مطلب وہ حدیں (ceilings) مقرر کرنا ہے جو آپ agent کے شروع ہونے سے پہلے سیٹ کرتے ہیں۔ اس کی وجہ یہ ہے کہ agent کے چلنے کے دوران کوئی بھی میٹر (meter) کی نگرانی نہیں کرتا۔ ہر response کو max_tokens کے ساتھ محدود کریں، اپنے کوڈ میں loop iterations کی حد مقرر کریں، prompt کے اس حصے کو cache کریں جو کبھی تبدیل نہیں ہوتا، اور ہر response کے usage numbers کو log کریں تاکہ معلوم ہو سکے کہ کون سا job زیادہ خرچ کر رہا ہے۔ server rental کی ماہانہ قیمت مقرر ہوتی ہے۔ Model API کا چارج ہر token کے حساب سے ہوتا ہے، اور ایک unattended loop خاموشی سے بہت زیادہ tokens खर्च کر سکتا ہے۔

یہ فرض کرتا ہے کہ AI agent پہلے سے موجود ہے اور آپ کے اپنے server سے Messages API کو call کرتا ہے۔ VPS پر Claude کے ساتھ AI agent بنانا اس کے میکانزم کے بارے میں تفصیل فراہم کرتا ہے۔

Unattended agent کی لاگت کا ڈھانچہ مختلف کیوں ہے

Interactive session میں انسان شامل ہوتا ہے۔ جب model غلط سمت میں چلا جائے یا 40,000 لائنوں والا log پڑھے، تو دیکھنے والا اسے روک دیتا ہے۔ Unattended agent میں ایسا کوئی کنٹرول نہیں ہوتا: یہ loop ختم ہونے تک چلتا رہتا ہے، اور پھر timer اسے دوبارہ شروع کر دیتا ہے۔

Frequency وہ multiplier ہے جسے لوگ نظر انداز کر دیتے ہیں۔ اگر کوئی job ہر 5 منٹ بعد چلے، تو وہ دن میں 288 بار اور مہینے میں تقریباً 8,640 بار چلتی ہے۔ ایک بار کے چلنے کی لاگت کو اس تعداد سے ضرب دیں۔ بہت سے "always-on" agents کو ہر وقت آن رہنے کی ضرورت نہیں ہوتی۔ انہیں صرف مخصوص منٹوں کے اندر جواب دینا ہوتا ہے، جو کہ ایک schedule ہے۔

Agent ان چیزوں کے لیے بھی ادائیگی کرتا ہے جو chat window میں نہیں ہوتیں۔

• Tool definitions ہر request کے ساتھ شامل ہوتے ہیں۔ Claude Opus 4.8 پر tool-use system prompt کی لاگت tool_choice of auto یا none کے ساتھ 290 tokens ہے، اور any یا tool کے ساتھ 410 ہے۔ Bash tool مزید 325 tokens کا اضافہ کرتا ہے۔ ہر MCP server jo aap attach karte hain اس وزن میں اپنے schemas شامل کرتا ہے، کیونکہ MCP کا مطلب model context protocol ہے۔
• Tool results input tokens ہوتے ہیں۔ ایک command جو 8,000 لائنیں پرنٹ کرتی ہے، وہ اگلی request میں اور اس turn کی تمام اگلی requests میں 8,000 لائنیں شامل کر دیتی ہے۔
• Fetched pages input tokens ہوتے ہیں۔ ایک اوسط 10 kB ویب پیج تقریباً 2,500 tokens کا ہوتا ہے اور 500 kB ریسرچ PDF تقریباً 125,000 tokens کی ہوتی ہے۔ max_content_tokens صرف text والی فائلوں کو truncate کرتا ہے، کیونکہ یہ "text content par apply hota hai, binary content jaise ke PDFs par nahi"۔ PDF کے لیے max_uses اور allowed_domains کا استعمال کریں۔
• Web search کی قیمت فی search ہے، جو کہ $10 per 1,000 searches ہے، چاہے کتنے بھی results मिलیں۔ Error آنے والی search کا کوئی چارج نہیں لیا جاتا۔

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

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

max_tokens نافذ کیا جاتا ہے۔ یہ ایک request کے کل output (سوچنے اور جواب دینے والے متن سمیت) پر ایک hard cap ہے۔ Claude اس سے آگے کبھی متن تیار نہیں کرتا، اور ماڈل اس نمبر کو نہیں دیکھ سکتا۔ اس حد تک پہنچنے سے stop_reason: "max_tokens" ہوتا ہے اور جواب ادھورا (truncated) رہ جاتا ہے۔ agents کے لیے اہم بات: tool-use loop میں ہر request کا اپنا max_tokens ہوتا ہے، اس لیے یہ صرف ایک response کو محدود کرتا ہے، پورے task کو نہیں۔ اگر 10 tool calls 4,000 tokens پر ہوں، تو اس turn کے لیے 40,000-token کی ceiling ہوگی۔

Task budget صرف مشاورتی ہے۔ task_budget، output_config کے اندر ہوتا ہے اور ماڈل کو بتاتا ہے کہ پورے agentic loop کے لیے اس کے پاس کتنے tokens ہیں، جس میں thinking، tool calls، tool results اور output شامل ہیں۔

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,
)

"Task budgets ایک soft hint ہے، hard cap نہیں۔" Claude کسی ایک action کے دوران حد سے تجاوز کر سکتا ہے، اور output پر نافذ کردہ limit اب بھی max_tokens ہی رہے گی۔ "Countdown صرف ماڈل کو نظر آتا ہے"، اور responses میں remaining-budget کا کوئی field نہیں ہوتا۔ کم از کم قابل قبول task_budget.total 20,000 tokens ہے، اور اس سے کم ہونے پر 400 error آتا ہے۔ کام کے لیے بہت چھوٹا budget ہونے کی صورت میں ماڈل انکار (refusal) جیسا رویہ اختیار کرتا ہے، چنانچہ ماڈل task کو چھوٹا کر دیتا ہے یا جلد ہی رک جاتا ہے۔

ایک تفصیل پیسے بچانے کے بجائے خرچ کرتی ہے۔ اگر آپ کا client ہر follow-up request پر task_budget.remaining کو کم کرتا ہے، تو بدلا ہوا value اس cached prefix کو invalid کر دے گا جس میں وہ شامل ہے۔ اسے صرف پہلی request پر ایک بار سیٹ کریں۔

Claude Fable 5، Claude Opus 4.8 اور Claude Opus 4.7 پر task budgets beta میں ہیں۔ Claude Sonnet 5 اور Claude Haiku 4.5 کو Not supported کے طور پر सूचीबद्ध کیا گیا ہے، اور task budgets Claude Code پر لاگو نہیں ہوتے، اس لیے tmux میں detached Claude Code session کا انحصار session hygiene پر ہوتا ہے۔

تیسری ceiling Claude Console میں ہوتی ہے: agent کو اس کا اپنا workspace دیں، پھر اس پر monthly spend limit اور per-minute rate limits سیٹ کریں۔ "آپ Default Workspace پر limits سیٹ نہیں کر سکتے"، اور "Organization-wide limits ہمیشہ لاگو ہوتی ہیں، چاہے workspace limits کا مجموعہ ان سے زیادہ ہی کیوں نہ ہو"۔ Spend notifications شامل کریں تاکہ cap تک پہنچنے سے پہلے threshold آپ کو مطلع کر دے۔

ہر جاب کے لیے ماڈل کا انتخاب، اور اصل میں کن عوامل سے فرق پڑتا ہے

ماڈل کا انتخاب ہر جاب کے لیے ایک الگ فیصلہ ہوتا ہے۔ جولائی 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 کی قیمت فی الحال اس کے اصل ریٹ سے کم ہے، کیونکہ "Introductory pricing of $2/$10 per million input/output tokens is in effect through August 31, 2026" ہے۔ اگر کوئی مرحلہ صرف log lines کو classify کرتا ہے، تو اسے Opus کی ضرورت نہیں ہے۔

Effort دوسرا اہم عامل ہے۔ output_config.effort، low، medium، high، xhigh اور max کو قبول کرتا ہے، اور اس کی default value high ہے، اس لیے high کو واضح طور پر سیٹ کرنا اسے چھوڑنے کے برابر ہے۔ کم effort سے صرف reasoning کی لمبائی ہی کم نہیں ہوتی، بلکہ اس سے زیادہ فرق پڑتا ہے: documentation کے مطابق یہ Claude کو کم tool calls کرنے اور آپریشنز کو ایک میں ضم کرنے پر مجبور کرتا ہے۔ Agent کے معاملے میں یہ زیادہ بچت فراہم کرتا ہے، کیونکہ ایک tool call کو بچانا ایک مکمل request کو روکنے کے برابر ہے جو کبھی نہیں ہوتی۔

خطرہ یہ ہے کہ effort کا استعمال cache کے خلاف کام کرتا ہے۔ requests کے درمیان value تبدیل کرنے سے prompt caching ختم ہو جاتی ہے۔ documented مثال میں، request 2 نے cache_read_input_tokens: 3546 رپورٹ کیا؛ request 3 میں، جب effort کو high سے medium پر تبدیل کیا گیا، تو اس نے 3546 کا cache_creation_input_tokens اور 0 کا cache_read_input_tokens رپورٹ کیا۔ اس لیے workloads کے درمیان effort کو تبدیل کریں، ایک ہی cached conversation کے اندر کبھی نہ کریں۔ Cache کو توڑے بغیر गहराई (depth) کو کنٹرول کرنے کے لیے، اسے prompt میں لکھیں: تازہ ترین user message پر "Answer directly without deliberating" جیسی لائن لکھنے سے پچھلے breakpoints برقرار رہتے ہیں۔

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

Stable prefix ko cache karein, aur ghalti se isay kharab hone se bachayein

Five-minute cache par cache write ki cost base input price se 1.25 guna hai, aur one-hour cache par 2 guna hai. Cache read ki cost 0.1 hai, is liye "5-minute duration ke liye sirf ek cache read ke baad caching faide mand sabit hoti hai (1.25x write), ya 1-hour duration ke liye do cache reads ke baad (2x write)".

Ek line is ki wajah batati hai ke ye always-on agent ke liye kyun behtar hai: "Jab bhi cached content istemal hota hai, cache bina kisi izafi cost ke refresh ho jata hai." Agar koi job har 2 minute baad five-minute cache ke liye chalti hai, to wo poora din sirf ek write ke sath apne prefix ko warm rakhti hai.

Cache ko baghair maloom hue khone ke teen tareeqay.

A prefix that changes. "Cache prefixes is tarteeb se bante hain: tools, system, phir messages." Is tarteeb mein pehle aane wala koi bhi byte change us ke baad ki tamam cheezon ko invalid kar deta hai, aur tool definitions ko edit karne se poora cache invalid ho jata hai. Sab se aam ghalti system prompt mein timestamp ya run id ka istemal hai: is se har request ka prefix mukhtalif ho jata hai, 1.25x par naya entry likha jata hai, aur kuch bhi read nahi hota. Is ki nishani identical-looking calls par usage.cache_read_input_tokens ka 0 hona hai. Volatile text ko sab se naye user message mein move karein.

A prefix that is too short. Har model ki cacheable length ki ek minimum had hoti hai, aur us se kam hone par request caching ke baghair process hoti hai aur "no error is returned". In figures mein Claude Opus 4.8 aur Claude Sonnet 5 ke liye 1,024 tokens, aur Claude Haiku 4.5 ke liye 4,096 tokens shamil hain, is liye job ko Sonnet se Haiku par move karne se caching khamoshi se band ho sakti hai.

A conversation that outgrows the lookback. "Lookback window 20 blocks hai." System har breakpoint par zyada se zyada 20 positions check karta hai, phir ruk jata hai. Documented example mein, 35 blocks wala turn jis ka breakpoint block 35 par hai, wo block 35 se 16 tak check karta hai, aur pichle turn ki block 15 wali entry window se bahar hoti hai, is liye koi hit nahi milta. Agar koi agent har turn mein kai tool-use aur tool-result blocks append karta hai, to wo do ya teen turns mein 20 se upar nikal jata hai. Aap ko har request ke liye char breakpoints milte hain, is liye ek breakpoint halia messages ke liye istemal karein.

وہ تمام کام Batches API کو بھیجیں جن میں تاخیر کی جا سکتی ہے

ان پٹ اور آؤٹ پٹ دونوں پر "تمام استعمال کے چارجز standard API قیمتوں کے 50%" ہوں گے۔ Batch processing asynchronous ہے، "زیادہ تر batches 1 گھنٹے سے کم وقت میں مکمل ہو جاتے ہیں"۔ نتائج تب دستیاب ہوں گے جب تمام requests مکمل ہو جائیں گی یا 24 گھنٹوں کے بعد، ان میں سے جو بھی پہلے ہو۔ یہ ایک عام صورتحال ہے، کوئی گارنٹی نہیں۔

processing_status کو تب تک poll کریں جب تک وہ ended نہ ہو جائے۔ وہ requests جو errored, canceled یا expired واپس کریں گی، ان کے چارجز نہیں لیے جائیں گے۔ اگر آپ نے spend cap کا استعمال کیا ہے تو ایک احتیاط: "batches آپ کے Workspace کی configured spend limit سے تھوڑا اوپر جا سکتے ہیں۔"

Discounts کا فائدہ ملتا ہے، اور چونکہ ایک batch کو پانچ منٹ سے زیادہ وقت لگ سکتا ہے، اس لیے documentation ایک گھنٹے کے cache کا مشورہ دیتی ہے جو ایک ہی context استعمال کرنے والے batches کے لیے مفید ہے۔ اس لیے کام کو تقسیم کریں: وہ تمام کام جس کا انسان یا webhook انتظار کر رہا ہے اسے live path پر رکھیں، جبکہ nightly digest یا گزشتہ دن کے log classification کو آدھی قیمت پر batch میں بھیج دیں۔

ہر response کے usage fields کو اپنے store میں log کریں

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

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 call کے لیے JSON-lines فائل میں ایک row شامل کریں، اور اسے اپنے job name کے ساتھ tag کریں۔ ایک ہفتے بعد آپ بتا سکیں گے کہ کس job پر کتنا خرچ ہوا اور کون سی job صرف مصروف نظر آتی تھی۔ cache_read پر نظر رکھیں: self-hosted agent میں zeros کا column سب سے عام cost bug ہے۔

ایک field کو پڑھنے میں غلطی ہو سکتی ہے۔ input_tokens صرف آخری cache breakpoint کے بعد کے tokens گنتا ہے، اس لیے اصل prompt size total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens ہے۔ اگر کوئی agent بڑے prompt پر input_tokens: 400 رپورٹ کرتا ہے تو وہ سستا نہیں ہے: باقی tokens cache سے آئے تھے۔

بھیجنے سے پہلے count کریں۔ Token counting مفت ہے اور اس کی rate limits message creation سے الگ ہوتی ہیں، اس لیے oversized attachment کے لیے ادائیگی کرنے کے بجائے اسے مسترد کرنے کے لیے count_tokens استعمال کریں۔ یہ نتیجہ ایک estimate ہے، اس لیے ہر model کے لیے دوبارہ پیمائش کریں اور کسی دوسرے vendor کے tokenizer کا count دوبارہ استعمال نہ کریں۔ Claude Opus 4.7 اور بعد کے Opus models، Claude Fable 5 اور Claude Sonnet 5 ایک نیا tokenizer استعمال کرتے ہیں جو "اسی text کے لیے تقریباً 30% زیادہ tokens produce کرتا ہے"۔ Claude Sonnet 4.6 اور اس سے پرانے، بشمول Claude Haiku 4.5، پچھلا tokenizer استعمال کرتے ہیں۔

حتمی معلومات کے لیے، Admin API usage کو https://api.anthropic.com/v1/organizations/usage_report/messages اور cost کو https://api.anthropic.com/v1/organizations/cost_report پر رپورٹ کرتا ہے۔ دونوں کے لیے admin key (sk-ant-admin01-...) کو x-api-key: $ANTHROPIC_ADMIN_KEY کے طور پر anthropic-version: 2023-06-01 کے ساتھ استعمال کیا جاتا ہے، اور یہ bucket_width=1d، group_by[]=model اور api_key_ids[]= کو قبول کرتے ہیں۔ ایک حد: "The Admin API is unavailable for individual accounts."

یہ آخری parameter attribution کا ایک سستا طریقہ ہے: ہر job کو اپنی الگ API key دیں، api_key_ids[] کے ساتھ filter کریں، اور group_by[]=api_key_id کے ساتھ key کے مطابق report کو تقسیم کریں۔ filter plural ہے، جبکہ grouping dimension singular ہے۔ keys کو code کے بجائے environment میں رکھیں، بالکل اسی طرح جیسے a first Claude API app on a VPS انہیں handle کرتا ہے۔

Loop کو محدود کریں، کیونکہ کوئی اور طریقہ نہیں ہے

یہاں iteration count کو محدود کرنا لازمی ہے۔ loop آپ کا ہے، اس لیے counter بھی آپ کا ہے:

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 صرف ایک response کو limit کرتا ہے، اور model کو صرف task budget کے بارے میں مطلع کیا جاتا ہے۔

Process کے باہر ایک دوسرا brake لگائیں۔ Job کو permanent process کے بجائے systemd timer کے ذریعے چلائیں، اور اس کے service unit پر RuntimeMaxSec= سیٹ کریں۔ RuntimeMaxSec=600 کے ساتھ، اگر کوئی run hang ہو جائے تو اسے 10 منٹ کے بعد kill کر دیا جائے گا، بجائے اس کے کہ وہ آپ کے notice کرنے تک چلتا رہے۔ Running a program as a systemd service and timer میں unit files کے بارے میں تفصیل موجود ہے۔ یہ دیکھنے کے لیے کہ run نے کیا کیا، journalctl -u triage-agent.service --since "1 hour ago" استعمال کریں۔

Retries کو بھی محدود کریں، کیونکہ وہ handler جو ہمیشہ retry کرتا ہے، ہر attempt کا खर्च (cost) لگاتا ہے۔ 429 یا 500 error کے لیے backoff کے ساتھ چند tries مناسب ہیں۔ 400 error کے لیے کوئی retry مناسب نہیں ہے، کیونکہ وہی request اسی طرح fail ہوگی۔

AI agent cost control starts with reading your own numbers

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

یہ اس صورت میں ہے جب آپ API key استعمال کر رہے ہوں، کیونکہ agent آپ کا اپنا پروگرام ہے جو Messages API کو کال کرتا ہے۔ اپنے ذاتی interactive کام کے لیے، جو Claude plan آپ کے کام کے انداز کے مطابق ہو سبسکرپشن سے متعلق معلومات فراہم کرتا ہے۔ یہاں دی گئی ہر قیمت اور حد (limit) کا موازنہ July 2026 میں Anthropic کی documentation سے کیا گیا تھا، اس لیے بجٹ بنانے سے پہلے pricing page کو دوبارہ ضرور پڑھ لیں۔

FAQ

VPS پر always-on AI agent چلانے کا کتنا خرچ آتا ہے؟

اس میں دو بل ہوتے ہیں اور صرف ایک کا اندازہ لگایا جا سکتا ہے۔ سرور کی ماہانہ قیمت مقررہ ہوتی ہے۔ Model API کا خرچ tokens پر مبنی ہوتا ہے، اس لیے کل خرچ کا تعین ایک بار کے استعمال اور اس کی تعدد (frequency) سے ہوتا ہے۔ Anthropic نے self-hosted always-on agent کے لیے کوئی فگر شائع نہیں کیا، اس لیے کسی بھی quoted number کو صرف ایک اندازہ سمجھیں۔ ایک حقیقی run سے usage کا log حاصل کریں اور اسے اپنے شیڈول سے ضرب دیں۔

max_tokens اور task budget میں کیا فرق ہے؟

max_tokens لاگو ہوتا ہے اور model کے لیے پوشیدہ ہوتا ہے۔ یہ ایک request کے output کو (thinking سمیت) محدود کرتا ہے، اور اس حد تک پہنچنے پر stop_reason: "max_tokens" حاصل ہوتا ہے۔ Task budget اس کے برعکس ہے: model کو یہ نمبر بتایا جاتا ہے اور وہ اس کے مطابق agentic loop کو چلاتا ہے، لیکن "Task budgets ایک soft hint ہیں، hard cap نہیں" اور اصل limit اب بھی max_tokens ہی ہے۔

میرے agent کے لیے cache_read_input_tokens ہمیشہ zero کیوں ہوتا ہے؟

کیونکہ calls کے درمیان prefix تبدیل ہو جاتا ہے، یا یہ cache کرنے کے لیے بہت چھوٹا ہوتا ہے۔ عام وجہ system prompt میں شامل timestamp یا run id ہے: cache prefix پر आधारित ہوتا ہے، اس لیے ایک byte کی تبدیلی بھی اس کے بعد کے تمام ڈیٹا کو invalid کر دیتی ہے۔ Tool definitions یا effort کی value تبدیل کرنے سے بھی یہی ہوتا ہے۔ اس کے علاوہ، اگر prompt کا سائز چھوٹا ہو تو بھی ایسا ہوتا ہے کیونکہ چھوٹے prompts cache نہیں کیے جاتے اور کوئی error بھی نہیں آتا۔

میں AI agent کو ہمیشہ کے لیے looping میں پھنسنے سے کیسے روک سکتا ہوں؟

اپنے loop code میں iterations کو count کریں اور ایک مقررہ maximum پر روک دیں، کیونکہ max_tokens صرف ایک response کو محدود کرتا ہے جبکہ ایک agent بہت سے responses بناتا ہے۔ process کے باہر ایک wall-clock limit لگائیں: job کو systemd timer سے شروع کریں جس میں RuntimeMaxSec= set ہو، تاکہ پھنس جانے والا run مقررہ وقت پر ختم ہو جائے۔ Retries کو بھی محدود کریں، کیونکہ ہر retry attempt کا الگ بل آتا ہے۔

کیا میں کسی ایک Claude API key پر spending limit لگا سکتا ہوں؟

Documented spend limit key کے بجائے workspace کے لیے ہوتی ہے، اس لیے agent کو اس کا اپنا workspace دیں اور وہاں اس کا ماہانہ خرچ محدود کریں۔ "You cannot set limits on the Default Workspace"۔ Spend notifications لگائیں تاکہ ایک threshold آپ کو مطلع کر سکے۔ Attribution کے لیے، ہر job کو اپنی الگ key دیں، اور پھر usage report کو group_by[]=api_key_id کے ساتھ group کریں۔