VPS-এ AI agent এর খরচ কমানোর উপায়

কীভাবে একটি সর্বদা সচল AI agent-এর খরচ নিয়ন্ত্রণে রাখা যায়

VPS (virtual private server)-এ AI agent-এর খরচ নিয়ন্ত্রণ করার মূল উপায় হলো এজেন্ট শুরু করার আগেই একটি সীমা নির্ধারণ করে দেওয়া। কারণ এজেন্ট চলার সময় কেউ মিটার পর্যবেক্ষণ করে না। প্রতিটি response-এর জন্য max_tokens ব্যবহার করে সীমা নির্ধারণ করুন, আপনার কোডে loop iteration সীমাবদ্ধ করুন, প্রম্পটের অপরিবর্তিত অংশটি cache করে রাখুন এবং কোন কাজে কত খরচ হচ্ছে তা দেখতে প্রতিটি response-এর usage log করুন। সার্ভার ভাড়ার জন্য একটি নির্দিষ্ট মাসিক মূল্য দিতে হয়। কিন্তু model API-এর খরচ token অনুযায়ী নির্ধারিত হয়, এবং একটি unattended loop খুব সহজেই নিঃশব্দে অনেক token খরচ করে ফেলতে পারে।

এটি এমন একটি agent-এর ক্ষেত্রে প্রযোজ্য যা ইতিমধ্যে বিদ্যমান এবং আপনার নিজস্ব কোনো machine থেকে Messages API কল করে। VPS-এ Claude দিয়ে একটি AI agent তৈরি করা নিবন্ধটিতে এর কারিগরি বিষয়গুলো আলোচনা করা হয়েছে।

কেন একটি unattended agent-এর খরচের ধরন ভিন্ন

একটি interactive session-এ একজন মানুষ থাকেন। মডেলটি ভুল পথে চলে গেলে বা 40,000 লাইনের কোনো log পড়লে, পর্যবেক্ষক সেটি থামিয়ে দিতে পারেন। একটি unattended agent-এর ক্ষেত্রে এমন কোনো নিয়ন্ত্রণ নেই: এটি লুপ শেষ না হওয়া পর্যন্ত চলতে থাকে, এরপর একটি timer পুনরায় এটি চালু করে।

মানুষের নজর এড়িয়ে যাওয়া বিষয় হলো frequency। প্রতি পাঁচ মিনিটে একবার করে চলা একটি job দিনে 288 বার এবং মাসে প্রায় 8,640 বার চলে। একটি মাত্র run-এর খরচ যাই হোক না কেন, সেই সংখ্যাটিকে আপনাকে গুণ করতে হবে। অনেক "always-on" agent-এর সবসময় চালু থাকার প্রয়োজন হয় না। তাদের কেবল নির্দিষ্ট কয়েক মিনিটের মধ্যে উত্তর দিতে হয়, যা একটি schedule।

একটি agent এমন কিছু বিষয়ের জন্যও খরচ করে যা একটি chat window করে না।

• প্রতিটি request-এর সাথে tool definitions যুক্ত থাকে। Claude Opus 4.8-এ tool_choice of auto বা none হলে tool-use system prompt-এর খরচ হয় 290 tokens, এবং any বা tool হলে 410 tokens। bash tool আরও 325 tokens যোগ করে। প্রতিটি সংযুক্ত MCP server তার schema যুক্ত করে সেই ওজন বাড়িয়ে দেয়, যেখানে MCP হলো model context protocol।
• Tool results হলো input tokens। একটি command যা 8,000 লাইন প্রিন্ট করে, সেটি পরবর্তী request-এ এবং সেই turn-এর প্রতিটি পরবর্তী request-এ 8,000 লাইনই পাঠায়।
• Fetched pages হলো input tokens। একটি গড় ১০ kB ওয়েব পেজ প্রায় 2,500 tokens এবং একটি 500 kB রিসার্চ PDF প্রায় 125,000 tokens। max_content_tokens শুধুমাত্র text content-এর ক্ষেত্রে truncate করে, কারণ এটি "applies to text content, not to binary content such as PDFs"। এর পরিবর্তে PDF-কে max_uses এবং allowed_domains দিয়ে bind করুন।
• Web search-এর দাম প্রতি search অনুযায়ী নির্ধারিত হয়, প্রতি 1,000 search-এ $10, ফলাফল যতটিই আসুক না কেন। কোনো search error হলে তার জন্য বিল নেওয়া হয় না।

এগুলোর কোনোটিই একবারের জন্য ব্যয়বহুল নয়। এগুলোর প্রতিটি ৮,৬৪০ বার ব্যয়বহুল।

Hard ceilings এবং soft ceilings ভিন্ন ভিন্ন সমস্যার সমাধান করে

max_tokens কার্যকর করা হয়। এটি একটি request-এর মোট output-এর জন্য একটি hard cap, যেখানে thinking এবং response text উভয়ই অন্তর্ভুক্ত। Claude কখনোই এর বেশি generate করে না এবং model এই সংখ্যাটি দেখতে পায় না। এই সীমায় পৌঁছালে stop_reason: "max_tokens" ঘটে এবং উত্তরটি truncated হয়ে যায়। agents-এর ক্ষেত্রে সমস্যাটি হলো: tool-use loop-এর প্রতিটি request-এ নিজস্ব max_tokens থাকে, তাই এটি একটি মাত্র response-কে সীমাবদ্ধ করে, পুরো task-কে নয়। 4,000 tokens বিশিষ্ট দশটি tool call মানে একটি turn-এর জন্য 40,000-token ceiling।

Task budget একটি advisory নির্দেশিকা। task_budget হলো output_config-এর অন্তর্ভুক্ত এবং এটি model-কে জানায় যে পুরো agentic loop-এর জন্য তার কাছে কতটি token আছে; এতে 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 শুধুমাত্র model-এর কাছে দৃশ্যমান", এবং response-এ কোনো remaining-budget field থাকে না। সর্বনিম্ন গ্রহণযোগ্য task_budget.total হলো 20,000 tokens, এর কম হলে 400 error দেখাবে। কাজের জন্য budget খুব কম হলে model refusal-এর মতো আচরণ করে, ফলে model task-এর পরিধি কমিয়ে ফেলে বা দ্রুত থেমে যায়।

একটি বিষয় খরচ বাঁচানোর পরিবর্তে খরচ বাড়িয়ে দেয়। যদি আপনার client প্রতিটি follow-up request-এ task_budget.remaining হ্রাস করে, তবে পরিবর্তিত value-টি ওই 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-এ limit সেট করা যায় না", এবং "Organization-wide limits সবসময় প্রযোজ্য হয়, এমনকি workspace limit-এর সমষ্টি তার চেয়ে বেশি হলেও"। spend notifications যোগ করুন যাতে cap-এ পৌঁছানোর আগেই একটি threshold আপনাকে সতর্ক করতে পারে।

প্রতি-জব মডেল নির্বাচন এবং প্রকৃত প্রচেষ্টার পরিবর্তন

মডেল নির্বাচন প্রতিটি জবের জন্য একটি আলাদা সিদ্ধান্ত। ২০২৬ সালের জুলাই অনুযায়ী, প্রতি ১০ লক্ষ টোকেনের জন্য ইনপুট এবং আউটপুট খরচ হলো: 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 line ক্লাসিফাই করার কাজের জন্য Opus এর প্রয়োজন নেই।

Effort হলো দ্বিতীয় নিয়ন্ত্রক। output_config.effort accepts low, medium, high, xhigh এবং max, এবং এর default হলো high; তাই high স্পষ্টভাবে সেট করা মানে এটি বাদ দেওয়া। Effort কমালে শুধু reasoning length কমে না: ডকুমেন্টেশন অনুযায়ী এটি Claude কে কম tool calls করতে এবং একাধিক অপারেশনকে একটিতে যুক্ত করতে সাহায্য করে। একটি agent এর ক্ষেত্রে এটি বড় ধরনের সাশ্রয় আনে, কারণ একটি tool call এড়ানো মানে একটি সম্পূর্ণ request বেঁচে যাওয়া।

এর অসুবিধা হলো effort এবং cache একে অপরের পরিপন্থী। প্রতিটি request এর মাঝে value পরিবর্তন করলে prompt caching invalid হয়ে যায়। ডকুমেন্টেশনে দেওয়া উদাহরণ অনুযায়ী, request 2 এ cache_read_input_tokens: 3546 দেখা গেছে; request 3 এ, যেখানে effort high থেকে medium করা হয়েছে, সেখানে cache_creation_input_tokens ছিল 3546 এবং cache_read_input_tokens ছিল 0। তাই বিভিন্ন workload এর মধ্যে effort পরিবর্তন করুন, কিন্তু একটি cached conversation এর ভেতরে নয়। Cache নষ্ট না করে গভীরতা নিয়ন্ত্রণ করতে prompt ব্যবহার করুন: সর্বশেষ user message এ "Answer directly without deliberating." এর মতো একটি লাইন লিখলে আগের breakpoints গুলো অক্ষুণ্ণ থাকে।

Thinking tokens এর জন্য output rate অনুযায়ী বিল হয় এবং এগুলো max_tokens এর অন্তর্ভুক্ত হয়; এই কারণেই অনেক সময় উত্তর অসম্পূর্ণ থাকলে বুঝতে হবে thinking এর কারণে বাজেট শেষ হয়ে গেছে। সংখ্যাটি জানতে usage.output_tokens_details.thinking_tokens পড়ুন। What actually fills a Claude token bill বিস্তারিত ব্যাখ্যা করে।

Stable prefix cache করুন এবং ভুলবশত এটি নষ্ট হওয়া রোধ করুন

পাঁচ-মিনিট cache-এর ক্ষেত্রে cache write-এর খরচ base input price-এর 1.25 গুণ এবং এক-ঘণ্টা cache-এর ক্ষেত্রে 2 গুণ। Cache read-এর খরচ 0.1 গুণ। তাই "5-minute duration-এর জন্য মাত্র একটি cache read-এর পর (1.25x write) caching লাভজনক হয়, অথবা 1-hour duration-এর জন্য দুটি cache read-এর পর (2x write) লাভজনক হয়।"

কেন এটি একটি always-on agent-এর জন্য উপযোগী তা একটি লাইন দিয়ে বোঝানো যায়: "প্রতিবার cached content ব্যবহার করার সময় কোনো অতিরিক্ত খরচ ছাড়াই cache refresh করা হয়।" পাঁচ-মিনিট cache-এর বিপরীতে প্রতি দুই মিনিটে একটি job চালালে মাত্র একটি write-এর মাধ্যমে সারাদিন এর prefix warm রাখা সম্ভব।

সতর্কতা ছাড়াই cache হারানোর তিনটি উপায়।

পরিবর্তনশীল prefix। "Cache prefixes নিচের ক্রমে তৈরি করা হয়: tools, system, তারপর messages।" এই ক্রমের শুরুর দিকের কোনো byte পরিবর্তন হলে তার পরের সবকিছু invalid হয়ে যায়, এবং editing tool definitions পুরো cache invalid করে দেয়। system prompt-এ timestamp বা run id রাখা একটি সাধারণ ভুল: এর ফলে প্রতিটি request-এ একটি ভিন্ন prefix থাকে, যা 1.25x খরচে নতুন entry write করে এবং কোনো cache hit পাওয়া যায় না। একই রকম দেখতে call-এর ক্ষেত্রে usage.cache_read_input_tokens value 0 হলে এটি বোঝা যায়। পরিবর্তনশীল টেক্সটটি সর্বশেষ user message-এ সরিয়ে নিন।

অত্যন্ত ছোট prefix। প্রতিটি model-এর একটি minimum cacheable length থাকে; এর নিচে request-টি caching ছাড়াই process করা হয় এবং "no error is returned"। Claude Opus 4.8 এবং Claude Sonnet 5-এর ক্ষেত্রে এই figure হলো 1,024 tokens, এবং Claude Haiku 4.5-এর ক্ষেত্রে 4,096 tokens। তাই একটি job Sonnet থেকে Haiku-তে সরিয়ে নিলে নিঃশব্দে caching বন্ধ হয়ে যেতে পারে।

Lookback window অতিক্রম করা conversation। "Lookback window হলো 20 blocks।" সিস্টেম প্রতিটি breakpoint-এ সর্বোচ্চ 20টি position চেক করে এবং তারপর থেমে যায়। ডকুমেন্ট করা উদাহরণ অনুযায়ী, 35টি block বিশিষ্ট একটি turn-এ যদি block 35-এ breakpoint থাকে, তবে এটি block 35 থেকে 16 পর্যন্ত চেক করে; ফলে block 15-এ থাকা আগের turn-এর entry window-এর বাইরে চলে যায় এবং কোনো hit পাওয়া যায় না। একটি agent যদি প্রতি turn-এ বেশ কিছু tool-use এবং tool-result block যোগ করে, তবে দুই বা তিন turn-এর মধ্যেই সেটি 20 অতিক্রম করে ফেলে। প্রতিটি request-এ আপনি চারটি breakpoint পান, তাই একটি সাম্প্রতিক messages-এর জন্য বরাদ্দ করুন।

যে কাজগুলো পরে করা সম্ভব সেগুলোকে Batches API-তে পাঠান

Input এবং output উভয় ক্ষেত্রেই "All usage is charged at 50% of the standard API prices"। Batch processing হলো asynchronous পদ্ধতি, যেখানে "most batches finishing in less than 1 hour"। প্রতিটি request শেষ হওয়ার পর অথবা 24 ঘণ্টা পর (যেটি আগে আসে) ফলাফল পাওয়া যাবে। এটি একটি সাধারণ ধারণা, কোনো গ্যারান্টি নয়।

processing_status কে ততক্ষণ পর্যন্ত poll করুন যতক্ষণ না এটি ended দেখায়। যে request গুলো errored, canceled অথবা expired রিটার্ন করে সেগুলোর জন্য কোনো বিল নেওয়া হবে না। আপনি যদি spend cap ব্যবহার করেন তবে একটি বিষয় মনে রাখবেন: "batches may go slightly over your Workspace's configured spend limit।"

ডিসকাউন্টগুলো একত্রে কাজ করে। যেহেতু একটি batch সম্পন্ন হতে পাঁচ মিনিটের বেশি সময় নিতে পারে, তাই একই context শেয়ার করে এমন batch গুলোর জন্য ডকুমেন্টেশনে এক ঘণ্টার cache ব্যবহারের পরামর্শ দেওয়া হয়েছে। তাই কাজের বিভাজন করুন: কোনো ব্যক্তি বা webhook যে কাজের জন্য অপেক্ষা করছে সেটি live path-এ রাখুন, আর nightly digest বা গতকালের log classification অর্ধেক মূল্যে batch-এ পাঠিয়ে দিন।

প্রতিটি রেসপন্সের usage field আপনার নিজস্ব স্টোরে লগ করুন

আপনি যা রেকর্ড করেননি, তার খরচ আপনি হিসাব করতে পারবেন না। প্রতিটি রেসপন্স আপনাকে এর খরচ জানিয়ে দেয়।

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 দিয়ে ট্যাগ করুন। এক সপ্তাহ পরে আপনি বুঝতে পারবেন কোন job-এর খরচ বেশি হয়েছে এবং কোনটি কেবল ব্যস্ত দেখাচ্ছিল। cache_read খেয়াল করুন: একটি কলামে সব শূন্য (zero) থাকা হলো self-hosted agent-এর সবচেয়ে সাধারণ cost bug।

একটি field ভুলভাবে পড়া সহজ। input_tokens শুধুমাত্র শেষ cache breakpoint-এর পরের token গুলো গণনা করে, তাই প্রকৃত prompt size হলো total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens। একটি বড় prompt-এর ক্ষেত্রে যদি কোনো agent input_tokens: 400 রিপোর্ট করে, তবে সেটি সস্তা নয়: বাকি অংশ cache থেকে এসেছে।

প্রেরণের আগে গণনা করুন। Token গণনা করা ফ্রি এবং এর rate limits মেসেজ তৈরির থেকে আলাদা, তাই বড় attachment গ্রহণ না করার সিদ্ধান্ত নিতে count_tokens ব্যবহার করুন। ফলাফলটি একটি estimate মাত্র, তাই প্রতিটি model-এর জন্য পুনরায় পরিমাপ করুন এবং অন্য কোনো vendor-এর tokenizer-এর গণনা পুনরায় ব্যবহার করবেন না। Claude Opus 4.7 এবং পরবর্তী Opus model সমূহ, Claude Fable 5 এবং Claude Sonnet 5 একটি নতুন tokenizer ব্যবহার করে যা "একই টেক্সটের জন্য প্রায় 30% বেশি token তৈরি করে"। Claude Sonnet 4.6 এবং এর আগের সংস্করণসমূহ, যার মধ্যে Claude Haiku 4.5 অন্তর্ভুক্ত, আগেরটি ব্যবহার করে।

নির্ভুল তথ্যের জন্য, Admin API https://api.anthropic.com/v1/organizations/usage_report/messages এ usage এবং https://api.anthropic.com/v1/organizations/cost_report এ cost রিপোর্ট করে। উভয় ক্ষেত্রেই 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[] দিয়ে ফিল্টার করুন, এবং group_by[]=api_key_id দিয়ে key অনুযায়ী রিপোর্টটি ভাগ করুন। ফিল্টারটি plural, কিন্তু grouping dimension হলো singular। Key গুলো কোডের পরিবর্তে environment-এ রাখুন, যেভাবে a first Claude API app on a VPS এগুলো হ্যান্ডেল করে।

Bound the loop, because nothing else will

A bounded iteration count is not optional here. The loop is yours, so the counter is yours:

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)

Neither ceiling above does it for you: max_tokens caps one response, and the model is only advised of a task budget.

Put a second brake outside the process. Run the job from a systemd timer instead of a permanent process, and set RuntimeMaxSec= on its service unit. With RuntimeMaxSec=600, a hung run is killed after ten minutes instead of spinning until you notice. Running a program as a systemd service and timer covers the unit files themselves. Read what a run did with journalctl -u triage-agent.service --since "1 hour ago".

Cap retries as well, because a handler that retries forever bills every attempt. A 429 or a 500 deserves a few tries with backoff. A 400 deserves none, since the same request fails the same way.

AI agent এর খরচ নিয়ন্ত্রণ করতে নিজের ডেটা বিশ্লেষণ করা প্রয়োজন

একটি সর্বদা সক্রিয় (always-on) agent এর খরচ কত হবে তা কেউ নিশ্চিতভাবে বলতে পারবে না। কারণ খরচ নির্ভর করে প্রতিটি রান-এ ব্যবহৃত token সংখ্যা এবং দিনে কতবার এটি রান করা হচ্ছে তার ওপর; এই দুটি বিষয় আপনার নিয়ন্ত্রণে থাকে। একবার এটি রান করুন, আপনার লগ করা usage row টি দেখুন এবং আপনার শিডিউল অনুযায়ী গুণফল বের করুন। দুই দিন পর সেই হিসাবের সাথে cost report মিলিয়ে দেখুন। যদি হিসাবের সাথে রিপোর্টের অমিল থাকে, তবে তার কারণ সাধারণত একটি broken cache অথবা আপনার ধারণা করা সময়ের চেয়ে বেশি সময় ধরে চলা কোনো loop।

এখানে একটি API key ব্যবহার করা হয়েছে ধরে নেওয়া হয়েছে, কারণ agent হলো আপনার নিজস্ব প্রোগ্রাম যা Messages API কল করে। আপনার ব্যক্তিগত কাজের জন্য, কোন Claude plan আপনার কাজের উপযোগী এখানে সাবস্ক্রিপশন সংক্রান্ত তথ্য দেওয়া হয়েছে। এখানে বর্ণিত প্রতিটি দাম এবং সীমা ২০২৬ সালের জুলাই মাসে Anthropic-এর ডকুমেন্টেশনের সাথে যাচাই করা হয়েছে। তাই বাজেট তৈরির আগে অবশ্যই pricing page টি পুনরায় দেখে নিন।

FAQ

VPS-এ একটি always-on AI agent চালাতে কত খরচ হয়?

দুটি বিল আসবে এবং কেবল একটির পরিমাণ আগে থেকে জানা সম্ভব। সার্ভারের মাসিক খরচ নির্দিষ্ট। Model API-এর খরচ token অনুযায়ী নির্ধারিত হয়, তাই খরচ হবে প্রতিটি run-এ কতটুকু token ব্যবহৃত হচ্ছে তার গুণফল এবং কতবার এটি run হচ্ছে তার গুণফল। Anthropic self-hosted always-on agent-এর জন্য কোনো নির্দিষ্ট হিসাব প্রকাশ করেনি, তাই যেকোনো উদ্ধৃত সংখ্যাকে একটি অনুমান হিসেবে গণ্য করুন। একটি বাস্তব run থেকে usage log সংগ্রহ করুন এবং আপনার schedule অনুযায়ী গুণফল বের করুন।

max_tokens এবং task budget-এর মধ্যে পার্থক্য কী?

max_tokens মডেলের কাছে অদৃশ্য এবং এটি কঠোরভাবে কার্যকর করা হয়। এটি একটি request-এর output (thinking সহ) সীমাবদ্ধ করে এবং এটি অতিক্রম করলে stop_reason: "max_tokens" ঘটে। Task budget এর বিপরীত: মডেলকে সংখ্যাটি বলা হয় এবং এটি সেই অনুযায়ী agentic loop নিয়ন্ত্রণ করে, কিন্তু "Task budgets are a soft hint, not a hard cap" এবং কার্যকর সীমাটি এখনও max_tokens।

আমার agent-এর জন্য cache_read_input_tokens কেন সবসময় zero দেখায়?

কারণ প্রতিটি call-এর মধ্যে prefix পরিবর্তিত হচ্ছে, অথবা এটি cache করার জন্য খুব ছোট। এর সাধারণ কারণ হলো system prompt-এ timestamp বা run id অন্তর্ভুক্ত করা: cache prefix-এর ওপর ভিত্তি করে কাজ করে, তাই যেকোনো byte পরিবর্তন এর পরের সব কিছু invalid করে দেয়। Tool definition পরিবর্তন করা বা effort value পরিবর্তন করাও একই ফলাফল দেয়। অন্যথায়, এটি সাইজের কারণে হতে পারে, কারণ ছোট prompt cache করা হয় না এবং কোনো error প্রদান করা হয় না।

একটি AI agent-কে অনন্তকাল লুপে থাকা থেকে কীভাবে থামানো যায়?

আপনার loop code-এ iteration গণনা করুন এবং একটি নির্দিষ্ট maximum সংখ্যায় থামিয়ে দিন, কারণ max_tokens একটি মাত্র response-কে সীমাবদ্ধ করে এবং একটি agent অনেকগুলো response তৈরি করে। প্রসেসের বাইরে একটি wall-clock limit যোগ করুন: RuntimeMaxSec= সেট করে একটি systemd timer দিয়ে job শুরু করুন, যাতে আটকে পড়া (wedged) run নির্দিষ্ট সময়ে বন্ধ হয়ে যায়। Retry-এর সংখ্যাও সীমাবদ্ধ করুন, কারণ প্রতিটি retry-তে খরচ বা billing ঘটে।

আমি কি একটি মাত্র Claude API key-তে spending limit সেট করতে পারি?

ডকুমেন্ট অনুযায়ী spend limit প্রতিটি key-এর পরিবর্তে প্রতিটি workspace-এর জন্য প্রযোজ্য, তাই agent-কে একটি নিজস্ব workspace দিন এবং সেখানে এর মাসিক খরচ সীমাবদ্ধ করুন। "You cannot set limits on the Default Workspace"। Spend notification যোগ করুন যাতে একটি নির্দিষ্ট সীমায় পৌঁছালে আপনি সতর্কবার্তা পান। খরচের হিসাব রাখার জন্য, প্রতিটি job-এর জন্য আলাদা key ইস্যু করুন, তারপর usage report-টি group_by[]=api_key_id দিয়ে গ্রুপ করুন।