ద్వారా Matt Connor 2026-07-23 · అప్‌డేట్ చేయబడింది 2026-08-13

ఎల్లప్పుడూ నడిచే AI agent ఖర్చును ఎలా నియంత్రించాలి

Q: max_tokens మరియు task budget మధ్య తేడా ఏమిటి?

max_tokens అమలు చేయబడుతుంది, కానీ model కు కనిపించదు. ఇది ఒక్క request యొక్క output ను, ఆలోచనా ప్రక్రియతో సహా, పరిమితం చేస్తుంది. ఆ పరిమితిని తాకితే stop_reason: "max_tokens" వస్తుంది. Task budget దీనికి విరుద్ధంగా ఉంటుంది: ఆ సంఖ్యను model కు తెలియజేస్తారు, model దాని ఆధారంగా agentic loop వేగాన్ని నియంత్రిస్తుంది. అయితే "Task budgets are a soft hint, not a hard cap". అమలు చేయబడే పరిమితి మాత్రం ఇప్పటికీ max_tokens.

Unattended AI agent ప్రతి loopలో ఖర్చు పెంచుతుంది. Hard caps, task budgets, prompt caching, batchingతో నియంత్రించండి; usage fieldsతో ఏ job ఎంత ఖర్చు చేసిందో తెలుసుకోండి.

ఎల్లప్పుడూ నడిచే AI agent అధిక ఖర్చు చేయకుండా ఎలా నియంత్రించాలి

VPS (virtual private server)లో AI agent ఖర్చును నియంత్రించాలంటే, agent ప్రారంభం కావడానికి ముందే పరిమితులు సెట్ చేయాలి. Agent నడుస్తున్నప్పుడు usage meter ను ఎవరూ నిరంతరం చూడరు. max_tokens తో ప్రతి response కు గరిష్ఠ పరిమితి పెట్టండి. మీ code లో loop iterations కు పరిమితి విధించండి. మారని prompt భాగాన్ని cache చేయండి. ప్రతి response యొక్క usage సంఖ్యలను log చేయండి. ఏ job ఎక్కువ ఖర్చు చేస్తుందో అప్పుడు తెలుస్తుంది. Server rental కు నెలవారీ స్థిర ధర ఉంటుంది. Model APIలో tokenల ఆధారంగా usage లెక్కించబడుతుంది. unattended loop tokenలను నిశ్శబ్దంగా ఎక్కువగా ఖర్చు చేయగలదు.

ఇది ఇప్పటికే ఉన్న agent మీకు చెందిన server నుంచి Messages APIని call చేస్తుందని భావిస్తుంది. VPSలో Claudeతో AI agent నిర్మాణంలో ఆ agentకు అవసరమైన వ్యవస్థను వివరించారు.

ఒక unattended agent ఎందుకు భిన్నమైన ఖర్చు నమూనాను కలిగి ఉంటుంది

Interactive session లో ఒక మనిషి ఉంటాడు. Model తప్పు మార్గంలో వెళ్లడం ప్రారంభించినా లేదా 40,000 లైన్ల log చదివినా, దాన్ని గమనిస్తున్న వ్యక్తి ఆపగలడు. Unattended agent కు అలాంటి నియంత్రణ ఉండదు: loop ముగిసే వరకు అది నడుస్తుంది, తరువాత timer దాన్ని మళ్లీ ప్రారంభిస్తుంది.

చాలామంది గమనించని multiplier frequency. Five-minute schedule లో నడిచే job రోజుకు 288 సార్లు, నెలకు సుమారు 8,640 సార్లు నడుస్తుంది. ఒక్క run కు అయ్యే ఖర్చును ఈ సంఖ్యతో గుణించాలి. అనేక "always-on" agents నిరంతరం నడవాల్సిన అవసరం లేదు. అవి కొన్ని నిమిషాల్లోపు సమాధానం ఇవ్వాలి, అంతే. దానికి schedule సరిపోతుంది.

Chat window లో లేని కొన్ని ఖర్చులు agent కు కూడా ఉంటాయి.

ప్రతి request తో tool definitions కూడా పంపబడతాయి. tool_choice లేదా auto తో none లో Claude Opus 4.8 కోసం 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 content ను మాత్రమే truncate చేస్తుంది. ఎందుకంటే అది "applies to text content, not to binary content such as PDFs". PDF పరిమాణాన్ని పరిమితం చేయడానికి max_uses మరియు allowed_domains ఉపయోగించండి.
Web search కు ఒక్కో search ఆధారంగా ధర నిర్ణయించబడుతుంది, 1,000 searches కు $10. ఎన్ని results వచ్చినా ధర మారదు. Error వచ్చిన search కు billing ఉండదు.

వీటిలో ఏదీ ఒక్కసారి జరిగినప్పుడు ఖరీదైనది కాదు. కానీ ఇవన్నీ 8,640 సార్లు జరిగితే ఖర్చు పెరుగుతుంది.

కఠిన పరిమితులు, సడలింపు పరిమితులు వేర్వేరు సమస్యలను పరిష్కరిస్తాయి

max_tokens అమలు చేయబడే పరిమితి. ఇది ఒక అభ్యర్థన యొక్క మొత్తం 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 చొప్పున 10 tool calls చేస్తే, ఆ turn కు 40,000-token ceiling ఉంటుంది.

Task budget సూచన మాత్రమే. task_budget అనేది output_config లో భాగంగా ఉంటుంది. మొత్తం agentic loop కోసం model వద్ద ఎన్ని tokens ఉన్నాయో ఇది సూచిస్తుంది. ఇందులో 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 ఈ పరిమితిని దాటవచ్చు. Output పై అమలు చేయబడే పరిమితి మాత్రం ఇప్పటికీ max_tokens. "Countdown model కు మాత్రమే కనిపిస్తుంది." Responses లో మిగిలిన budget ను చూపించే field ఉండదు. అంగీకరించబడే కనిష్ఠ task_budget.total 20,000 tokens. అంతకంటే తక్కువ విలువ ఇస్తే 400 error వస్తుంది. పని పూర్తిచేయడానికి budget చాలా తక్కువగా ఉంటే refusal లాంటి ప్రవర్తన కనిపిస్తుంది. అందువల్ల model task పరిధిని తగ్గించవచ్చు లేదా ముందుగానే ఆపివేయవచ్చు.

ఒక వివరాన్ని మార్చడం వల్ల ఖర్చు తగ్గడానికి బదులుగా పెరుగుతుంది. మీ client ప్రతి follow-up request లో task_budget.remaining విలువను తగ్గిస్తే, మార్చిన విలువ దాన్ని కలిగి ఉన్న 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 లో detached చేసిన 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 వస్తుంది.

ప్రతి పనికి మోడల్ ఎంపిక, అలాగే ప్రయత్నం వాస్తవంగా మార్చేది

మోడల్ ఎంపిక ప్రతి పనికి విడిగా చేయాల్సిన నిర్ణయం. 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 ను మాత్రమే వర్గీకరించే దశకు Opus అవసరం లేదు. Busy schedule ను సమతుల్యం చేయడానికి ఉచిత 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 ను ఒకదానిలో కలపడానికి ఇది కారణమవుతుంది. Agent లో ఇది మరింత పెద్ద ఆదా, ఎందుకంటే తప్పించుకున్న tool call అంటే అసలు జరగని పూర్తి request.

Effort cache కు విరుద్ధంగా పనిచేయడం సమస్య. Requests మధ్య value మార్చితే prompt caching చెల్లదు. Documentation లోని ఉదాహరణలో request 2 cache_read_input_tokens: 3546 ను report చేసింది. Effort ను high నుంచి medium కు మార్చిన request 3, 3546 లో cache_creation_input_tokens మరియు 0 లో cache_read_input_tokens ను report చేసింది. అందువల్ల workloads మధ్య effort ను మార్చండి, ఒకే cached conversation లో మాత్రం మార్చవద్దు. Cache ను విచ్ఛిన్నం చేయకుండా depth ను నియంత్రించాలంటే prompt లోనే సూచన ఇవ్వండి: "Answer directly without deliberating." వంటి line ను తాజా user message లో ఉంచితే, మునుపటి breakpoints అలాగే ఉంటాయి.

Thinking tokens కు output rates ప్రకారం billing జరుగుతుంది. అవి max_tokens లో కూడా లెక్కించబడతాయి. అందుకే truncated answer కనిపించినప్పుడు thinking budget ను ఖర్చు చేసి ఉండటం తరచుగా కారణం. సంఖ్య కోసం usage.output_tokens_details.thinking_tokens ను చదవండి. Claude token bill ను వాస్తవంగా ఏవి నింపుతాయి అనే వివరణలో meter ను విడదీసి చూపుతుంది.

స్థిరమైన prefix ను cache చేసి, అనుకోకుండా దాన్ని విచ్ఛిన్నం చేయకుండా చూడండి

five-minute cache లో cache write కు base input price కంటే 1.25 రెట్లు, one-hour cache లో 2 రెట్లు ఖర్చవుతుంది. cache read కు 0.1 రెట్లు మాత్రమే ఖర్చవుతుంది. అందువల్ల “5-minute వ్యవధిలో (1.25x write) ఒక్క cache read తర్వాతే caching ప్రయోజనకరంగా మారుతుంది; 1-hour వ్యవధిలో (2x write) రెండు cache reads తర్వాత ప్రయోజనం లభిస్తుంది.”

ఇది ఎల్లప్పుడూ నడిచే agent కు ఎందుకు అనుకూలమో ఒక వాక్యం వివరిస్తుంది: “cache చేసిన content ను ప్రతి సారి ఉపయోగించినప్పుడు అదనపు ఖర్చు లేకుండా cache refresh అవుతుంది.” five-minute cache ను ఉపయోగించే job ప్రతి రెండు నిమిషాలకు ఒకసారి నడిస్తే, ఒక write తో రోజంతా దాని prefix warm గా ఉంటుంది.

మీకు తెలియకుండానే cache కోల్పోయే మూడు మార్గాలు ఇవి.

మారే prefix. “Cache prefixes కింది క్రమంలో సృష్టించబడతాయి: tools, system, తరువాత messages.” ఆ క్రమంలో ముందుగా ఉన్న ఏ byte మారినా, దాని తరువాతి మొత్తం భాగం invalid అవుతుంది. Tool definitions ను సవరించినా మొత్తం cache invalid అవుతుంది. System prompt లో timestamp లేదా run id ఉంచడం తరచుగా జరిగే స్వయంకృత సమస్య. అప్పుడు ప్రతి request వేర్వేరు prefix ను పంపుతుంది, 1.25x వద్ద కొత్త 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 ను పరిశీలించి, తరువాత ఆపుతుంది. Document చేసిన ఉదాహరణలో block 35 వద్ద breakpoint ఉన్న turn లో 35 blocks ఉంటాయి. System blocks 35 నుంచి 16 వరకు పరిశీలిస్తుంది. మునుపటి turn లోని block 15 వద్ద ఉన్న entry window వెలుపల ఉండటంతో hit లభించదు. ప్రతి turn లో agent అనేక tool-use మరియు tool-result blocks జోడిస్తే, రెండు లేదా మూడు turns లోనే 20 దాటుతుంది. ప్రతి request కు నాలుగు breakpoints ఉంటాయి. కాబట్టి వాటిలో ఒకదాన్ని తాజా messages కోసం ఉపయోగించండి.

వేచి ఉండగల ప్రతిదాన్ని Batches API కి పంపండి

ఇన్‌పుట్ మరియు అవుట్‌పుట్ రెండింటిపైనా “మొత్తం వినియోగానికి ప్రామాణిక API ధరల్లో 50% మాత్రమే ఛార్జ్ చేయబడుతుంది.” Batch processing asynchronous గా జరుగుతుంది. “చాలా batches 1 గంటలోపు పూర్తవుతాయి.” అన్ని requests పూర్తయినప్పుడు లేదా 24 గంటల తర్వాత, ఏది ముందుగా జరిగితే అప్పుడు results అందుబాటులోకి వస్తాయి. ఇది సాధారణ అంచనా మాత్రమే; హామీ కాదు.

processing_status లో ended కనిపించే వరకు దాన్ని poll చేయండి. errored, canceled లేదా expired ను తిరిగి ఇచ్చే requests కు ఛార్జ్ విధించబడదు. మీరు spend cap పై ఆధారపడితే ఒక పరిమితి ఉంది: “batches మీ Workspace కోసం configured spend limit ను కొద్దిగా మించవచ్చు.”

ఈ discounts పరస్పరం కలుస్తాయి. Batch పూర్తవడానికి ఐదు నిమిషాలకంటే ఎక్కువ సమయం పట్టవచ్చు కాబట్టి, context పంచుకునే batches కోసం one-hour cache ను documentation సిఫార్సు చేస్తుంది. అందువల్ల పనిని విభజించండి: ఒక వ్యక్తి లేదా 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 కు ఒక row ను JSON-lines file లో జోడించండి. దానికి మీ job name ను tag చేయండి. వారం తర్వాత ఏ job ఖర్చు చేస్తుందో, ఏది busyగా మాత్రమే కనిపిస్తుందో చెప్పగలరు. cache_read ను గమనించండి: self-hosted agent లో ఖర్చుకు సంబంధించిన అత్యంత సాధారణ bug zeroలతో నిండిన column.

ఒక 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 నుంచి వచ్చింది.

పంపించే ముందు లెక్కించండి. Token counting ఉచితం, దానికి message creation నుంచి వేరు rate limits ఉంటాయి. అందువల్ల 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 మరియు అంతకుముందు versions, వాటిలో Claude Haiku 4.5 కూడా ఉన్నాయి, మునుపటి tokenizer ను ఉపయోగిస్తాయి.

అధికారిక వివరాల కోసం 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[]= ను కూడా అంగీకరిస్తాయి. ఒక పరిమితి ఉంది: "వ్యక్తిగత accounts కు Admin API అందుబాటులో ఉండదు."

చివరి parameter ద్వారా తక్కువ ఖర్చుతో attribution చేయవచ్చు: ప్రతి job కు ప్రత్యేక API key ఇవ్వండి, api_key_ids[] తో filter చేయండి, తరువాత group_by[]=api_key_id తో ప్రతి key కు report ను విడిగా విభజించండి. Filter plural రూపంలో ఉంటుంది, grouping dimension singular రూపంలో ఉంటుంది. Keys ను code లో కాకుండా environment లో ఉంచండి. VPS పై మొదటి Claude API app వాటిని నిర్వహించే విధానం ఇదే.

పునరావృతికి పరిమితి విధించండి, లేకపోతే సమస్య కొనసాగుతూనే ఉంటుంది

ఇక్కడ పునరావృతుల సంఖ్యకు పరిమితి తప్పనిసరి. 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)

పైన ఉన్న రెండు పరిమితుల్లో ఏదీ మీ తరఫున దీన్ని చేయదు: max_tokens ఒక response కు మాత్రమే పరిమితి విధిస్తుంది, model కు task budget గురించి సూచన మాత్రమే అందుతుంది.

Process వెలుపల మరో నియంత్రణను ఉంచండి. Job ను శాశ్వత process గా కాకుండా systemd timer నుంచి నడపండి. దాని service unit లో RuntimeMaxSec= సెట్ చేయండి. RuntimeMaxSec=600 ఉపయోగిస్తే, నిలిచిపోయిన run ను మీరు గమనించే వరకు కొనసాగించకుండా పది నిమిషాల తర్వాత ఆపివేస్తుంది. systemd service మరియు timer గా program ను నడపడం unit files గురించి వివరిస్తుంది. Run ఏమి చేసిందో journalctl -u triage-agent.service --since "1 hour ago" తో చూడండి.

Retries కు కూడా పరిమితి విధించండి. ఎందుకంటే ఎప్పటికీ retry చేసే handler ప్రతి ప్రయత్నానికి billing ను పెంచుతుంది. 429 లేదా 500 కు backoff తో కొన్ని ప్రయత్నాలు చేయడం సముచితం. 400 కు ఒక్క ప్రయత్నం కూడా అవసరం లేదు, ఎందుకంటే అదే request మళ్లీ అదే విధంగా విఫలమవుతుంది.

AI agent ఖర్చు నియంత్రణ మీ స్వంత గణాంకాలను చదవడం నుంచే ప్రారంభమవుతుంది

ఎల్లప్పుడూ నడుస్తున్న agent కు ఎంత ఖర్చవుతుందో ఎవరూ ఖచ్చితంగా చెప్పలేరు. కారణం, ఒక్కో run కు అయ్యే tokens ఖర్చును రోజుకు జరిగే runs సంఖ్యతో గుణించాలి. ఈ రెండు విలువలు మీ వినియోగంపై ఆధారపడి ఉంటాయి. Agent ను ఒకసారి run చేసి, మీరు నమోదు చేసిన usage వరుసను చదవండి. తరువాత దాన్ని మీ schedule తో గుణించండి. రెండు రోజుల తర్వాత cost report ను ఆ లెక్కతో పోల్చండి. రెండూ సరిపోకపోతే, కారణం దాదాపు ఎల్లప్పుడూ విఫలమైన cache లేదా మీరు ఊహించినదానికంటే ఎక్కువసేపు నడిచిన loop అయి ఉంటుంది.

ఇది API key ఉందని భావిస్తుంది. ఎందుకంటే agent అనేది Messages API ను పిలిచే మీ స్వంత program. మీ స్వంత interactive పనికి, మీ పని విధానానికి సరిపోయే Claude plan ఏది subscription వైపు వివరాలను అందిస్తుంది. ఇక్కడ పేర్కొన్న ప్రతి ధర మరియు పరిమితిని July 2026లో Anthropic documentation తో ధృవీకరించాం. అందువల్ల budget రూపొందించే ముందు pricing page ను మళ్లీ చదవండి.

FAQ

ఎల్లప్పుడూ నడిచే AI agent ను VPS పై అమలు చేయడానికి ఎంత ఖర్చవుతుంది?

ఇక్కడ రెండు బిల్లులు ఉంటాయి. వాటిలో ఒకటి మాత్రమే ముందుగా అంచనా వేయగలిగేది. Server కు నెలవారీ స్థిర ధర ఉంటుంది. Model API కు token ఆధారంగా metered billing ఉంటుంది. అందువల్ల ఒక్క run వినియోగించే మొత్తాన్ని, అది ఎంత తరచుగా నడుస్తుందో దానితో గుణించినదే ఖర్చు. Self-hosted always-on agent కోసం Anthropic ఎలాంటి నిర్దిష్ట సంఖ్యను ప్రచురించలేదు. కాబట్టి ఎవరైనా చెప్పే సంఖ్యను అంచనాగానే పరిగణించండి. ఒక నిజమైన run నుంచి usage ను log చేసి, మీ schedule ప్రకారం గుణించండి.

max_tokens మరియు task budget మధ్య తేడా ఏమిటి?

max_tokens అమలు చేయబడుతుంది, కానీ model కు కనిపించదు. ఇది ఒక్క request యొక్క output ను, ఆలోచనా ప్రక్రియతో సహా, పరిమితం చేస్తుంది. ఆ పరిమితిని తాకితే stop_reason: "max_tokens" వస్తుంది. Task budget దీనికి విరుద్ధంగా ఉంటుంది: ఆ సంఖ్యను model కు తెలియజేస్తారు, model దాని ఆధారంగా agentic loop వేగాన్ని నియంత్రిస్తుంది. అయితే "Task budgets are a soft hint, not a hard cap". అమలు చేయబడే పరిమితి మాత్రం ఇప్పటికీ max_tokens.

నా agent కోసం cache_read_input_tokens ఎల్లప్పుడూ zero గా ఎందుకు ఉంటుంది?

Calls మధ్య prefix మారడం లేదా అది cache చేయడానికి చాలా చిన్నగా ఉండడమే కారణం. సాధారణంగా system prompt లో timestamp లేదా run id ను interpolate చేయడం వల్ల ఈ సమస్య వస్తుంది. Cache, prefix ఆధారంగా రూపొందుతుంది. అందువల్ల ఏ byte మారినా, దాని తరువాతి మొత్తం భాగం చెల్లదు. Tool definitions లేదా effort value మార్చినా ఇదే జరుగుతుంది. లేకపోతే కారణం పరిమాణం కావచ్చు. చిన్న prompts cache చేయబడవు, కానీ ఎలాంటి error కూడా తిరిగి ఇవ్వబడదు.

AI agent ఎప్పటికీ loop అవుతూ ఉండకుండా ఎలా ఆపాలి?

మీ loop code లో iterations ను లెక్కించి, ఒక స్థిరమైన గరిష్ఠ పరిమితి వద్ద ఆపండి. ఎందుకంటే max_tokens ఒక్క response ను మాత్రమే పరిమితం చేస్తుంది, కానీ agent అనేక responses ను సృష్టిస్తుంది. Process వెలుపల wall-clock limit కూడా పెట్టండి. RuntimeMaxSec= సెట్ చేసిన systemd timer నుంచి job ను ప్రారంభించండి. అప్పుడు నిలిచిపోయిన run షెడ్యూల్ ప్రకారం terminate అవుతుంది. Retries కు కూడా పరిమితి పెట్టండి. Retry loop లో ప్రతి attempt కు billing జరుగుతుంది.

ఒకే Claude API key పై spending limit పెట్టవచ్చా?

Documented spend limit ఒక్క key కు కాకుండా workspace కు వర్తిస్తుంది. కాబట్టి agent కోసం ప్రత్యేక workspace సృష్టించి, అక్కడ దాని monthly spend కు పరిమితి పెట్టండి. "You cannot set limits on the Default Workspace". Spend notifications జోడించండి, తద్వారా threshold చేరుకునే ముందు మీకు alert వస్తుంది. వినియోగాన్ని వేరు గుర్తించడానికి ప్రతి job కు ప్రత్యేక key ఇవ్వండి. తరువాత group_by[]=api_key_id తో usage report ను group చేయండి.

#claude #ai #agents #api #cost