VPS-இல் AI agent செலவைக் குறைப்பது எப்படி?

எப்போதும் இயங்கிக்கொண்டிருக்கும் AI agent-ன் செலவைக் கட்டுப்படுத்துவது எப்படி

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

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

ஏன் ஒரு unattended agent வேறுபட்ட cost shape கொண்டுள்ளது

ஒரு interactive session-இல் மனிதத் தலையீடு இருக்கும். Model தவறான பாதையில் சென்றாலோ அல்லது 40,000 வரிகள் கொண்ட log கோப்பை வாசித்தாலோ, அதைப் பார்த்துக் கொண்டிருக்கும் நபர் அதைத் தடுத்து நிறுத்த முடியும். ஆனால், ஒரு unattended agent-க்கு அத்தகைய கட்டுப்பாடு இல்லை: அது loop முடியும் வரை இயங்கும், அதன் பிறகு ஒரு timer அதை மீண்டும் தொடங்கும்.

Frequency என்பது மக்கள் கவனிக்கத் தவறும் ஒரு காரணியாகும். ஐந்து நிமிட இடைவெளியில் இயங்கும் ஒரு job, ஒரு நாளைக்கு 288 முறையும், ஒரு மாதத்திற்கு சுமார் 8,640 முறையும் இயங்கும். ஒரு முறை இயங்குவதற்கு எவ்வளவு செலவானாலும், அந்தத் தொகையை நீங்கள் பெருக்க வேண்டும். பல "always-on" agents எப்போதும் இயங்க வேண்டிய அவசியமில்லை. அவை ஒரு குறிப்பிட்ட நிமிடங்களுக்குள் பதிலளிக்க வேண்டும், அதுவே ஒரு schedule ஆகும்.

ஒரு chat window செய்யாத சில விஷயங்களுக்கும் agent கட்டணம் செலுத்துகிறது.

• Tool definitions ஒவ்வொரு request-இன் போதும் சேர்க்கப்படுகின்றன. 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 அதன் schemas-ஐயும் அந்தச் செலவில் சேர்க்கும் (MCP என்பது model context protocol ஆகும்).
• Tool results என்பவை input tokens ஆகும். 8,000 வரிகளை அச்சிடும் ஒரு command, அடுத்த request-இல் 8,000 வரிகளையும், அந்த turn-இல் உள்ள அடுத்தடுத்த ஒவ்வொரு request-இலும் அந்த வரிகளையும் சேர்க்கும்.
• Fetched pages என்பவை input tokens ஆகும். சராசரி 10 kB அளவுள்ள web page தோராயமாக 2,500 tokens ஆகும், 500 kB அளவுள்ள research PDF தோராயமாக 125,000 tokens ஆகும். max_content_tokens உரையை (text) மட்டுமே சுருக்கும் (truncate), ஏனெனில் இது "applies to text content, not to binary content such as PDFs". PDF கோப்புகளை max_uses மற்றும் allowed_domains மூலம் கையாளவும்.
• Web search என்பது ஒவ்வொரு search-க்கும் கணக்கிடப்படுகிறது, அதாவது 1,000 searches-க்கு $10 என்ற வீதத்தில், எத்தனை முடிவுகள் வந்தாலும் சரி. பிழை (error) ஏற்படும் search-களுக்குக் கட்டணம் வசூலிக்கப்படாது.

இவை ஒவ்வொன்றும் ஒருமுறை மட்டும் அதிக செலவு கொண்டவை அல்ல. இவை அனைத்தும் 8,640 முறை இயங்கும்போது அதிக செலவு கொண்டவையாக மாறுகின்றன.

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

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

Task budget என்பது ஒரு advisory மட்டுமே. task_budget என்பது output_config-க்குள் உள்ளது. இது thinking, tool calls, tool results மற்றும் output ஆகியவற்றைத் தவிர்த்து, முழு agentic loop-க்கும் model-க்கு எத்தனை tokens உள்ளன என்பதைக் கூறுகிறது.

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 ஒரு mid-action-ல் இந்த எல்லையைத் தாண்டலாம், ஆனால் output-க்கான enforced limit இன்னும் max_tokens ஆகவே இருக்கும். "The countdown is visible only to the model", மேலும் responses-ல் remaining-budget field இருக்காது. ஏற்றுக்கொள்ளப்படும் குறைந்தபட்ச task_budget.total 20,000 tokens ஆகும், அதைவிடக் குறைவாக இருந்தால் 400 error வரும். வேலையைச் செய்ய மிகக் குறைந்த budget இருந்தால், model வேலையைச் சுருக்கிக் கொள்ளும் அல்லது முன்கூட்டியே நிறுத்திக்கொள்ளும் (refusal-like behaviour).

ஒரு விஷயம் பணத்தைச் சேமிப்பதற்குப் பதிலாக செலவை அதிகரிக்கும். உங்கள் client ஒவ்வொரு follow-up request-லும் task_budget.remaining-ஐக் குறைத்தால், அதில் உள்ள மாற்றப்பட்ட மதிப்பு அந்த prefix-ஐ உள்ளே கொண்ட எந்தவொரு cache-ஐயும் invalidates செய்யும். முதல் request-லேயே இதை ஒருமுறை மட்டும் set செய்யவும்.

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-ஐ set செய்யவும். "You cannot set limits on the Default Workspace", மற்றும் "Organization-wide limits எப்போதும் பொருந்தும், workspace limits அவற்றின் கூட்டுத்தொகையை விட அதிகமாக இருந்தாலும் கூட". Cap-ஐ அடைவதற்கு முன்பே உங்களுக்குத் தெரியப்படுத்த spend notifications-ஐச் சேர்க்கவும்.

Per-job model choice, and what effort actually changes

Model choice என்பது ஒவ்வொரு 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 and $5 ஆகும். Sonnet 5 தற்போதைக்கு அதன் sticker price-ஐ விடக் குறைவாக உள்ளது, ஏனெனில் "Introductory pricing of $2/$10 per million input/output tokens is in effect through August 31, 2026". Log lines-களை மட்டும் classify செய்யும் ஒரு step-க்கு Opus தேவையில்லை.

Effort என்பது இரண்டாவது காரணியாகும் (lever). output_config.effort ஆனது low, medium, high, xhigh மற்றும் max ஆகியவற்றை ஏற்றுக்கொள்கிறது; இதன் default மதிப்பு high ஆகும். எனவே, high-ஐத் தெளிவாக (explicitly) குறிப்பிடுவது, அதைத் தவிர்த்து விடுவதற்குச் சமமாகும். Effort-ஐக் குறைப்பது reasoning length-ஐ விட அதிகப் பயனைத் தரும்: documentation-ன் படி, இது Claude குறைவான tool calls-களைப் பயன்படுத்தவும், பல operations-களை ஒன்றிணைக்கவும் செய்யும். ஒரு agent-ஐப் பொறுத்தவரை, இதுவே மிகப்பெரிய சேமிப்பாகும், ஏனெனில் ஒரு tool call தவிர்க்கப்பட்டால், அந்த முழு request-உமே தவிர்க்கப்படுகிறது.

இதிலுள்ள சிக்கல் என்னவென்றால், effort மதிப்பானது cache-உடன் முரண்படுகிறது. ஒவ்வொரு request-க்கும் இடையில் இந்த மதிப்பினை மாற்றுவது prompt caching-ஐச் செயலிழக்கச் செய்யும் (invalidate). ஆவணப்படுத்தப்பட்ட உதாரணத்தில், request 2-இல் cache_read_input_tokens: 3546 பதிவாகியுள்ளது; request 3-இல், effort மதிப்பானது high-லிருந்து medium-க்கு மாற்றப்பட்டபோது, cache_creation_input_tokens மதிப்பு 3546 மற்றும் cache_read_input_tokens மதிப்பு 0 எனப் பதிவாகியுள்ளது. எனவே, வெவ்வேறு workloads-களுக்கு இடையில் effort மதிப்பினை மாற்றலாம், ஆனால் ஒரே cached conversation-க்குள் அதை ஒருபோதும் மாற்றக்கூடாது. Cache-ஐப் பாதிக்காமல் ஆழத்தை (depth) மாற்ற விரும்பினால், அதை prompt-இல் குறிப்பிடவும்: புதிய user message-இல் "Answer directly without deliberating." போன்ற ஒரு வரியைப் பயன்படுத்துவது, முந்தைய breakpoints-களை அப்படியே வைத்திருக்கும்.

Thinking tokens-களுக்கு output rates-இல் கட்டணம் வசூலிக்கப்படும் மற்றும் அவை max_tokens-இல் கணக்கிடப்படும். அதனால்தான் ஒரு truncated answer என்பது, thinking செயல்முறை பட்ஜெட்டைத் தீர்த்துவிட்டது என்பதைக் குறிக்கலாம். எண்ணிக்கையைப் பெற usage.output_tokens_details.thinking_tokens-ஐப் படிக்கவும். What actually fills a Claude token bill என்பது விரிவான விளக்கத்தைத் தருகிறது.

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

Five-minute cache-இல் ஒரு cache write, அடிப்படை input விலையை விட 1.25 மடங்கு செலவாகும். One-hour cache-இல் இது 2 மடங்கு செலவாகும். Cache read என்பது 0.1 மடங்கு மட்டுமே என்பதால், "5-minute duration-இல் ஒரு cache read செய்தாலே (1.25x write) லாபமாகிவிடும், அல்லது 1-hour duration-இல் இரண்டு cache reads செய்தாலே (2x write) லாபமாகிவிடும்".

இது ஏன் எப்போதும் இயங்கிக்கொண்டிருக்கும் (always-on) agent-களுக்கு ஏற்றது என்பதை ஒரு வரி விளக்குகிறது: "cached content பயன்படுத்தப்படும் ஒவ்வொரு முறையும், கூடுதல் செலவின்றி cache refresh செய்யப்படுகிறது." Five-minute cache-ஐப் பயன்படுத்தி ஒவ்வொரு இரண்டு நிமிடத்திற்கும் ஒரு job இயங்கினால், ஒரு single 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 எழுதப்படும், ஆனால் எந்த cache hit-உம் கிடைக்காது. ஒரே மாதிரியான calls-இல் usage.cache_read_input_tokens மதிப்பு 0 ஆக இருந்தால் அதுவே இதற்கான அறிகுறி. நிலையற்ற (volatile) உரையை புதியest user message-க்குள் நகர்த்தவும்.

மிகக் குறுகிய prefix. ஒவ்வொரு model-க்கும் ஒரு குறைந்தபட்ச cacheable length உள்ளது. அதற்கு கீழே இருந்தால், request caching இல்லாமல் process செய்யப்படும் மற்றும் "no error is returned". Claude Opus 4.8 மற்றும் Claude Sonnet 5 ஆகியவற்றில் 1,024 tokens, மற்றும் Claude Haiku 4.5-இல் 4,096 tokens என இந்த அளவுகள் உள்ளன. எனவே, ஒரு job-ஐ Sonnet-லிருந்து Haiku-விற்கு மாற்றும்போது, caching அமைதிப்பயனாக (silently) அணைக்கப்படலாம்.

lookback அளவைத் தாண்டும் conversation. "Lookback window என்பது 20 blocks ஆகும்." system ஒவ்வொரு breakpoint-இலும் அதிகபட்சமாக 20 positions-ஐ மட்டுமே சரிபார்க்கும். ஆவணப்படுத்தப்பட்ட உதாரணத்தில், block 35-இல் breakpoint கொண்ட 35 blocks உடைய ஒரு turn, block 35 முதல் 16 வரை சரிபார்க்கும். முந்தைய turn-இன் block 15 உள்ளே வராது என்பதால், அங்கு cache hit கிடைக்காது. ஒவ்வொரு turn-இலும் பல tool-use மற்றும் tool-result blocks-ஐச் சேர்க்கும் ஒரு agent, இரண்டு அல்லது மூன்று turns-இல் 20-ஐத் தாண்டிவிடும். ஒவ்வொரு request-க்கும் உங்களுக்கு நான்கு breakpoints கிடைக்கும், எனவே ஒன்றை சமீபத்திய messages-க்காகப் பயன்படுத்தவும்.

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

Input மற்றும் output ஆகிய இரண்டிற்கும் "சாதாரண API விலையில் 50% மட்டுமே கட்டணமாக வசூலிக்கப்படும்". Batch processing என்பது asynchronous முறையில் இயங்கும். "பெரும்பாலான batches 1 மணி நேரத்திற்குள்ளேயே முடிந்துவிடும்". அனைத்து requests-களும் முடிந்தவுடன் அல்லது 24 மணி நேரத்திற்குப் பிறகு, இதில் எது முதலில் வருகிறதோ அப்போது முடிவுகள் கிடைக்கும். இது ஒரு பொதுவான நிலை மட்டுமே, உத்தரவாதம் அல்ல.

processing_status ஆனது ended என்று மாறும் வரை Poll செய்யவும். errored, canceled அல்லது expired ஆகியவற்றைத் திருப்பித் தரும் requests-களுக்குக் கட்டணம் வசூலிக்கப்படாது. நீங்கள் ஒரு spend cap-ஐப் பயன்படுத்துகிறீர்கள் என்றால், "batches உங்கள் Workspace-ன் கட்டமைக்கப்பட்ட spend limit-ஐ விடச் சற்று அதிகமாகச் செல்லக்கூடும்" என்பதைக் கவனத்தில் கொள்ளவும்.

தள்ளுபடிகள் ஒன்றன் மேல் ஒன்றாகக் கணக்கிடப்படும் (stack). ஒரு batch ஐந்து நிமிடங்களுக்கு மேல் எடுத்துக்கொள்ளக்கூடும் என்பதால், ஒரே context-ஐப் பகிரும் batches-களுக்கு ஒரு மணி நேர cache முறையைப் பயன்படுத்துமாறு ஆவணங்கள் பரிந்துரைக்கின்றன. எனவே பணிகளைப் பிரித்துச் செய்யவும்: ஒரு நபர் அல்லது 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-க்கும் உங்கள் job name-ஐ tag செய்து, ஒரு JSON-lines file-ல் ஒரு row-ஆகச் சேர்க்கவும். ஒரு வாரத்திற்குப் பிறகு, எந்த job அதிக செலவு செய்கிறது மற்றும் எந்த job வெறும் வேலையாகத் தெரிகிறது என்பதை நீங்கள் அறியலாம். cache_read-ஐக் கவனிக்கவும்: ஒரு column முழுவதும் zeros இருப்பது, 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-க்கு input_tokens: 400 என்று ஒரு agent report செய்தால், அது மலிவானது அல்ல: மீதமுள்ளவை cache-லிருந்து வந்தவை.

அனுப்புவதற்கு முன்பே கணக்கிடுங்கள். 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-களை உருவாக்கும்". 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-லும் 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 trick: ஒவ்வொரு job-க்கும் தனித்தனி API key வழங்கவும், api_key_ids[] மூலம் filter செய்யவும், மற்றும் group_by[]=api_key_id மூலம் report-ஐ key வாரியாகப் பிரிக்கவும். Filter என்பது plural, grouping dimension என்பது singular. a first Claude API app on a VPS கையாளும் முறையைப் போலவே, keys-களை code-ல் வைக்காமல் environment-ல் வைத்திருக்கவும்.

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 cost control starts with reading your own numbers

எப்போதும் இயங்கிக்கொண்டிருக்கும் (always-on) ஒரு agent-ன் செலவு எவ்வளவு என்பதை யாராலும் துல்லியமாகக் கூற முடியாது. ஏனெனில், செலவு என்பது ஒரு run-க்கான tokens எண்ணிக்கையை, ஒரு நாளில் நடக்கும் total runs எண்ணிக்கையால் பெருக்குவதன் மூலம் கணக்கிடப்படுகிறது. இந்த இரண்டு காரணிகளும் உங்கள் கட்டுப்பாட்டில்தான் உள்ளன. ஒருமுறை agent-ஐ இயக்கி, நீங்கள் log செய்த 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

VPS-இல் always-on AI agent இயக்குவதற்கு எவ்வளவு செலவாகும்?

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

max_tokens மற்றும் task budget ஆகியவற்றிற்கு இடையிலான வேறுபாடு என்ன?

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

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

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

ஒரு AI agent முடிவில்லாமல் loop ஆவதைத் தடுப்பது எப்படி?

உங்கள் loop code-இல் iterations எண்ணிக்கையைத் தீர்மானித்து, ஒரு குறிப்பிட்ட maximum மதிப்பிற்குப் பிறகு நிறுத்தவும், ஏனெனில் max_tokens என்பது ஒரு response-ஐ மட்டுமே கட்டுப்படுத்தும், ஆனால் ஒரு agent பலமுறை இயங்கும். process-க்கு வெளியே ஒரு wall-clock limit-ஐச் சேர்க்கவும்: RuntimeMaxSec= அமைக்கப்பட்ட systemd timer மூலம் வேலையைத் தொடங்கவும், இதனால் ஒரு wedged run குறிப்பிட்ட நேரத்தில் நிறுத்தப்படும். Retries எண்ணிக்கையையும் கட்டுப்படுத்தவும், ஏனெனில் ஒவ்வொரு retry loop-உம் கட்டணத்தை உண்டாக்கும்.

ஒரு தனி Claude API key-க்கு spending limit நிர்ணயிக்க முடியுமா?

ஆவணப்படுத்தப்பட்ட spend limit என்பது ஒரு key-க்காக அல்ல, workspace-க்காக ஆகும். எனவே agent-க்குத் தனியாக ஒரு workspace உருவாக்கி, அதன் மாதச் செலவை அங்கேயே கட்டுப்படுத்தவும். "You cannot set limits on the Default Workspace". ஒரு threshold எட்டும்போது உங்களுக்குத் தெரியப்படுத்த spend notifications-ஐச் சேர்க்கவும். பயன்பாட்டுத் தரவை (usage report) group_by[]=api_key_id மூலம் குழுவாக்க, ஒவ்வொரு வேலைக்கும் தனித்தனி key-களை வழங்கவும்.