VPS లో AI agent ఖర్చులను ఎలా తగ్గించాలి

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

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

ఇది ఇప్పటికే ఉన్న మరియు మీ స్వంత సర్వర్ నుండి Messages API ని ఉపయోగించే agent గురించి చెబుతోంది. VPS లో Claude తో AI agent ని నిర్మించడం లో దాని పనితీరు గురించి వివరించబడింది.

Unattended agent వల్ల ఖర్చుల విధానం ఎందుకు మారుతుంది

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

Frequency అనేది ప్రజలు గమనించని అంశం. ప్రతి ఐదు నిమిషాలకు ఒకసారి నడిచే job రోజుకు 288 సార్లు, నెలకు సుమారు 8,640 సార్లు నడుస్తుంది. ఒకే ఒక్క run కి అయ్యే ఖర్చును ఈ సంఖ్యతో గుణించాలి. చాలా "always-on" agents ని ఎప్పుడూ ఆన్ లో ఉంచాల్సిన అవసరం లేదు. వాటికి నిర్ణీత నిమిషాల లోపు సమాధానం ఇవ్వాలి, ఇది ఒక schedule.

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

• ప్రతి request తో tool definitions కూడా వెళ్తాయి. Claude Opus 4.8 లో tool_choice of auto లేదా none ఉన్నప్పుడు tool-use system prompt ఖర్చు 290 tokens అవుతుంది, any లేదా tool ఉన్నప్పుడు 410 అవుతుంది. Bash tool వల్ల మరో 325 tokens పెరుగుతాయి. మీరు అటాచ్ చేసే ప్రతి MCP server దాని schemas వల్ల ఈ బరువును పెంచుతుంది, ఇక్కడ MCP అంటే model context protocol.
• Tool results అనేవి input tokens. 8,000 లైన్లను ప్రింట్ చేసే command, తదుపరి request లో మరియు ఆ turn లోని ప్రతి request లో 8,000 లైన్లను పంపుతుంది.
• Fetched pages అనేవి input tokens. సగటు 10 kB వెబ్ పేజీ సుమారు 2,500 tokens మరియు 500 kB రీసెర్చ్ PDF సుమారు 125,000 tokens అవుతుంది. max_content_tokens కేవలం text ఫైళ్లకు మాత్రమే వర్తిస్తుంది, ఎందుకంటే ఇది "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 అమలు చేయబడుతుంది. ఇది ఒక రిక్వెస్ట్ యొక్క మొత్తం అవుట్‌పుట్ (thinking మరియు response text కలిపి) పై ఉండే hard cap. Claude దీనిని దాటి ఎప్పుడూ జనరేట్ చేయదు, మరియు మోడల్‌కు ఈ సంఖ్య తెలియదు. ఈ పరిమితికి చేరుకుంటే stop_reason: "max_tokens" మరియు అసంపూర్తిగా ఉన్న సమాధానం (truncated answer) వస్తుంది. agents కి ఉన్న ఇబ్బంది ఏమిటంటే: tool-use loop లో ప్రతి రిక్వెస్ట్‌కు దాని స్వంత max_tokens ఉంటుంది, కాబట్టి ఇది ఒకే ఒక response ని పరిమితం చేస్తుంది కానీ మొత్తం టాస్క్ ని కాదు. 4,000 టోకెన్ల వద్ద పది tool calls ఉంటే, ఆ turn కోసం మొత్తం 40,000-token ceiling అవుతుంది.

Task budget అనేది ఒక advisory మాత్రమే. task_budget అనేది output_config లో ఉంటుంది. ఇది thinking, tool calls, tool results మరియు output కలిపి మొత్తం agentic loop కోసం మోడల్‌కు ఎన్ని టోకెన్లు ఉన్నాయో తెలియజేస్తుంది.

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 ఏదైనా యాక్షన్ మధ్యలో దీనిని మించి వెళ్లవచ్చు, మరియు అవుట్‌పుట్ పై ఉండే enforced limit ఇంకా max_tokens గానే ఉంటుంది. "The countdown is visible only to the model", మరియు responses లో remaining-budget అనే ఫీల్డ్ ఉండదు. కనిష్టంగా ఆమోదించబడే task_budget.total 20,000 tokens, అంతకంటే తక్కువ ఉంటే 400 error వస్తుంది. పనికి తక్కువగా ఉన్న బడ్జెట్ వల్ల మోడల్ రిఫ్యూజ్ చేసే ప్రవర్తనను (refusal-like behaviour) చూపుతుంది, కాబట్టి మోడల్ టాస్క్ పరిధిని తగ్గించుకుంటుంది లేదా త్వరగా ఆగిపోతుంది.

ఒక చిన్న విషయం వల్ల డబ్బు ఆదా అవ్వదు, బదులుగా ఖర్చు పెరుగుతుంది. మీ client ప్రతి follow-up request లో task_budget.remaining ని తగ్గించినట్లయితే, మారిన విలువ వల్ల ఆ prefix లో ఉన్న cache చెల్లకుండా పోతుంది. మొదటి రిక్వెస్ట్ లో మాత్రమే దీనిని ఒకసారి సెట్ చేయండి.

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 సెట్ చేయండి. "You cannot set limits on the Default Workspace", మరియు "Organization-wide limits ఎల్లప్పుడూ వర్తిస్తాయి, workspace limits వాటికంటే ఎక్కువగా ఉన్నప్పటికీ". cap కి చేరుకోకముందే అలర్ట్ రావడానికి spend notifications ని జోడించండి.

ప్రతి జాబ్ కోసం మోడల్ ఎంపిక, మరియు అసలైన శ్రమ (effort) ప్రభావం

మోడల్ ఎంపిక అనేది ప్రతి జాబ్ కోసం తీసుకునే నిర్ణయం. జూలై 2026 నాటికి, ప్రతి మిలియన్ టోకెన్లకు, ఇన్‌పుట్ మరియు అవుట్‌పుట్ ధరలు ఇలా ఉన్నాయి: 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 ధర దాని అసలు ధర కంటే తక్కువగా ఉంది, ఎందుకంటే "August 31, 2026 వరకు ప్రతి మిలియన్ ఇన్‌పుట్/అవుట్‌పుట్ టోకెన్లకు $2/$10 పరిచయ ధర అమలులో ఉంది". కేవలం log lines మాత్రమే క్లాసిఫై చేసే పనికి Opus అవసరం లేదు.

శ్రమ (effort) అనేది రెండవ ముఖ్యమైన అంశం. output_config.effort అనేది low, medium, high, xhigh మరియు max లను అంగీకరిస్తుంది, మరియు దీని డిఫాల్ట్ విలువ high. కాబట్టి high ని స్పష్టంగా సెట్ చేయడం అంటే దానిని వదిలేయడంతో సమానం. శ్రమను తగ్గించడం వల్ల కేవలం reasoning length మాత్రమే తగ్గదు: డాక్యుమెంటేషన్ ప్రకారం, ఇది Claude తక్కువ tool calls చేసేలా చేస్తుంది మరియు కార్యకలాపాలను (operations) ఒకటిగా కలుపుతుంది. ఒక agent విషయంలో ఇది ఎక్కువ ఆదా చేస్తుంది, ఎందుకంటే ఒక tool call ని నివారించడం అంటే ఒక పూర్తి request జరగకపోవడమే.

ప్రమాదం ఏమిటంటే, శ్రమ (effort) అనేది cache కి విరుద్ధంగా పనిచేస్తుంది. రిక్వెస్ట్‌ల మధ్య ఈ విలువను మార్చడం వల్ల prompt caching చెల్లకుండా పోతుంది. డాక్యుమెంటేషన్‌లో ఉన్న ఉదాహరణ ప్రకారం, request 2 లో cache_read_input_tokens: 3546 నమోదైంది; request 3 లో, effort ని high నుండి medium కి మార్చినప్పుడు, cache_creation_input_tokens విలువ 3546 మరియు cache_read_input_tokens విలువ 0 గా నమోదైంది. కాబట్టి వివిధ వర్క్‌లోడ్‌ల మధ్య మాత్రమే effort ని మార్చండి, ఒకే cached conversation లో మార్చకండి. Cache ని పాడు చేయకుండా లోతును (depth) నియంత్రించాలంటే, దానిని prompt లో చేయండి: తాజా user message లో "Answer directly without deliberating." వంటి లైన్ ఉంచడం వల్ల మునుపటి breakpoints అలాగే ఉంటాయి.

Thinking tokens అవుట్‌పుట్ ధరల ప్రకారం బిల్ చేయబడతాయి మరియు ఇవి max_tokens కింద లెక్కించబడతాయి, అందుకే సమాధానం మధ్యలో ఆగిపోతే (truncated answer), thinking వల్ల బడ్జెట్ అయిపోయిందని అర్థం. సంఖ్యల కోసం usage.output_tokens_details.thinking_tokens చదవండి. Claude టోకెన్ బిల్లులో అసలైన అంశాలు దీని గురించి వివరంగా వివరిస్తుంది.

Stable prefix ని cache చేయండి, మరియు పొరపాటున దానిని దెబ్బతీయకండి

5-minute cache లో cache write ధర base input price కంటే 1.25 రెట్లు ఉంటుంది, మరియు 1-hour cache లో 2 రెట్లు ఉంటుంది. Cache read ధర 0.1 రెట్లు మాత్రమే ఉంటుంది, కాబట్టి "5-minute duration కి కేవలం ఒకే ఒక cache read తర్వాత caching లాభదాయకం (1.25x write), లేదా 1-hour duration కి రెండు cache reads తర్వాత లాభదాయకం (2x write)".

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

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

మారే prefix. "Cache prefixes ఈ క్రమంలో సృష్టించబడతాయి: tools, system, ఆపై messages." ఈ క్రమంలో ముందున్న ఏ byte మార్పు అయినా దాని తర్వాత ఉన్నవన్నీ invalidates చేస్తుంది, మరియు editing tool definitions మొత్తం cache ని invalidates చేస్తుంది. system prompt లో timestamp లేదా run id ఉండటం వల్ల కలిగే సమస్య అత్యంత సాధారణమైనది: అప్పుడు ప్రతి request వేరొక prefix ని కలిగి ఉంటుంది, 1.25x ఖర్చుతో కొత్త entry ని write చేస్తుంది, మరియు ఏదీ read చేయదు. ఒకేలా కనిపించే calls లో usage.cache_read_input_tokens విలువ 0 గా ఉంటే అది దీనికి సంకేతం. మారుతూ ఉండే text ని కొత్త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 నిశ్శబ్దంగా ఆగిపోవచ్చు.

Lookback window కంటే పెద్దదిగా ఉండే conversation. "Lookback window 20 blocks." system ప్రతి breakpoint వద్ద గరిష్టంగా 20 positions ని తనిఖీ చేస్తుంది, ఆపై ఆగిపోతుంది. డాక్యుమెంట్ చేయబడిన ఉదాహరణలో, block 35 వద్ద breakpoint ఉన్న 35 blocks కలిగిన turn, block 35 నుండి 16 వరకు తనిఖీ చేస్తుంది, మరియు முந்தைய turn లోని block 15 entry window బయట పడిపోతుంది, కాబట్టి అక్కడ hit ఉండదు. ప్రతి turn లో tool-use మరియు tool-result blocks కలిపి append చేసే agent, రెండు లేదా మూడు turns లోనే 20 ని దాటేస్తుంది. ప్రతి request కి నాలుగు breakpoints లభిస్తాయి, కాబట్టి ఒక దానిని ఇటీవలి messages కోసం ఉపయోగించండి.

వేచి ఉండగలిగే పనులను Batches API కి పంపండి

ఇన్‌పుట్ మరియు అవుట్‌పుట్ రెండింటిపై "అన్ని వినియోగాలకు standard API ధరలలో 50% మాత్రమే ఛార్జ్ చేయబడుతుంది". Batch processing అనేది asynchronous పద్ధతిలో జరుగుతుంది. "చాలా batches 1 hour కంటే తక్కువ సమయంలోనే పూర్తవుతాయి". ప్రతి request పూర్తయిన తర్వాత లేదా 24 hours తర్వాత, వీటిలో ఏది ముందు వస్తే అప్పుడు ఫలితాలు లభిస్తాయి. ఇది సాధారణంగా జరుగుతుంది, కానీ దీనికి గ్యారెంటీ లేదు.

ended అని వచ్చే వరకు processing_status ని poll చేయండి. errored, canceled లేదా expired రిటర్న్ అయ్యే requests కి బిల్లింగ్ ఉండదు. మీరు spend cap ఉపయోగిస్తుంటే ఒక విషయం గుర్తుంచుకోవాలి: "batches మీ Workspace యొక్క configured spend limit కంటే కొంచెం ఎక్కువగా వెళ్లవచ్చు."

డిస్కౌంట్లు స్టాక్ అవుతాయి. ఒక batch ఐదు నిమిషాల కంటే ఎక్కువ సమయం తీసుకోవచ్చు కాబట్టి, ఒకే context ఉన్న batches కోసం డాక్యుమెంటేషన్ ఒక-గంట cache ని సిఫార్సు చేస్తుంది. కాబట్టి పనిని విభజించండి: మనిషి లేదా webhook వేచి ఉండే పనులను live path లో ఉంచండి, మరియు nightly digest లేదా నిన్నటి log classification వంటి పనులను సగం ధరకే batch లోకి పంపండి.

ప్రతి రెస్పాన్స్ యొక్క usage fields ను మీ స్వంత స్టోర్‌లోకి లాగ్ చేయండి

మీరు రికార్డ్ చేయని ఖర్చును మీరు లెక్కించలేరు. ప్రతి రెస్పాన్స్ దాని ఖర్చును తెలియజేస్తుంది.

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 కాల్‌కు ఒక వరుసను (row) మీ job name తో ట్యాగ్ చేస్తూ, ఒక JSON-lines ఫైల్‌కు జోడించండి. ఒక వారం తర్వాత, ఏ job ఎంత ఖర్చు చేసిందో మరియు ఏది కేవలం బిజీగా కనిపించిందో మీరు చెప్పగలరు. cache_read ని గమనించండి: సెల్ఫ్-హోస్టెడ్ ఏజెంట్‌లో సున్నాలతో కూడిన కాలమ్ అత్యంత సాధారణమైన cost bug.

ఒక ఫీల్డ్‌ను తప్పుగా అర్థం చేసుకునే అవకాశం ఉంది. input_tokens కేవలం చివరి cache breakpoint తర్వాత ఉన్న tokens మాత్రమే లెక్కిస్తుంది, కాబట్టి అసలు prompt size total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. పెద్ద prompt కి input_tokens: 400 ని రిపోర్ట్ చేసే ఏజెంట్ చౌకైనది కాదు: మిగిలినవి cache నుండి వచ్చాయి.

పంపే ముందే లెక్కించండి. Token counting ఉచితం మరియు దాని rate limits మెసేజ్ క్రియేషన్ నుండి వేరుగా ఉంటాయి, కాబట్టి ఖర్చుతో కూడిన అటాచ్‌మెంట్‌ను గుర్తించే బదులు, దానిని తిరస్కరించడానికి count_tokens ఉపయోగించండి. ఫలితం ఒక అంచనా మాత్రమే, కాబట్టి ప్రతి మోడల్‌కు మళ్ళీ కొలవండి మరియు ఇతర vendor యొక్క tokenizer నుండి వచ్చిన కౌంట్‌ను ఎప్పుడూ మళ్ళీ ఉపయోగించవద్దు. Claude Opus 4.7 మరియు తర్వాతి Opus మోడల్స్, 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 వద్ద usage ని మరియు https://api.anthropic.com/v1/organizations/cost_report వద్ద cost ని రిపోర్ట్ చేస్తుంది. రెండూ x-api-key: $ANTHROPIC_ADMIN_KEY గా sk-ant-admin01-... ని మరియు anthropic-version: 2023-06-01 తో తీసుకుంటాయి, మరియు bucket_width=1d, group_by[]=model మరియు api_key_ids[]= ని అంగీకరిస్తాయి. ఒక పరిమితి: "The Admin API is unavailable for individual accounts."

ఆ చివరి పారామీటర్ ఒక తక్కువ ఖర్చుతో కూడిన attribution ట్రిక్: ప్రతి job కి దాని స్వంత API key ని ఇవ్వండి, api_key_ids[] తో ఫిల్టర్ చేయండి, మరియు group_by[]=api_key_id తో రిపోర్ట్‌ను ప్రతి key కి విడగొట్టండి. ఫిల్టర్ బహువచనం (plural), గ్రూపింగ్ డైమెన్షన్ ఏకవచనం (singular). a first Claude API app on a VPS చేసే విధంగా, కీలను కోడ్‌లో కాకుండా 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 ఖర్చులను నియంత్రించాలంటే మీ స్వంత గణాంకాలను విశ్లేషించడం ముఖ్యం

ఎల్లప్పుడూ ఆన్లైన్‌లో ఉండే (always-on) agent ఖర్చు ఎంత ఉంటుందో ఎవరూ ఖచ్చితంగా చెప్పలేరు. ఎందుకంటే ఖర్చు అనేది 'ప్రతి రన్ కి అయ్యే tokens' మరియు 'రోజుకు చేసే runs' ల లబ్దంపై ఆధారపడి ఉంటుంది. ఈ రెండు అంశాలు మీ నియంత్రణలోనే ఉంటాయి. ఒకసారి agent ని రన్ చేసి, మీరు log చేసిన usage row ని చూడండి, దానిని మీ schedule తో గుణించండి. రెండు రోజుల తర్వాత వచ్చిన cost report ని ఆ గణనతో పోల్చి చూడండి. ఈ రెండింటి మధ్య తేడా ఉంటే, దానికి కారణం సాధారణంగా cache సరిగ్గా పనిచేయకపోవడం లేదా మీరు ఊహించిన దానికంటే ఎక్కువ సేపు నడిచిన loop వల్ల జరుగుతుంది.

ఇక్కడ API key ఉపయోగిస్తున్నట్లుగా పరిగణించబడింది, ఎందుకంటే agent అనేది Messages API ని పిలిచే మీ స్వంత ప్రోగ్రామ్. మీ స్వంత interactive పనుల కోసం, మీ పని విధానానికి ఏ Claude plan సరిపోతుందో తెలుసుకోండి. ఇక్కడ పేర్కొన్న ప్రతి ధర మరియు పరిమితి July 2026 లో Anthropic డాక్యుమెంటేషన్ ఆధారంగా తనిఖీ చేయబడింది. కాబట్టి బడ్జెట్ సిద్ధం చేసే ముందు pricing page ని మళ్ళీ చదవండి.

FAQ

VPSలో always-on AI agent నడపడానికి అయ్యే ఖర్చు ఎంత?

రెండు బిల్లులు ఉంటాయి, అందులో ఒకటి మాత్రమే ముందే తెలుస్తుంది. సర్వర్ ధర ప్రతి నెలా స్థిరంగా ఉంటుంది. model API ఖర్చు token ఆధారంగా లెక్కించబడుతుంది, కాబట్టి ఒక run లో వినియోగించే మొత్తాన్ని, అది ఎన్నిసార్లు run అవుతుందో దానితో గుణిస్తే ఖర్చు తెలుస్తుంది. Anthropic సంస్థ self-hosted always-on agent కోసం ఎటువంటి ఖర్చు వివరాలను ప్రకటించలేదు, కాబట్టి ఏదైనా అంచనా వేసిన సంఖ్యను కేవలం ఒక ఊహగా మాత్రమే పరిగణించండి. ఒక real run నుండి usage ని సేకరించి, దానిని మీ 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 ఉండటం వల్ల ఇలా జరుగుతుంది: cache అనేది prefix ఆధారంగా పనిచేస్తుంది, కాబట్టి ఏ చిన్న byte మార్పు వచ్చినా దాని తర్వాత ఉన్నవన్నీ invalid అవుతాయి. tool definitions మార్చడం లేదా effort విలువను మార్చడం వల్ల కూడా ఇదే జరుగుతుంది. లేదంటే, prompt పరిమాణం తక్కువగా ఉండటం వల్ల కూడా ఇలా జరుగుతుంది, ఎందుకంటే చిన్న prompts ని cache చేయరు మరియు ఎటువంటి error కూడా రాదు.

AI agent అనంతంగా loop లోకి వెళ్లకుండా ఎలా ఆపాలి?

మీ loop code లో iterations ని లెక్కించండి మరియు ఒక నిర్ణీత గరిష్ట సంఖ్య వద్ద ఆపివేయండి, ఎందుకంటే max_tokens అనేది ఒక response కి మాత్రమే పరిమితిగా పనిచేస్తుంది, కానీ agent అనేక response లను చేస్తుంది. process బయట ఒక wall-clock limit ని జోడించండి: RuntimeMaxSec= ని ఉపయోగించి systemd timer ద్వారా job ని ప్రారంభించండి, తద్వారా stuck అయిన run నిర్ణీత సమయంలో ఆగిపోతుంది. retries ని కూడా పరిమితం చేయండి, ఎందుకంటే ప్రతి retry attempt కి బిల్లు పడుతుంది.

నేను ఒకే ఒక Claude API key కి spending limit ని సెట్ చేయవచ్చా?

level ప్రకారం spend limit అనేది key కి కాకుండా workspace కి వర్తిస్తుంది, కాబట్టి agent కి ఒక ప్రత్యేక workspace ఇచ్చి, అక్కడ దాని నెలవారీ ఖర్చును పరిమితం చేయండి. "You cannot set limits on the Default Workspace". ఒక threshold దాటినప్పుడు మీకు అలర్ట్ వచ్చేలా spend notifications ని జోడించండి. ఖర్చుల వివరాల కోసం (attribution), ప్రతి job కి ఒక ప్రత్యేక key ని ఇవ్వండి, ఆపై usage report ని group_by[]=api_key_id తో గ్రూప్ చేయండి.