எப்போதும் இயங்கும் VPS AI agent செலவைக் கட்டுப்படுத்துவது

எப்போதும் இயங்கும் AI agent அதிக கட்டணம் ஏற்படுத்தாமல் தடுப்பது எப்படி

VPS (virtual private server)-ல் AI agent-ன் செலவைக் கட்டுப்படுத்த, agent தொடங்குவதற்கு முன்பே வரம்புகளை அமைக்க வேண்டும். Agent இயங்கும்போது usage meter-ஐ யாரும் தொடர்ந்து கண்காணிக்காமல் இருக்கலாம். ஒவ்வொரு response-க்கும் max_tokens மூலம் cap அமைக்கவும். உங்கள் code-ல் loop iterations-க்கு வரம்பு விதிக்கவும். மாற்றமில்லாத prompt பகுதியை cache செய்யவும். எந்த job அதிகம் செலவிடுகிறது என்பதை அறிய, ஒவ்வொரு response-ன் usage numbers-ஐ log செய்யவும். Server rental-க்கு மாதாந்திர நிலையான கட்டணம் இருக்கும். Model API-ல் token எண்ணிக்கையின் அடிப்படையில் கட்டணம் கணக்கிடப்படும். unattended loop அமைதியாக tokens-ஐ அதிகமாகச் செலவிடும்.

உங்களுக்குச் சொந்தமான server-ல் ஏற்கனவே இயங்கும் agent, Messages API-ஐ அழைக்கிறது என்று இது கருதுகிறது. VPS-ல் Claude மூலம் AI agent உருவாக்குதல் என்ற பகுதி இதற்கான machinery-ஐ விளக்குகிறது.

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.

Hard ceilings மற்றும் soft ceilings வெவ்வேறு பிரச்சினைகளைத் தீர்க்கின்றன

max_tokens அமல்படுத்தப்படுகிறது. இது ஒரு request-ன் மொத்த output-க்கு விதிக்கப்படும் hard cap ஆகும்; இதில் thinking மற்றும் response text இரண்டும் அடங்கும். Claude இதை மீறி output உருவாக்காது; மேலும் model-க்கு இந்த எண்ணிக்கை தெரியாது. இதை அடைந்தால் stop_reason: "max_tokens" கிடைக்கும்; answer துண்டிக்கப்படும். Agents-க்கு முக்கியமான விஷயம்: tool-use loop-ல் உள்ள ஒவ்வொரு request-ம் தனித்தனி max_tokens-ஐ கொண்டிருக்கும். எனவே இது முழு task-ஐ அல்ல, ஒரு response-ஐ மட்டுமே வரையறுக்கும். 4,000 அளவிலான 10 tool calls, அந்த turn-க்கு 40,000-token ceiling-ஐ வழங்கும்.

Task budget ஆலோசனைக்குரியது. task_budget, output_config-க்குள் அமைந்து, முழு agentic loop-க்கு model பயன்படுத்தக்கூடிய 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-க்கு மட்டுமே தெரியும்." Responses-ல் மீதமுள்ள budget-க்கான field இருக்காது. ஏற்கப்படும் குறைந்தபட்ச task_budget.total 20,000 tokens ஆகும். அதற்குக் குறைவான மதிப்பு 400 error-ஐத் தரும். Work-க்கு போதுமான அளவு இல்லாத task budget refusal போன்ற நடத்தையை ஏற்படுத்தும். எனவே model task-ன் scope-ஐக் குறைக்கலாம் அல்லது முன்கூட்டியே நிறுத்தலாம்.

ஒரு detail சேமிப்பதற்குப் பதிலாக செலவை அதிகரிக்கிறது. ஒவ்வொரு follow-up request-லும் உங்கள் client task_budget.remaining-ஐ குறைத்தால், மாற்றப்பட்ட value அதைக் கொண்ட cached prefix-ஐ செல்லாததாக்கும். இதை முதல் request-ல் ஒருமுறை மட்டும் அமைக்கவும்.

Task budgets, Claude Fable 5, Claude Opus 4.8 மற்றும் Claude Opus 4.7 ஆகியவற்றில் beta நிலையில் உள்ளன. Claude Sonnet 5 மற்றும் Claude Haiku 4.5 ஆகியவை Not supported எனப் பட்டியலிடப்பட்டுள்ளன. Claude Code-க்கு task budgets பொருந்தாது. எனவே tmux-ல் detach செய்யப்பட்ட Claude Code session session hygiene-ஐப் பொறுத்திருக்கும்.

மூன்றாவது ceiling Claude Console-ல் உள்ளது. Agent-க்கு தனிப்பட்ட workspace-ஐ வழங்கி, அதில் monthly spend limit மற்றும் per-minute rate limits-ஐ அமைக்கவும். "Default Workspace-ல் limits அமைக்க முடியாது." மேலும், "workspace limits-ன் மொத்தம் அதைவிட அதிகமாக இருந்தாலும் Organization-wide limits எப்போதும் பொருந்தும்." Spend notifications-ஐச் சேர்க்கவும். அப்போது cap-ஐ அடைவதற்கு முன் threshold பற்றிய alert கிடைக்கும்.

ஒவ்வொரு job-க்கும் model தேர்வு, மேலும் எந்த effort உண்மையில் மாற்றத்தை ஏற்படுத்துகிறது

Model தேர்வு ஒவ்வொரு job-க்கும் தனித்தனியாக செய்ய வேண்டிய முடிவு. July 2026 நிலவரப்படி, ஒரு million tokens-க்கு 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 அதன் பட்டியல் விலையைவிடக் குறைவாக உள்ளது. காரணம், "Introductory pricing of $2/$10 per million input/output tokens is in effect through August 31, 2026". Log lines-ஐ மட்டும் வகைப்படுத்தும் step-க்கு Opus தேவையில்லை. Busy schedule-ஐ சமாளிக்க free allowance-உம் இல்லை. ஏனெனில் signup நேரத்தில் வழங்கப்படும் சிறிய credit-ஐத் தவிர, Claude API-க்கு free tier இல்லை.

Effort என்பது இரண்டாவது கட்டுப்பாட்டு அம்சம். output_config.effort, low, medium, high, xhigh மற்றும் max ஆகிய மதிப்புகளை ஏற்கிறது. Default மதிப்பு high. எனவே high-ஐ வெளிப்படையாக அமைப்பது, அதை விடுவது போன்றதே. குறைந்த effort, reasoning length-ஐ மட்டும் குறைக்காது. Documentation-ன் படி, Claude குறைவான tool calls செய்யவும், பல operations-ஐ ஒரே operation-ஆக இணைக்கவும் இது வழிவகுக்கும். Agent-ல் இதுவே அதிக saving-ஐ அளிக்கும். தவிர்க்கப்பட்ட ஒவ்வொரு tool call-உம் நடைபெறாத ஒரு முழு request ஆகும்.

Effort cache-உடன் முரண்படுவது முக்கியமான சிக்கல். Requests-க்கு இடையில் இந்த மதிப்பை மாற்றினால் prompt caching invalid ஆகும். Documentation-ல் உள்ள example-ல், request 2 cache_read_input_tokens: 3546 எனப் பதிவுசெய்தது. High-இலிருந்து medium-ஆக effort மாற்றப்பட்ட request 3, 3546-ல் cache_creation_input_tokens மற்றும் 0-ல் cache_read_input_tokens எனப் பதிவுசெய்தது. எனவே workloads-க்கு இடையில் effort-ஐ மாற்றலாம். ஆனால் ஒரே cached conversation-க்குள் மாற்றக்கூடாது. Cache-ஐ பாதிக்காமல் response depth-ஐ கட்டுப்படுத்த, prompt-ல் அதை குறிப்பிடவும். "Answer directly without deliberating." போன்ற ஒரு line-ஐ newest user message-ல் சேர்த்தால், முந்தைய breakpoints மாற்றமின்றி இருக்கும்.

Thinking tokens, output rates அடிப்படையில் bill செய்யப்படுகின்றன. அவை max_tokens-க்கும் எதிராகக் கணக்கிடப்படுகின்றன. இதனால் truncated answer கிடைப்பதற்கான பொதுவான காரணம் thinking budget-ஐ பயன்படுத்திவிட்டதாகும். எண்ணிக்கையை அறிய usage.output_tokens_details.thinking_tokens-ஐப் பார்க்கவும். Claude token bill-ஐ உண்மையில் நிரப்புவது எது என்பதைப் புரிந்துகொள்ள meter-ன் பகுதிகளைத் தனித்தனியாகப் பாருங்கள்.

நிலையான prefix-ஐ cache செய்து, தவறுதலாக அதை மாற்றுவதைத் தவிர்க்கவும்

ஐந்து நிமிட cache-ல் ஒரு cache write-க்கு base input price-ன் 1.25 மடங்கு செலவாகும்; ஒரு மணி நேர cache-ல் 2 மடங்கு செலவாகும். ஒரு cache read-க்கு 0.1 மடங்கு மட்டுமே செலவாகும். எனவே, "5-minute duration-க்கு (1.25x write) ஒரே ஒரு cache read-க்குப் பிறகே caching பயனளிக்கத் தொடங்கும்; 1-hour duration-க்கு (2x write) இரண்டு cache reads-க்குப் பிறகு பயனளிக்கத் தொடங்கும்".

எப்போதும் இயங்கும் agent-க்கு இது ஏன் பொருத்தமானது என்பதை ஒரு வரி விளக்குகிறது: "Cached content பயன்படுத்தப்படும் ஒவ்வொரு முறையும் கூடுதல் செலவின்றி cache refresh செய்யப்படும்." ஐந்து நிமிட cache-ஐ பயன்படுத்தும் job இரண்டு நிமிடங்களுக்கு ஒருமுறை இயங்கினால், ஒரே ஒரு write மூலம் அதன் prefix நாள் முழுவதும் warm நிலையில் இருக்கும்.

கவனிக்கப்படாமல் cache-ஐ இழக்கும் மூன்று வழிகள்.

மாறும் prefix. "Cache prefixes பின்வரும் வரிசையில் உருவாக்கப்படுகின்றன: tools, system, பின்னர் messages." அந்த வரிசையில் முன்னதாக வரும் எந்த byte-யிலும் மாற்றம் ஏற்பட்டால், அதற்குப் பிறகு உள்ள அனைத்தும் invalid ஆகும். Tool definitions-ஐத் திருத்தினாலும் முழு cache invalid ஆகும். System prompt-ல் timestamp அல்லது run id சேர்ப்பது இதற்கான வழக்கமான self-inflicted wound ஆகும். அப்போது ஒவ்வொரு request-மும் வேறுபட்ட prefix-ஐ எடுத்துச் செல்லும்; 1.25x செலவில் புதிய entry எழுதப்படும்; எந்தப் பழைய entry-யும் read ஆகாது. ஒரே மாதிரியாகத் தோன்றும் calls-களில் usage.cache_read_input_tokens மதிப்பு 0 ஆக இருப்பது இதற்கான அறிகுறி. மாறக்கூடிய text-ஐ புதிய user message-க்கு மாற்றவும்.

மிகக் குறுகிய prefix. ஒவ்வொரு model-க்கும் குறைந்தபட்ச 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 positions-ஐச் சரிபார்த்த பிறகு நிறுத்தும். ஆவணப்படுத்தப்பட்ட example-ல், breakpoint block 35-ல் இருக்கும் 35 blocks கொண்ட turn-க்கு blocks 35 முதல் 16 வரை சரிபார்க்கப்படும். முந்தைய turn-ன் block 15-ல் உள்ள entry இந்த window-க்கு வெளியே இருப்பதால் hit கிடைக்காது. ஒவ்வொரு turn-லும் பல tool-use மற்றும் tool-result blocks-ஐச் சேர்க்கும் agent, இரண்டு அல்லது மூன்று turns-க்குள் 20 blocks-ஐத் தாண்டிவிடும். ஒவ்வொரு request-க்கும் நான்கு breakpoints கிடைக்கும். அவற்றில் ஒன்றை recent messages-க்கு பயன்படுத்தவும்.

தாமதிக்கக்கூடிய அனைத்தையும் Batches API-க்கு அனுப்புங்கள்

Input மற்றும் output இரண்டிற்கும், “All usage is charged at 50% of the standard API prices”. Batch processing asynchronous முறையில் நடைபெறும். “with most batches finishing in less than 1 hour”. அனைத்து requests-உம் முடிந்ததும் அல்லது 24 hours கடந்ததும், இதில் முதலில் எது நிகழ்கிறதோ அதன்போது results கிடைக்கும். இது வழக்கமான நிலை மட்டுமே; உத்தரவாதம் அல்ல.

processing_status என்பதில் ended எனக் காட்டும் வரை poll செய்யுங்கள். errored, canceled அல்லது expired என்பதைத் திருப்பி அனுப்பும் requests-க்கு கட்டணம் விதிக்கப்படாது. spend cap-ஐ பயன்படுத்தினால் ஒரு முக்கிய விதிவிலக்கு உள்ளது: “batches may go slightly over your Workspace's configured spend limit.”

இந்த discounts ஒன்றுடன் ஒன்று சேரும். மேலும், ஒரு batch முடிவடைய five minutes-ஐ விட அதிக நேரம் ஆகலாம். எனவே, ஒரே context-ஐ பகிரும் batches-க்கு one-hour cache-ஐ பயன்படுத்த documentation பரிந்துரைக்கிறது. பணியைப் பிரியுங்கள்: ஒருவர் அல்லது webhook காத்திருக்கும் எதுவும் live path-ல் இருக்க வேண்டும். nightly digest அல்லது முந்தைய நாளின் log classification போன்றவை half price-ல் batch-க்கு அனுப்பப்பட வேண்டும்.

ஒவ்வொரு response-இன் usage fields-ஐ உங்கள் சொந்த store-ல் பதிவு செய்யவும்

நீங்கள் பதிவு செய்யாத செலவை எந்த job-க்கும் ஒதுக்க முடியாது. ஒவ்வொரு 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-ல் சேர்க்கவும். அந்த row-க்கு உங்கள் job name-ஐ tag ஆகக் குறிப்பிடவும். ஒரு வாரம் கழித்து எந்த job செலவழிக்கிறது, எது busy போல மட்டும் தெரிகிறது என்பதைத் தெரிவிக்க முடியும். cache_read-ஐ கண்காணிக்கவும்: zeros மட்டும் உள்ள column, self-hosted agent-ல் ஏற்படும் பொதுவான cost bug ஆகும்.

ஒரு field-ஐ தவறாகப் புரிந்துகொள்வது எளிது. input_tokens என்பது கடைசி cache breakpoint-க்குப் பிறகு உள்ள tokens-ஐ மட்டும் எண்ணுகிறது. எனவே உண்மையான prompt size total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens ஆகும். பெரிய prompt-க்கு agent input_tokens: 400 என்று தெரிவிப்பது அது குறைந்த செலவுடையது என்று பொருளல்ல; மீதமுள்ள பகுதி cache-ல் இருந்து வந்தது.

அனுப்புவதற்கு முன் count செய்யவும். Token counting இலவசம்; அதன் rate limits message creation-க்கான rate limits-இலிருந்து தனியாக இருக்கும். ஆகவே, attachment அளவுக்கு அதிகமாக இருந்தால் பணம் செலுத்திய பிறகு தெரிந்துகொள்வதற்குப் பதிலாக count_tokens மூலம் அதை மறுக்கவும். பெறப்படும் முடிவு ஒரு estimate ஆகும். எனவே ஒவ்வொரு model-க்கும் மீண்டும் அளவிடவும்; மற்றொரு vendor-ன் tokenizer-ல் பெற்ற count-ஐ ஒருபோதும் மீண்டும் பயன்படுத்த வேண்டாம். Claude Opus 4.7 மற்றும் அதற்குப் பிறகான Opus models, Claude Fable 5, Claude Sonnet 5 ஆகியவை புதிய tokenizer-ஐப் பயன்படுத்துகின்றன. இது ஒரே text-க்கு "சுமார் 30% அதிக tokens உருவாக்குகிறது". Claude Sonnet 4.6 மற்றும் அதற்கு முந்தைய versions, அவற்றில் 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[]= ஆகியவற்றை ஏற்கின்றன. ஒரு வரம்பு உள்ளது: "தனிப்பட்ட accounts-க்கு Admin API கிடைக்காது."

கடைசி parameter-ஐப் பயன்படுத்துவது attribution-க்கு எளிய வழியாகும்: ஒவ்வொரு job-க்கும் தனித்தனி API key வழங்கி, api_key_ids[] மூலம் filter செய்து, group_by[]=api_key_id மூலம் ஒவ்வொரு key-க்கும் தனித்தனியாக report-ஐப் பிரிக்கவும். Filter plural ஆகும்; grouping dimension singular ஆகும். VPS-ல் முதல் Claude API app அவற்றைக் கையாளும் முறையைப் போல, keys-ஐ code-ல் வைக்காமல் environment-ல் வைத்திருக்கவும்.

Loop-ஐ வரம்புக்குள் வைத்திருங்கள்; வேறு எதுவும் அதைச் செய்யாது

இங்கு வரம்பிட்ட iteration எண்ணிக்கை கட்டாயம். 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)

மேலே உள்ள எந்த ceiling-உம் இதைச் செய்யாது: max_tokens ஒரு response-ஐ மட்டும் வரம்பிடுகிறது; model-க்கு task budget குறித்து அறிவுறுத்தல் மட்டுமே வழங்கப்படுகிறது. Hosted product ஒன்று இதே நிலையில் உங்களைத் தடுத்து நிறுத்தும். ஒரே turn-ல் அதிக tool calls செய்யப்பட்டால் session-ஐ நிறுத்தும் Claude-ன் ஒரே turn-க்கான tool calls வரம்பு இதற்கு உதாரணம். ஆனால் நீங்கள் எழுதும் loop-க்கு, நீங்கள் ஒரு backstop சேர்க்கும் வரை இத்தகைய பாதுகாப்பு இயல்பாக இருக்காது.

Process-க்கு வெளியிலும் ஒரு இரண்டாவது தடையை அமைக்கவும். Permanent process-க்கு பதிலாக systemd timer மூலம் job-ஐ இயக்கி, அதன் service unit-ல் RuntimeMaxSec= அமைக்கவும். RuntimeMaxSec=600 அமைத்தால், hung run பத்து நிமிடங்களுக்குப் பிறகு நிறுத்தப்படும்; அதை நீங்கள் கவனிக்கும் வரை தொடர்ந்து இயங்காது. systemd service மற்றும் timer ஆக ஒரு program-ஐ இயக்குதல் unit files பற்றிய விவரங்களை வழங்குகிறது. ஒரு run என்ன செய்தது என்பதை journalctl -u triage-agent.service --since "1 hour ago" மூலம் பார்க்கவும்.

Retries-க்கும் வரம்பு அமைக்கவும். இல்லையெனில், முடிவில்லாமல் retry செய்யும் handler ஒவ்வொரு attempt-க்கும் கட்டணம் உருவாக்கும். 429 அல்லது 500 போன்ற நிலைகளுக்கு backoff உடன் சில retries பொருத்தமானவை. 400 நிலைக்கு retries தேவையில்லை; அதே request மீண்டும் அதே முறையில் தோல்வியடையும்.

AI agent-க்கான செலவுக் கட்டுப்பாடு உங்கள் சொந்த usage எண்ணிக்கைகளைப் பார்ப்பதிலிருந்து தொடங்குகிறது

எப்போதும் இயங்கும் agent-க்கான செலவை யாராலும் முன்கூட்டியே சொல்ல முடியாது. அதன் செலவு, ஒரு run-க்கான tokens எண்ணிக்கையை ஒரு நாளில் நடைபெறும் runs எண்ணிக்கையால் பெருக்குவதன் அடிப்படையில் அமையும். இந்த இரு மதிப்புகளும் உங்கள் பயன்பாட்டைப் பொறுத்தவை. அதை ஒருமுறை இயக்கி, நீங்கள் பதிவு செய்த usage row-ஐப் பார்க்கவும். பின்னர் அதை உங்கள் schedule-ன் அடிப்படையில் பெருக்கவும். இரண்டு நாட்களுக்குப் பிறகு cost report-ஐ அந்தக் கணக்குடன் ஒப்பிடவும். இரண்டும் பொருந்தவில்லை என்றால், காரணம் பெரும்பாலும் செயலிழந்த cache அல்லது நீங்கள் கருதியதைவிட நீண்ட நேரம் இயங்கிய loop ஆக இருக்கும்.

இங்கு API key இருப்பதாகக் கருதப்படுகிறது. ஏனெனில் agent என்பது Messages API-ஐ அழைக்கும் உங்கள் சொந்த program ஆகும். உங்கள் சொந்த interactive பணிகளுக்கு, உங்கள் பணிமுறைக்கு ஏற்ற Claude plan எது என்பது subscription பகுதியை விளக்குகிறது. இங்கு குறிப்பிடப்பட்டுள்ள ஒவ்வொரு விலையும் limit-உம் July 2026-ல் Anthropic-ன் documentation-ஐ அடிப்படையாகக் கொண்டு சரிபார்க்கப்பட்டவை. எனவே budget உருவாக்குவதற்கு முன் pricing page-ஐ மீண்டும் படிக்கவும்.

FAQ

எப்போதும் இயங்கும் AI agent-ஐ VPS-ல் இயக்க எவ்வளவு செலவாகும்?

இரண்டு billing செலவுகள் உள்ளன; அவற்றில் ஒன்றை மட்டுமே முன்கூட்டியே கணிக்க முடியும். Server-க்கு நிலையான மாதாந்திர விலை இருக்கும். Model API token அடிப்படையில் usage-க்கு ஏற்ப கட்டணம் வசூலிக்கும். ஆகவே, ஒரு run பயன்படுத்தும் அளவை அது எத்தனை முறை இயக்கப்படுகிறது என்பதால் பெருக்கினால் செலவு கிடைக்கும். Self-hosted எப்போதும் இயங்கும் agent-க்கான எந்தத் தொகையையும் Anthropic வெளியிடவில்லை. எனவே மேற்கோளிடப்படும் எந்த எண்ணையும் ஒரு ஊகமாகக் கருதவும். ஒரு உண்மையான run-லிருந்து usage-ஐ log செய்து, அதை உங்கள் schedule-இன் அடிக்கடி இயக்கும் எண்ணிக்கையால் பெருக்கவும்.

max_tokens மற்றும் task budget ஆகியவற்றுக்கு என்ன வித்தியாசம்?

max_tokens நடைமுறைப்படுத்தப்படும் limit; அது model-க்கு தெரிவதில்லை. இது ஒரு request-ன் output-ஐ கட்டுப்படுத்தும்; இதில் thinking-உம் அடங்கும். அந்த limit எட்டப்பட்டால் stop_reason: "max_tokens" கிடைக்கும். Task budget இதற்கு மாறானது. அந்த எண்ணிக்கை model-க்கு தெரிவிக்கப்படும்; model அதனை அடிப்படையாகக் கொண்டு agentic loop-ஐ வேகப்படுத்தும். ஆனால் "Task budgets are a soft hint, not a hard cap". நடைமுறைப்படுத்தப்படும் limit இன்னும் max_tokens ஆகும்.

எனது agent-க்கு cache_read_input_tokens எப்போதும் zero ஆக இருப்பதற்கான காரணம் என்ன?

Calls-க்கு இடையில் prefix மாறுவதாலோ, cache செய்ய அது மிகவும் குறுகியதாக இருப்பதாலோ இது நிகழ்கிறது. System prompt-ல் timestamp அல்லது run id-ஐ interpolate செய்வதே வழக்கமான காரணம். Cache, prefix-ஐ அடிப்படையாகக் கொண்டு உருவாக்கப்படுகிறது. எனவே எந்த ஒரு byte மாற்றமும் அதற்குப் பிறகு உள்ள அனைத்தையும் invalid ஆகும். Tool definitions அல்லது effort value-ஐ மாற்றினாலும் இதே விளைவு ஏற்படும். இல்லையெனில் காரணம் size ஆகும். குறுகிய prompts cache செய்யப்படாது; error எதுவும் திருப்பி அனுப்பப்படாது.

AI agent முடிவில்லாமல் loop செய்வதை எவ்வாறு நிறுத்துவது?

உங்கள் loop code-ல் iterations-ஐ எண்ணி, ஒரு நிலையான maximum-ஐ அடைந்ததும் நிறுத்தவும். ஏனெனில் max_tokens ஒரு response-ஐ மட்டுமே கட்டுப்படுத்தும்; agent பல responses உருவாக்கும். Process-க்கு வெளியே wall-clock limit ஒன்றைச் சேர்க்கவும். RuntimeMaxSec= அமைக்கப்பட்ட systemd timer-லிருந்து job-ஐ தொடங்கவும். இதனால் சிக்கி நிற்கும் run திட்டமிட்ட நேரத்தில் kill செய்யப்படும். Retries-க்கும் limit அமைக்கவும். ஒவ்வொரு retry attempt-க்கும் billing செய்யப்படும்.

ஒரே Claude API key-க்கு spending limit அமைக்க முடியுமா?

Documented spend limit ஒரு key-க்கு அல்ல, workspace-க்கு பொருந்தும். எனவே agent-க்கென தனி workspace ஒன்றை வழங்கி, அங்கு அதன் monthly spend-க்கு limit அமைக்கவும். "You cannot set limits on the Default Workspace". Spend notifications-ஐச் சேர்க்கவும். இதனால் ஒரு threshold எட்டப்படும்போது முதலில் உங்களுக்கு alert வரும். Attribution-க்காக ஒவ்வொரு job-க்கும் தனித்தனி key வழங்கவும். பின்னர் group_by[]=api_key_id மூலம் usage report-ஐ group செய்யவும்.