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

চলমান AI agent-এর বিল নিয়ন্ত্রণে রাখার উপায়

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

এখানে এমন একটি agent ধরে নেওয়া হয়েছে, যা আগে থেকেই তৈরি এবং আপনার মালিকানাধীন একটি machine থেকে Messages API call করে। VPS-এ Claude দিয়ে AI agent তৈরি-এ মূল ব্যবস্থা তৈরির পদ্ধতি দেখানো হয়েছে।

Why an unattended agent is a different cost shape

An interactive session has a human in it. When the model goes down a wrong path or reads a 40,000-line log, the person watching stops it. An unattended agent has no such brake: it runs until the loop ends, then a timer starts it again.

Frequency is the multiplier people miss. A job on a five-minute schedule runs 288 times a day and about 8,640 times a month. Whatever one run costs, that is the figure you multiply. Many "always-on" agents do not need to be on. They need to answer within some number of minutes, which is a schedule.

An agent also pays for things a chat window does not.

• Tool definitions ride along on every request. The tool-use system prompt costs 290 tokens on Claude Opus 4.8 with tool_choice of auto or none, and 410 with any or tool. The bash tool adds 325 more. Every MCP server you attach adds its schemas to that weight, MCP being the model context protocol.
• Tool results are input tokens. A command that prints 8,000 lines puts 8,000 lines into the next request, and into every request after it in that turn.
• Fetched pages are input tokens. An average 10 kB web page is roughly 2,500 tokens and a 500 kB research PDF roughly 125,000. max_content_tokens truncates the text ones only, because it "applies to text content, not to binary content such as PDFs". Bound a PDF with max_uses and allowed_domains instead.
• Web search is priced per search, at $10 per 1,000 searches, however many results come back. A search that errors is not billed.

None of that is expensive once. All of it is expensive 8,640 times.

হার্ড ceiling এবং সফট ceiling ভিন্ন সমস্যার সমাধান করে

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

Task budget পরামর্শমূলক। task_budget, output_config-এর মধ্যে থাকে এবং পুরো agentic loop-এ model-এর জন্য কত token বরাদ্দ আছে তা জানায়। এর মধ্যে thinking, tool call, tool result এবং 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 budget একটি soft hint, hard cap নয়।" কোনো একটি action চলাকালে Claude এই সীমা অতিক্রম করতে পারে। তবে output-এর কার্যকর সীমা এখনও max_tokens। "Countdown শুধু model দেখতে পায়", এবং response-এ remaining-budget field থাকে না। গ্রহণযোগ্য সর্বনিম্ন task_budget.total হলো 20,000 token। এর চেয়ে কম দিলে 400 error ফেরত আসে। কাজের জন্য budget খুব কম হলে refusal-এর মতো আচরণ দেখা দিতে পারে। তখন model task-এর scope কমিয়ে দেয় অথবা আগেই থেমে যায়।

একটি detail অর্থ সাশ্রয় না করে বরং খরচ বাড়ায়। আপনার client যদি প্রতিটি follow-up request-এ task_budget.remaining কমায়, তাহলে পরিবর্তিত value-টি সেটি ধারণ করা cached prefix-কে invalid করে। এটি প্রথম request-এ একবারই set করুন।

Claude Fable 5, Claude Opus 4.8 এবং Claude Opus 4.7-এ task budget beta পর্যায়ে রয়েছে। Claude Sonnet 5 এবং Claude Haiku 4.5-কে Not supported হিসেবে তালিকাভুক্ত করা হয়েছে। Claude Code-এ task budget প্রযোজ্য নয়। তাই tmux-এ detached Claude Code session session hygiene-এর ওপর নির্ভর করে।

তৃতীয় ceiling Claude Console-এ থাকে। Agent-এর জন্য একটি আলাদা workspace দিন। এরপর সেটিতে monthly spend limit এবং per-minute rate limit নির্ধারণ করুন। "Default Workspace-এ limit নির্ধারণ করা যায় না", এবং "workspace limit-গুলোর যোগফল তার চেয়ে বেশি হলেও Organization-wide limit সবসময় প্রযোজ্য।" Spend notification যোগ করুন, যাতে cap-এ পৌঁছানোর আগে threshold অতিক্রম করলে আপনি alert পান।

প্রতি কাজের জন্য মডেল নির্বাচন এবং কোন প্রচেষ্টায় আসলে পরিবর্তন আসে

মডেল নির্বাচন প্রতিটি কাজের জন্য আলাদা সিদ্ধান্ত। 2026 সালের July অনুযায়ী, প্রতি million token-এ input এবং তারপর output-এর দাম হলো: 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 আপাতত ঘোষিত দামের চেয়ে কম দামে পাওয়া যাচ্ছে, কারণ “প্রতি million input/output token-এ $2/$10-এর প্রারম্ভিক মূল্য 31 August 2026 পর্যন্ত কার্যকর।” শুধু log line শ্রেণিবদ্ধ করার মতো কাজের জন্য Opus প্রয়োজন হয় না। ব্যস্ত schedule সামলানোর জন্য কোনো free allowance-ও নেই, কারণ signup-এর সময় দেওয়া সামান্য credit ছাড়া Claude API-তে কোনো free tier নেই।

Effort হলো দ্বিতীয় নিয়ন্ত্রণযোগ্য বিষয়। output_config.effort, low, medium, high, xhigh এবং max গ্রহণ করে, আর default হলো high; তাই high স্পষ্টভাবে সেট করা এবং এটি বাদ দেওয়া একই বিষয়। কম effort শুধু reasoning-এর দৈর্ঘ্য কমায় না। Documentation অনুযায়ী, এতে Claude কম tool call করে এবং একাধিক operation একসঙ্গে সম্পন্ন করে। Agent-এর ক্ষেত্রে এটিই বেশি সাশ্রয় করে, কারণ এড়ানো প্রতিটি tool call এমন একটি সম্পূর্ণ request, যা আর পাঠানো হয় না।

সমস্যা হলো, effort cache-এর সঙ্গে বিরোধ তৈরি করে। Request-এর মধ্যে value পরিবর্তন করলে prompt caching invalid হয়ে যায়। Documentation-এর উদাহরণে request 2-তে cache_read_input_tokens: 3546 রিপোর্ট করা হয়েছিল; effort high থেকে medium পরিবর্তন করার পর request 3-এ 3546-এর মধ্যে cache_creation_input_tokens এবং 0-এর মধ্যে cache_read_input_tokens রিপোর্ট করা হয়েছিল। তাই workload-এর মধ্যে effort পরিবর্তন করুন, কিন্তু একই cached conversation-এর মধ্যে কখনো পরিবর্তন করবেন না। Cache নষ্ট না করে depth নিয়ন্ত্রণ করতে prompt ব্যবহার করুন। যেমন, সর্বশেষ user message-এ “বিস্তারিত চিন্তা না করে সরাসরি উত্তর দিন।” লিখলে আগের breakpoint অক্ষত থাকে।

Thinking token-এর জন্য output rate অনুযায়ী billing হয় এবং এগুলো max_tokens-এর মধ্যে গণনা হয়। এ কারণেই truncated answer প্রায়ই বোঝায় যে thinking budget ব্যবহার করে ফেলেছে। সংখ্যা জানতে usage.output_tokens_details.thinking_tokens পড়ুন। Claude-এর token bill-এ আসলে কী কী গণনা হয় বিষয়টি বিশদে ব্যাখ্যা করে।

স্থিতিশীল prefix cache করুন এবং ভুল করে এটি নষ্ট করা বন্ধ করুন

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

একটি লাইন ব্যাখ্যা করে কেন এটি সব সময় চালু থাকা agent-এর জন্য উপযোগী: “Cached content ব্যবহার করা হলে প্রতিবার কোনো অতিরিক্ত খরচ ছাড়াই cache refresh হয়।” পাঁচ মিনিটের cache ব্যবহার করে প্রতি দুই মিনিটে চালানো একটি job একটি write-এর বিনিময়ে সারা দিন তার prefix warm রাখে।

খেয়াল না করেই cache হারানোর 3টি উপায় আছে।

পরিবর্তনশীল prefix। “Cache prefix-গুলো নিম্নলিখিত ক্রমে তৈরি হয়: tools, system, তারপর messages।” এই ক্রমে আগের কোনো byte পরিবর্তিত হলে তার পরের সবকিছু invalid হয়ে যায়, আর tool definition সম্পাদনা করলে পুরো cache invalid হয়। নিজের কারণে তৈরি হওয়া প্রচলিত সমস্যাটি হলো system prompt-এ timestamp বা run id রাখা। এতে প্রতিটি request আলাদা prefix বহন করে, 1.25x খরচে একটি নতুন entry লিখে, কিন্তু কোনো cache read হয় না। একই রকম দেখতে call-গুলোর মধ্যে usage.cache_read_input_tokens-এর মান 0 থাকা এর লক্ষণ। পরিবর্তনশীল text-টি সর্বশেষ user message-এ সরিয়ে নিন।

অতিরিক্ত ছোট prefix। প্রতিটি model-এর একটি minimum cacheable length থাকে। এর নিচে request caching ছাড়াই process হয় এবং “কোনো error ফেরত দেওয়া হয় না”। এই সীমার মধ্যে Claude Opus 4.8 ও Claude Sonnet 5-এর জন্য 1,024 tokens এবং Claude Haiku 4.5-এর জন্য 4,096 tokens রয়েছে। তাই কোনো job Sonnet থেকে Haiku-তে সরালে caching নীরবে বন্ধ হয়ে যেতে পারে।

Lookback সীমার চেয়ে বড় conversation। “Lookback window হলো 20 blocks।” প্রতিটি breakpoint-এর জন্য system সর্বোচ্চ 20টি position পরীক্ষা করে, তারপর থেমে যায়। Documented example-এ block 35-এ breakpoint থাকা 35টি block-এর একটি turn হলে system block 35 থেকে 16 পর্যন্ত পরীক্ষা করে। আগের turn-এর block 15-এর entry window-এর বাইরে থাকায় কোনো hit হয় না। প্রতি turn-এ একাধিক tool-use এবং tool-result block যোগ করা agent দুই বা তিন turn-এর মধ্যেই 20টি block অতিক্রম করে। প্রতিটি request-এ আপনি 4টি breakpoint পান, তাই এর মধ্যে একটি সাম্প্রতিক message-এর জন্য ব্যবহার করুন।

যে কাজ অপেক্ষা করতে পারে, তা Batches API-তে পাঠান

ইনপুট ও আউটপুট—উভয় ক্ষেত্রেই সব ব্যবহার standard API price-এর 50% হারে বিল করা হয়। Batch processing asynchronous; “বেশিরভাগ batch 1 hour-এর কম সময়ে সম্পন্ন হয়”, এবং সব request শেষ হলে অথবা 24 hours পরে—যেটি আগে ঘটে—ফলাফল পাওয়া যায়। এটি সাধারণ সময়সীমা, নিশ্চয়তা নয়।

processing_status পরীক্ষা করতে থাকুন, যতক্ষণ না এর মান ended হয়। errored, canceled অথবা expired ফেরত দেওয়া request-এর জন্য বিল করা হয় না। তবে spend cap ব্যবহার করলে একটি বিষয় মনে রাখুন: “batch আপনার Workspace-এর configured spend limit সামান্য অতিক্রম করতে পারে।”

Discount-গুলো একসঙ্গে প্রযোজ্য হয়। একটি batch সম্পন্ন হতে five minutes-এর বেশি সময় লাগতে পারে বলে documentation একই context ভাগ করা batch-এর জন্য one-hour cache ব্যবহারের পরামর্শ দেয়। তাই কাজ ভাগ করুন: যে কাজের জন্য কোনো ব্যক্তি বা webhook অপেক্ষা করে, তা live path-এ রাখুন। nightly digest অথবা গতকালের log classification অর্ধেক দামে batch-এ পাঠান।

প্রতিটি response-এর usage field নিজের store-এ লগ করুন

আপনি যে খরচ রেকর্ড করেননি, তার attribution করা যায় না। প্রতিটি 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-এর জন্য একটি করে row JSON-lines file-এ যোগ করুন এবং job name দিয়ে tag করুন। এক সপ্তাহ পরে আপনি বলতে পারবেন কোন job খরচ করছে এবং কোনটি শুধু ব্যস্ত দেখাচ্ছে। cache_read monitor করুন: zeros-এ ভরা একটি column 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 report করে, সেটি কম খরচের নয়; বাকি token cache থেকে এসেছে।

পাঠানোর আগে count করুন। Token counting বিনামূল্যে এবং এর rate limit message creation-এর rate limit থেকে আলাদা। তাই attachment বড় হলে টাকা খরচ করে তা জানার বদলে count_tokens ব্যবহার করে request প্রত্যাখ্যান করুন। ফলাফলটি একটি estimate, তাই প্রতিটি model-এর জন্য আবার মাপুন এবং অন্য vendor-এর tokenizer থেকে পাওয়া count কখনো পুনর্ব্যবহার করবেন না। Claude Opus 4.7 এবং পরবর্তী Opus model, Claude Fable 5 এবং Claude Sonnet 5 একটি নতুন tokenizer ব্যবহার করে, যা "একই text-এর জন্য প্রায় 30% বেশি token তৈরি করে"। Claude Sonnet 4.6 এবং তার আগের version-গুলো, যার মধ্যে Claude Haiku 4.5-ও রয়েছে, আগের tokenizer ব্যবহার করে।

Authoritative view-এর জন্য Admin API https://api.anthropic.com/v1/organizations/usage_report/messages-এ usage এবং https://api.anthropic.com/v1/organizations/cost_report-এ cost report করে। উভয় endpoint-এই 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[]= গ্রহণ করে। একটি সীমাবদ্ধতা হলো: "Individual account-এর জন্য Admin API available নয়।"

শেষ parameter-টি attribution করার একটি কম খরচের কৌশল। প্রতিটি job-এর জন্য আলাদা API key দিন, api_key_ids[] দিয়ে filter করুন এবং group_by[]=api_key_id দিয়ে প্রতিটি key অনুযায়ী report ভাগ করুন। Filter-টি plural, কিন্তু grouping dimension singular। Key-গুলো code-এ না রেখে environment-এ সংরক্ষণ করুন, যেমন VPS-এ প্রথম Claude API app সেগুলো পরিচালনা করে।

লুপের সীমা নির্ধারণ করুন, কারণ অন্য কিছু তা করবে না

এখানে নির্দিষ্ট iteration count ঐচ্ছিক নয়। লুপটি আপনার, তাই 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)

উপরের কোনো ceiling আপনার হয়ে কাজ করবে না: max_tokens একটি response-এর সীমা নির্ধারণ করে, আর model-কে শুধু task budget সম্পর্কে জানানো হয়। Hosted product হলে এই পর্যায়ে আপনাকে থামিয়ে দিত। যেমন, একটি turn-এর মধ্যে Claude-এর tool call সীমা অতিরিক্ত tool call হওয়া session থামিয়ে দেয়। কিন্তু আপনি নিজে লেখা লুপে এমন কোনো backstop থাকে না, যতক্ষণ না আপনি তা যোগ করেন।

Process-এর বাইরেও একটি দ্বিতীয় brake রাখুন। Permanent process-এর পরিবর্তে systemd timer থেকে job চালান এবং এর service unit-এ RuntimeMaxSec= নির্ধারণ করুন। RuntimeMaxSec=600 ব্যবহার করলে hung run দশ মিনিট পরে বন্ধ হয়ে যায়; আপনি তা লক্ষ্য না করা পর্যন্ত এটি চলতেই থাকে না। systemd service এবং timer হিসেবে program চালানো-তে unit file-গুলোর বিস্তারিত রয়েছে। কোনো run কী করেছে, তা journalctl -u triage-agent.service --since "1 hour ago" দিয়ে দেখুন।

Retries-এরও সীমা নির্ধারণ করুন, কারণ যে handler অনির্দিষ্টকাল retry করে, সেটি প্রতিটি attempt-এর জন্য খরচ তৈরি করে। 429 বা 500-এর ক্ষেত্রে backoff সহ কয়েকবার retry করা যুক্তিযুক্ত। 400-এর ক্ষেত্রে একবারও নয়, কারণ একই request একইভাবে ব্যর্থ হবে।

AI agent-এর খরচ নিয়ন্ত্রণ শুরু হয় নিজের ব্যবহারের পরিসংখ্যান পড়া দিয়ে

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

এখানে API key ব্যবহারের কথা ধরা হয়েছে, কারণ agent-টি আপনার নিজস্ব program, যা Messages API কল করে। আপনার নিজস্ব interactive কাজের জন্য আপনার কাজের ধরন অনুযায়ী কোন Claude plan উপযুক্ত subscription-এর দিকটি ব্যাখ্যা করে। এখানে দেওয়া প্রতিটি price ও limit July 2026-এ Anthropic-এর documentation-এর সঙ্গে মিলিয়ে দেখা হয়েছে। তাই budget তৈরির আগে pricing page আবার পড়ুন।

FAQ

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

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

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

max_tokens কার্যকর করা হয় এবং model এটি দেখতে পায় না। এটি একটি request-এর output সীমাবদ্ধ করে, যার মধ্যে thinking-ও অন্তর্ভুক্ত। এই সীমায় পৌঁছালে stop_reason: "max_tokens" পাওয়া যায়। Task budget এর বিপরীত: model-কে সংখ্যাটি জানানো হয় এবং সে সেই অনুযায়ী 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 interpolated থাকা। Cache prefix-এর ওপর নির্ভর করে, তাই যেকোনো byte পরিবর্তিত হলে তার পরের সবকিছু cache-এর বাইরে চলে যায়। Tool definition বা effort value পরিবর্তন করলেও একই ঘটনা ঘটে। অন্যথায় কারণটি size: ছোট prompt cache করা হয় না এবং কোনো error ফেরত দেওয়া হয় না।

AI agent-কে অনন্তকাল loop করা থেকে কীভাবে থামাব?

আপনার loop code-এ iteration গণনা করুন এবং একটি নির্দিষ্ট সর্বোচ্চ সীমায় পৌঁছালে থামুন। কারণ max_tokens একটি response সীমাবদ্ধ করে, কিন্তু একটি agent বহু response তৈরি করতে পারে। Process-এর বাইরে একটি wall-clock limit যোগ করুন। RuntimeMaxSec= সেট করে systemd timer থেকে job শুরু করুন, যাতে আটকে থাকা run নির্ধারিত সময়ে kill হয়। Retry-এর সংখ্যাও সীমাবদ্ধ করুন, কারণ retry loop-এর প্রতিটি attempt-এর জন্য বিল হয়।

একটি Claude API key-এর জন্য কি spending limit নির্ধারণ করা যায়?

Documented spend limit key অনুযায়ী নয়, workspace অনুযায়ী নির্ধারিত হয়। তাই agent-এর জন্য আলাদা একটি workspace তৈরি করুন এবং সেখানে মাসিক spend সীমাবদ্ধ করুন। “You cannot set limits on the Default Workspace”। Spend notification যোগ করুন, যাতে কোনো threshold অতিক্রম করার আগে আপনি alert পান। Attribution-এর জন্য প্রতিটি job-কে আলাদা key দিন। এরপর group_by[]=api_key_id ব্যবহার করে usage report group করুন।