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

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

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

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

Unattended agent-ன் செலவு அமைப்பு ஏன் மாறுபடுகிறது

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

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

ஒரு chat window-க்கு இல்லாத சில கூடுதல் செலவுகள் agent-க்கு உண்டு.

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

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

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

max_tokens கட்டாயப்படுத்தப்படுகிறது. இது ஒரு கோரிக்கையின் (request) மொத்த வெளியீடு, சிந்தனை மற்றும் பதில் உரை ஆகிய அனைத்திற்கும் விதிக்கப்படும் ஒரு கடினமான வரம்பு (hard cap) ஆகும். Claude இதைத் தாண்டி ஒருபோதும் உருவாக்காது, மேலும் இந்த எண்ணை மாதிரியால் (model) பார்க்க முடியாது. இதை அடையும்போது stop_reason: "max_tokens" பிழை ஏற்படும் மற்றும் பதில் பாதியிலேயே துண்டிக்கப்படும். ஏஜெண்டுகளுக்கான சிக்கல் என்னவென்றால்: tool-use லூப்பில் உள்ள ஒவ்வொரு கோரிக்கையும் அதன் சொந்த max_tokens-ஐக் கொண்டிருக்கும், எனவே இது ஒரு பதிலுக்கு மட்டுமே கட்டுப்படும், முழு பணிக்கும் அல்ல. 4,000 டோக்கன்களில் பத்து tool அழைப்புகள் என்பது ஒரு சுழற்சிக்கு 40,000-டோக்கன் வரம்பாகும்.

Task budget என்பது ஒரு அறிவுரை மட்டுமே. task_budget என்பது output_config-க்குள் அமர்ந்து, முழு ஏஜென்ட் லூப்பிற்கும் (agentic loop) எத்தனை டோக்கன்கள் உள்ளன என்பதை மாதிரிக்குத் தெரிவிக்கிறது; இதில் சிந்தனை, tool அழைப்புகள், tool முடிவுகள் மற்றும் வெளியீடு ஆகியவை அடங்கும்.

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 என்பது ஒரு மென்மையான குறிப்பு, கடினமான வரம்பு அல்ல." ஒரு செயலின் நடுவில் Claude இதை மீறக்கூடும், ஆனால் வெளியீட்டின் மீதான கட்டாய வரம்பு இன்னும் max_tokens ஆகவே இருக்கும். "இந்தக் கணக்கீடு மாதிரிக்கு மட்டுமே தெரியும்", மேலும் பதில்களில் மீதமுள்ள பட்ஜெட் குறித்த விவரங்கள் இருக்காது. குறைந்தபட்சமாக ஏற்றுக்கொள்ளப்படும் task_budget.total என்பது 20,000 டோக்கன்கள் ஆகும், அதற்கு குறைவாக இருந்தால் 400 பிழை திரும்ப வரும். பணிக்குத் தேவையானதை விட பட்ஜெட் மிகக் குறைவாக இருந்தால், மாதிரி மறுப்பது போன்ற செயல்களைச் செய்யும், எனவே மாதிரி பணியின் அளவைக் குறைக்கும் அல்லது பாதியிலேயே நிறுத்திவிடும்.

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

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 பொருந்தாது, எனவே Claude Code session detached in tmux என்பது session பராமரிப்பையே சார்ந்துள்ளது.

மூன்றாவது வரம்பு Claude Console-ல் உள்ளது: ஏஜெண்டிற்கு அதன் சொந்த workspace-ஐ வழங்கி, அதில் மாதாந்திர செலவு வரம்பு மற்றும் நிமிடத்திற்கு இத்தனை கோரிக்கைகள் (per-minute rate limits) என அமைக்கவும். "Default Workspace-க்கு நீங்கள் வரம்புகளை அமைக்க முடியாது", மேலும் "Workspace வரம்புகள் அதிகமாக இருந்தாலும், நிறுவனம் தழுவிய (Organization-wide) வரம்புகளே எப்போதும் பொருந்தும்". வரம்பை எட்டுவதற்கு முன்பே உங்களை எச்சரிக்க, செலவு அறிவிப்புகளை (spend notifications) சேர்க்கவும்.

ஒவ்வொரு பணிக்கும் மாடல் தேர்வு மற்றும் முயற்சியின் தாக்கம்

மாடல் தேர்வு என்பது ஒவ்வொரு பணிக்கும் தனித்தனியாக எடுக்கப்பட வேண்டிய முடிவாகும். ஜூலை 2026 நிலவரப்படி, பத்து லட்சம் 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-ன் தற்போதைய விலை அதன் அடிப்படை விலையை விடக் குறைவாக உள்ளது, ஏனெனில் "ஆகஸ்ட் 31, 2026 வரை பத்து லட்சம் input/output tokens-க்கு $2/$10 என்ற அறிமுக விலை அமலில் உள்ளது". log lines-ஐ வகைப்படுத்தும் ஒரு பணிக்கு Opus தேவையில்லை. அதிகப்படியான பணிகளைச் சமாளிக்க இலவச ஒதுக்கீடு எதுவும் இல்லை, ஏனெனில் Claude API-ல் இலவச அடுக்கு இல்லை, பதிவு செய்யும்போது வழங்கப்படும் சிறிய credit மட்டுமே உள்ளது.

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

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

Thinking tokens-க்கான கட்டணம் output விகிதத்தில் கணக்கிடப்பட்டு max_tokens-ல் கழிக்கப்படும், இதனால்தான் ஒரு பதில் பாதியிலேயே நின்றால், thinking செயல்முறை அந்த வரம்பை முழுமையாகப் பயன்படுத்தியிருக்கலாம் என்று அர்த்தம். அந்த எண்ணைப் பார்க்க usage.output_tokens_details.thinking_tokens-ஐப் படிக்கவும். Claude token கட்டணத்தை எது தீர்மானிக்கிறது என்பது குறித்த கட்டுரை, இந்த அளவீட்டை விரிவாக விளக்குகிறது.

நிலையான முன்னொட்டை (stable prefix) cache செய்யவும், அதைத் தற்செயலாகச் சிதைப்பதைத் தவிர்க்கவும்

ஐந்து நிமிட cache-க்கு ஒரு cache write என்பது அடிப்படை உள்ளீட்டு விலையை விட 1.25 மடங்கு, ஒரு மணிநேர cache-க்கு 2 மடங்கு செலவாகும். ஒரு cache read என்பது 0.1 மடங்கு செலவாகும், எனவே "5 நிமிட காலத்திற்கு ஒருமுறை cache read செய்தாலே cache லாபகரமானது (1.25x write), அல்லது 1 மணிநேர காலத்திற்கு இரண்டு முறை read செய்தாலே போதுமானது (2x write)".

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

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

மாறும் முன்னொட்டு. "Cache முன்னொட்டுகள் பின்வரும் வரிசையில் உருவாக்கப்படுகின்றன: tools, system, பிறகு messages." அந்த வரிசையில் முன்னதாக ஏற்படும் எந்தவொரு byte மாற்றமும் அதற்குப் பின் உள்ள அனைத்தையும் செல்லாததாக்கிவிடும், மேலும் tool definitions-ஐத் திருத்துவது முழு cache-ஐயும் செல்லாததாக்கும். சிஸ்டம் ப்ராம்ப்டில் (system prompt) timestamp அல்லது run id-ஐச் சேர்ப்பதுதான் பெரும்பாலும் நாமே செய்துகொள்ளும் தவறு: ஒவ்வொரு கோரிக்கையும் (request) வெவ்வேறு முன்னொட்டைக் கொண்டிருக்கும், 1.25x விலையில் புதிய பதிப்பை எழுதும், எதையும் மீண்டும் படிக்காது. ஒரே மாதிரியான அழைப்புகளின் போது usage.cache_read_input_tokens பூஜ்ஜியமாகக் (0) காட்டப்படுவது இதற்கான அறிகுறியாகும். மாறக்கூடிய உரையை (volatile text) மிகப்புதிய பயனர் செய்தியில் (user message) நகர்த்தவும்.

மிகக் குறுகிய முன்னொட்டு. ஒவ்வொரு மாடலுக்கும் குறைந்தபட்ச cacheable நீளம் உண்டு, அதற்கு கீழே உள்ள கோரிக்கைகள் cache செய்யப்படாமலேயே செயலாக்கப்படும், மேலும் "எந்தப் பிழையும் காட்டப்படாது". Claude Opus 4.8 மற்றும் Claude Sonnet 5 மாடல்களில் 1,024 tokens-ம், Claude Haiku 4.5 மாடலில் 4,096 tokens-ம் இதற்கான அளவீடுகள். எனவே, ஒரு job-ஐ Sonnet-லிருந்து Haiku-க்கு மாற்றும்போது, cache வசதி அமைதியாகச் செயலிழக்கக்கூடும்.

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

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

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

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

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

ஒவ்வொரு பதிலின் பயன்பாட்டு விவரங்களையும் உங்கள் சொந்த சேமிப்பகத்தில் பதிவு செய்யவும்

நீங்கள் பதிவு செய்யாத செலவுகளைக் கணக்கிட முடியாது. ஒவ்வொரு பதிலும் அதன் செலவு என்ன என்பதை உங்களுக்குத் தெரிவிக்கும்.

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 அழைப்பிற்கும் ஒரு வரி வீதம் JSON-lines கோப்பில் உங்கள் பணிப் பெயருடன் (job name) சேர்த்துப் பதிவு செய்யவும். ஒரு வாரம் கழித்து, எந்தப் பணி செலவை ஏற்படுத்துகிறது, எது சும்மா இயங்குகிறது என்பதை உங்களால் கண்டறிய முடியும். cache_read-ஐக் கவனிக்கவும்: self-hosted agent-களில் பூஜ்ஜியங்கள் கொண்ட நெடுவரிசை (column of zeros) என்பது மிகவும் பொதுவான செலவுப் பிழையாகும்.

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

அனுப்புவதற்கு முன்பே கணக்கிடுங்கள். Token-களைக் கணக்கிடுவது இலவசம் மற்றும் அதன் rate limits செய்தி உருவாக்கத்திலிருந்து தனிப்பட்டது, எனவே அதிக அளவுள்ள கோப்புகளை நிராகரிக்க count_tokens-ஐப் பயன்படுத்தவும்; அதை அனுப்பிவிட்டு செலவை அறிவதை விட இது சிறந்தது. இதன் முடிவு ஒரு மதிப்பீடு மட்டுமே, எனவே ஒவ்வொரு model-க்கும் தனித்தனியாக அளவிடவும்; மற்றொரு vendor-ன் tokenizer-ல் இருந்து பெறப்பட்ட எண்ணிக்கையை ஒருபோதும் பயன்படுத்த வேண்டாம். Claude Opus 4.7 மற்றும் அதற்குப் பிந்தைய Opus model-கள், Claude Fable 5 மற்றும் Claude Sonnet 5 ஆகியவை புதிய tokenizer-ஐப் பயன்படுத்துகின்றன, இது "ஒரே உரைக்கு சுமார் 30% கூடுதல் tokens-களை உருவாக்குகிறது". Claude Sonnet 4.6 மற்றும் அதற்கு முந்தையவை, Claude Haiku 4.5 உட்பட, முந்தைய tokenizer-ஐப் பயன்படுத்துகின்றன.

அதிகாரப்பூர்வமான தகவலுக்கு, Admin API பயன்பாட்டை https://api.anthropic.com/v1/organizations/usage_report/messages-லும், செலவை 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[]= ஆகியவற்றை ஏற்கும். ஒரு குறைபாடு: "தனிநபர் கணக்குகளுக்கு Admin API கிடைக்காது."

அந்த கடைசி parameter ஒரு மலிவான செலவுப் பகிர்வு தந்திரமாகும்: ஒவ்வொரு பணிக்கும் தனித்தனி API key-ஐ வழங்கவும், api_key_ids[] மூலம் வடிகட்டவும், group_by[]=api_key_id மூலம் ஒவ்வொரு key-க்கும் அறிக்கையைப் பிரிக்கவும். வடிகட்டி (filter) பன்மையில் இருக்கும், ஆனால் குழுவாக்கும் பரிமாணம் (grouping dimension) ஒருமையில் இருக்கும். VPS-ல் முதல் Claude API app-ஐ உருவாக்குவது போல, key-களைக் குறியீட்டில் (code) வைக்காமல் environment-ல் வைத்திருக்கவும்.

சுழற்சியைக் கட்டுப்படுத்துங்கள், ஏனெனில் வேறு எதுவும் அதைச் செய்யாது

இங்கே ஒரு குறிப்பிட்ட எண்ணிக்கையிலான சுழற்சி (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 ஒரு பதிலுக்கு மட்டுமே வரம்பு விதிக்கிறது, மேலும் இது ஒரு பணி வரம்பு குறித்த ஆலோசனையை மட்டுமே மாதிரியிடம் (model) வழங்குகிறது. ஒரு hosted product உங்களை இங்கேயே தடுத்து நிறுத்தும்; உதாரணமாக, ஒரே turn-ல் Claude மேற்கொள்ளும் tool calls-க்கான வரம்பு அதிகப்படியான அழைப்புகளைச் செய்யும் அமர்வை நிறுத்திவிடும். ஆனால், நீங்கள் சொந்தமாக எழுதிய சுழற்சியில், நீங்களாகவே ஒரு தடுப்பானைச் சேர்க்காதவரை அது தானாக நிற்காது.

செயல்முறைக்கு வெளியே இரண்டாவது தடுப்பானை (brake) வையுங்கள். நிரந்தரமான process-க்கு பதிலாக systemd timer மூலம் பணியை இயக்குங்கள், மேலும் அதன் service unit-ல் RuntimeMaxSec=-ஐ அமைக்கவும். RuntimeMaxSec=600-ஐப் பயன்படுத்தினால், ஒரு செயல்முறை முடங்கிப்போகும்போது, அது தொடர்ந்து இயங்காமல் பத்து நிமிடங்களுக்குப் பிறகு தானாகவே நிறுத்தப்படும். systemd service மற்றும் timer மூலம் ஒரு நிரலை இயக்குதல் என்பது unit files-ஐ உருவாக்குவது குறித்த விளக்கங்களை வழங்குகிறது. ஒரு செயல்முறை என்ன செய்தது என்பதை journalctl -u triage-agent.service --since "1 hour ago" மூலம் படித்துப் பாருங்கள்.

மீண்டும் முயற்சிக்கும் (retries) எண்ணிக்கையையும் கட்டுப்படுத்துங்கள், ஏனெனில் தொடர்ந்து முயற்சிக்கும் handler ஒவ்வொரு முயற்சிக்கும் கட்டணத்தை வசூலிக்கும். 429 அல்லது 500 பிழைகள் ஏற்படும்போது, backoff முறையைப் பயன்படுத்திச் சில முறை முயற்சி செய்யலாம். ஆனால் 400 பிழை ஏற்பட்டால், மீண்டும் முயற்சி செய்யத் தேவையில்லை; ஏனெனில் அதே கோரிக்கை மீண்டும் அதே பிழையையே தரும்.

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

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

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

FAQ

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

இரண்டு வகையான கட்டணங்கள் உள்ளன, இதில் ஒன்று மட்டுமே கணிக்கக்கூடியது. server-க்கான கட்டணம் மாதந்தோறும் நிலையானது. model API கட்டணம் token அடிப்படையில் கணக்கிடப்படுகிறது, எனவே ஒருமுறை இயங்குவதற்கு ஆகும் செலவை, அது எத்தனை முறை இயங்குகிறது என்பதோடு பெருக்கினால் மொத்த செலவு கிடைக்கும். எப்போதும் இயங்கும் self-hosted agent-க்கு Anthropic எந்தவொரு நிலையான கட்டணத்தையும் குறிப்பிடுவதில்லை, எனவே கூறப்படும் எந்தவொரு தொகையையும் ஒரு தோராயமான மதிப்பீடாகவே கருத வேண்டும். ஒருமுறை இயங்கியதற்கான Log usage-ஐ எடுத்து, உங்கள் அட்டவணைக்கு ஏற்ப பெருக்கிக் கொள்ளுங்கள்.

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

max_tokens என்பது கட்டாயப்படுத்தப்பட்ட ஒன்று, இது model-க்குத் தெரியாது. இது ஒரு கோரிக்கையின் வெளியீட்டை (சிந்தனை உட்பட) கட்டுப்படுத்துகிறது, இந்த எல்லையைத் தாண்டினால் stop_reason: "max_tokens" பிழை ஏற்படும். Task budget இதற்கு நேர்மாறானது: இந்த எண்ணிக்கை model-க்குத் தெரிவிக்கப்படுகிறது, அதற்கேற்ப agentic loop-ஐ அது அமைத்துக் கொள்ளும். ஆனால், "Task budgets என்பது ஒரு மென்மையான குறிப்பு, கடுமையான கட்டுப்பாடு அல்ல" என்பதால், கட்டாயப்படுத்தப்பட்ட எல்லை இன்னும் max_tokens ஆகவே இருக்கும்.

எனது agent-க்கு ஏன் cache_read_input_tokens எப்போதும் பூஜ்ஜியமாகக் காட்டுகிறது?

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

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

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

ஒரு Claude API key-க்கு செலவு வரம்பை (spending limit) அமைக்க முடியுமா?

ஆவணப்படுத்தப்பட்ட செலவு வரம்பு என்பது key-க்கு அல்ல, workspace-க்கு மட்டுமே பொருந்தும். எனவே, agent-க்குத் தனி workspace-ஐ உருவாக்கி, அதில் மாத செலவு வரம்பை அமைக்கவும். "Default Workspace-க்கு நீங்கள் வரம்புகளை அமைக்க முடியாது". செலவு குறித்த அறிவிப்புகளை (spend notifications) சேர்த்துக்கொள்ளுங்கள், இதன் மூலம் ஒரு குறிப்பிட்ட தொகையைத் தாண்டும்போது உங்களுக்கு எச்சரிக்கை வரும். பயன்பாட்டைக் கண்காணிக்க, ஒவ்வொரு வேலைக்கும் தனித்தனி key-ஐ வழங்கி, அதன் பயன்பாட்டு அறிக்கையை group_by[]=api_key_id மூலம் வகைப்படுத்தவும்.