Coding agents కోసం multi-model routing ఖర్చు లెక్కలు

కోడింగ్ agent కు multi-model routing వల్ల కలిగే ప్రభావం

Multi-model routing ప్రతి అభ్యర్థనను దాన్ని నిర్వహించగల అత్యంత చవకైన model కు పంపుతుంది. Chat traffic విషయంలో ఇది బాగా పనిచేస్తుంది. Coding agent విషయంలో ఇది సాధారణంగా ఆదా చేసే మొత్తంకంటే ఎక్కువ ఖర్చు చేస్తుంది. కారణం, agent ఖర్చులో ఎక్కువ భాగం ప్రతి model కు cache అయ్యే prompt prefix వల్ల వస్తుంది. Model మార్చినప్పుడు ఆ cache తొలగిపోతుంది.

ఈ పోస్ట్ సూచించే నియమం: availability కోసం providers మధ్య route చేయండి. ఖర్చు తగ్గించడానికి tiers మధ్య route చేయడం task boundaries వద్ద మాత్రమే చేయండి. Agent తరహా పనుల కోసం ప్రతి session కు ఒకే model ను pin చేయండి. దిగువ వివరణ అంతా దీనికి సంబంధించిన కారణాలను తెలియజేస్తుంది.

నాలుగు పదాలకు ఒకసారి నిర్వచనం. Router ప్రతి అభ్యర్థనకు ఒక model ను ఎంచుకుంటుంది. Gateway అభ్యర్థన దాని ద్వారా వెళ్లే proxy. అది routing కూడా చేయవచ్చు, చేయకపోవచ్చు. Prompt cache అంటే మీ prompt లో process చేసిన prefix ను provider నిల్వ చేయడం. తరువాతి అభ్యర్థనలో అదే prefix మళ్లీ ఉంటే input price లో కొంత భాగమే charge అవుతుంది. KV cache (key value cache) అనేది మీరు స్వయంగా నడిపే server లో ఇదే విధమైన వ్యవస్థ.

చాట్ traffic ఎందుకు బాగా route అవుతుంది, agent traffic ఎందుకు కాదు

చాట్ అభ్యర్థన ఒక turn మాత్రమే. అది వస్తుంది, classification జరుగుతుంది, model కు పంపబడుతుంది, సమాధానం తిరిగి వస్తుంది. తదుపరి అభ్యర్థనకు మునుపటి అభ్యర్థన నుంచి ఏదీ కొనసాగదు. Router ఈ ప్రశ్నను చిన్న model కు, తదుపరి ప్రశ్నను పెద్ద model కు పంపగలదు. ఏ అభ్యర్థనకూ మరొకటి జరిగిన విషయం తెలియదు. దాదాపు ప్రతి routing benchmark కొలిచేది ఇదే workload. మంచి routers ఈ పనిని నిజంగా సమర్థంగా నిర్వహిస్తాయి.

Agent turn ఒక అభ్యర్థన కాదు. "విఫలమవుతున్న test ను సరిచేయి" వంటి ఒక instruction ఇరవై నుంచి అరవై API calls గా మారుతుంది. ప్రతి call లో మొత్తం conversation మళ్లీ పంపబడుతుంది: system prompt, ప్రతి tool definition, agent చదివిన ప్రతి file, అది చూసిన ప్రతి command output. Context నిరంతరం పెరుగుతుంది. ముప్పైవ call కు చేరేసరికి మళ్లీ పంపబడే prefix పదివేలకొద్దీ tokens ఉండవచ్చు. అయితే ప్రతి call లో నిజంగా కొత్తగా ఉండే content కొన్ని వందల tokens మాత్రమే.

ఈ నిర్మాణం "ఖరీదైనది" అనే పదానికి అర్థాన్ని మారుస్తుంది. Chat లో cost సుమారుగా model ధరను request సంఖ్యతో గుణించినంత ఉంటుంది. Agent loop లో ప్రతి ఒక్క call కు మళ్లీ billing అయ్యేది prefix. ఈ post లోని మిగతా విషయం మొత్తం ఆ ఒక్క వాస్తవం నుంచి ఉద్భవిస్తుంది.

ప్రాంప్ట్ cache ప్రతి model‌కు వేరు. Agent దాని లోపలే ఉంటుంది

Anthropic cache read కు base input price లో 0.1 రెట్లు, ఐదు నిమిషాల cache write కు 1.25 రెట్లు ధర వసూలు చేస్తుంది. ఇవి 2026 August నాటికి ప్రచురించిన list prices.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

రెండో శ్రేణిని మొదటి శ్రేణితో అడ్డంగా, వరుసల వారీగా పోల్చండి; నిలువుగా కాదు. Opus 5 పై cache read ధర ప్రతి మిలియన్ tokens కు 0.50 dollars. జాబితాలో అతి తక్కువ ధర కలిగిన model అయిన Haiku 4.5 పై uncached input ధర 1.00 dollars. అందువల్ల అత్యంత ఖరీదైన model పై warm prefix ను మళ్లీ చదవడం, అత్యంత చవకైన model పై అదే prefix ను cache లేకుండా మొదటిసారి చదవడం కంటే ప్రతి input token కు తక్కువ ఖర్చవుతుంది.

ఈ ఒక్క పోలిక చాలా routing plans ను పనికిరాకుండా చేస్తుంది. ఒక router పనిని ఒక tier నుంచి "కిందికి" తరలించినప్పుడు list prices ను పోలుస్తుంది. కానీ session మధ్యలో ఉన్న agent ఇప్పటికే ఉపయోగిస్తున్న model కు list price చెల్లించదు. అది cache read price చెల్లిస్తుంది. ఈ ధర చవకైన model యొక్క uncached rate కంటే ఇప్పటికే తక్కువగా ఉంటుంది.

Caches prompt prefix యొక్క hash ఆధారంగా గుర్తించబడతాయి. అవి ప్రతి model కు వేరు. వేరే model కు పంపిన request, ఆ model ఇంతకు ముందు చూడని store పై hash అవుతుంది. అందువల్ల దానికి ఏదీ దొరకదు మరియు పూర్తి ధర చెల్లించాలి. Cache ఒక hierarchy కూడా: ముందుగా tools, తరువాత system, ఆపై messages. ఏ స్థాయిలోనైనా మార్పు జరిగితే ఆ స్థాయి మరియు దాని తరువాతి అన్ని స్థాయిలు invalidate అవుతాయి. అంటే ఒక tool definition ను సవరించినప్పుడు, దాని వెనుక ఉన్న system prompt cache కూడా తొలగిపోతుంది. Runtimeలో tools register చేసే agents, router ను అసలు తాకకుండానే ఈ పరిస్థితిని ఎదుర్కొంటాయి.

ఒక session మధ్యలో మార్పు చేస్తే వాస్తవంగా ఎంత ఖర్చవుతుంది

40,000 tokens ఉన్న స్థిరమైన prefix తో ఒక session ను పరిగణించండి. Agent కొన్ని files చదివిన తర్వాత ఇది సాధారణ పరిమాణమే. పైన ఇచ్చిన list prices ఆధారంగా, ఒక turn కు సంబంధించిన prefix ఖర్చు క్రింద చూపించబడింది.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

వెచ్చని cache తో Opus 5లో కొనసాగితే, ఆ turn యొక్క prefix కు 0.020 dollars ఖర్చవుతుంది. Sonnet 5కు routing down చేసిన తర్వాత వచ్చే మొదటి turn కు 0.100 dollars ఖర్చవుతుంది. Sonnet వద్ద ఈ prefix కు entry ఉండదు, కాబట్టి అది ఒక entryని రాయాలి. తిరిగి Opus 5కు వస్తే 0.250 dollars ఖర్చవుతుంది. Session బయట ఉన్న సమయంలో అసలు entry expire అవుతుంది.

అందువల్ల round tripలో రెండు cache reads ను నివారించడానికి రెండు cache writes చేయాల్సి వస్తుంది. దానికి బదులుగా, Opus output priceకు బదులుగా Sonnet output priceతో ఒక turn output లభిస్తుంది. Details blockలో మొత్తం లెక్క చూపబడింది: ఆదా fractions of a centలో ఉంటుంది, కానీ cache penalty tens of centsలో ఉంటుంది. ఈ penalty ఒక order of magnitude కంటే ఎక్కువగా ఉంటుంది. Prefix పొడవు పెరిగే కొద్దీ penalty పెరుగుతుంది, కానీ saving పెరగదు.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

ప్రొవైడర్ల మధ్య tool call format ఒకేలా ఉండదు

Agent అనేది tool-calling loop కాబట్టి, chat లో ఎప్పుడూ ప్రాధాన్యం లేని tool call format ఇక్కడ ముఖ్యమైనది. Anthropic's Messages API ఒక tool_use content block ను తిరిగి ఇస్తుంది మరియు ప్రతిస్పందనగా tool_result block ను ఆశిస్తుంది. OpenAI-compatible APIs ఒక tool_calls array ను తిరిగి ఇస్తాయి. అందులో function.arguments nested object కాకుండా JSON-encoded string గా ఉంటుంది. Gateway ఈ రెండు formats మధ్య అనువదిస్తుంది. సాధారణ calls కోసం ఈ అనువాదం సరిగ్గా పనిచేస్తుంది.

అంచు పరిస్థితుల్లో సమస్యలు కనిపిస్తాయి. Parallel tool calls లో model ఒకే response లో అనేక calls పంపుతుంది. వీటిని వేర్వేరు విధాలుగా సూచిస్తారు. అన్ని చోట్ల ఇవి ఒకే విధంగా support కావు. Strict schema enforcement ప్రతి providerలో వేర్వేరు feature. అందువల్ల ఒక endpointలో schema-valid arguments కు హామీ ఇచ్చే model, మరొక endpointలో చెల్లుబాటు అయ్యే arguments ను ఇవ్వడానికి మాత్రమే ఎక్కువగా ప్రయత్నిస్తుంది. Agent ఈ తేడాను parse error ఉన్న tool result గా చూస్తుంది. తరువాత మరో turn ఉపయోగించి దాన్ని సరిచేయడానికి ప్రయత్నిస్తుంది. ఈ repair turns కు పూర్తి prefix price వర్తిస్తుంది. కాబట్టి format mismatch transcriptలోనే కాకుండా invoiceలో కూడా కనిపిస్తుంది.

Self-hosted endpointsలో దీన్ని స్పష్టంగా configure చేయాలి. vLLM's OpenAI-compatible serverకు model familyకు సరిపోయే --tool-call-parser తో పాటు --enable-auto-tool-choice అవసరం. ఇందులో hermes, mistral, llama3_json మరియు ఇతర model families ఉంటాయి. Tool-role messages ను handle చేసే chat template కూడా అవసరం. ఈ మార్గానికి ఉన్న పరిమితులను vLLM documentation స్పష్టంగా చెబుతుంది. tool_choice="auto" ఉపయోగించి strict schema constraint లేకపోతే, vLLM raw text నుంచి tool calls ను extract చేస్తుంది. అందువల్ల arguments కొన్నిసార్లు తప్పుగా ఉండవచ్చు లేదా function యొక్క parameter schema ను ఉల్లంఘించవచ్చు. మీ modelకు తప్పు parser ఎంచుకోవడం configuration error. దీని ఫలితంగా agent tools ను call చేయలేనట్లు కనిపిస్తుంది. Traffic ను దానికి route చేయడానికి ముందు ఈ విషయం తెలుసుకోవాలి. మీరు స్వయంగా models అందించేటప్పుడు Ollama మరియు vLLM మధ్య తేడా ఇక్కడ ముఖ్యమైనది. ఎందుకంటే ఈ రెండూ tool calling ను వేర్వేరు విధానాల్లో అందిస్తాయి.

మధ్యలో fallback మారితే error లేకుండానే ప్రవర్తన మారుతుంది

Fallback routing అనుకోకుండా enable అయ్యే అవకాశం ఎక్కువగా ఉన్న feature. మొదటి model rate limit లేదా 5xx ను తిరిగి ఇస్తే మరో model తో retry చేయడానికి gateway ను configure చేస్తారు. తరువాత విఫలమైన model ను కొన్ని seconds పాటు cooldown లో ఉంచుతారు. Chat traffic కు ఇది సరైన విధానం. కానీ దీర్ఘ agent task లో, మీ ఎంపికలో లేని model పై task యొక్క రెండో భాగం అమలవుతుందని దీని అర్థం.

దీన్ని ఏదీ తెలియజేయదు. Task fail కాదు, agent warning ఇవ్వదు, exit status కూడా success గానే ఉంటుంది. ఒక model plan ను రాసి, మరో model edits చేసిన task మీకు లభిస్తుంది. మధ్యలో tone మరియు అలవాట్లు మారిపోతాయి. Gateway request log లేదా response metadata లోని model field మాత్రమే నమ్మదగిన సంకేతం. కాబట్టి fallbacks ఉపయోగిస్తే, ప్రతి request కు ఆ field ను log చేయండి. ఫలితం ఆశ్చర్యంగా ఉన్నప్పుడు దాన్ని పరిశీలించండి. ఏ model ఫలితాన్ని రూపొందించిందో తెలియకుండా behaviour ను debug చేయడం వల్ల fallback ఆదా చేసిన సమయం కంటే ఎక్కువ సమయం వృథా అవుతుంది.

ఇదే సమస్య context compression లో కూడా ఎదురవుతుంది. చాలా agents దీర్ఘ history ను చిన్న model ను పిలిచి summarise చేస్తాయి. ఆ call లో వేరే model లేదా వేరే system prompt ఉంటే, అది తన సొంత cache entry ను రాస్తుంది. ప్రధాన session యొక్క cache entry refresh కాదు. అందువల్ల తదుపరి పూర్తి turn కు cold prefix కోసం మళ్లీ చెల్లించాలి. Compression tokens ను ఆదా చేసినా cache ను కోల్పోయింది.

Routing overhead నిజమైనదే, కానీ latency ప్రభావం కలిగించే ప్రధాన కారణం కాదు

Routers ప్రతి request కు అదనపు పని చేస్తాయి. అయితే ఆ పని ఎంత ఉంటుందో ఖచ్చితంగా అర్థం చేసుకోవాలి. DigitalOcean ప్రకారం, వారి Arch-Router model routing intent ను సుమారు 51 milliseconds లో నిర్ణయిస్తుంది. వారి స్వంత evaluation లో routing accuracy 93.17% గా ఉంది. ఇవి వారి measurement మరియు benchmark ఆధారంగా ఇచ్చిన గణాంకాలు. ఇవి మా గణాంకాలు కావు. ఇవి ప్రతి సందర్భానికీ వర్తించే universal result కూడా కావు. ఈ గణాంకాలను అలాగే తీసుకుంటే, ఫలితం భరోసా కలిగిస్తుంది: 40 agent calls కు 51 milliseconds చొప్పున కలిపితే, అనేక నిమిషాలు నడిచే task కు సుమారు రెండు seconds మాత్రమే అదనంగా చేరతాయి.

ఇక్కడ routing ఖరీదైనదిగా మారడానికి కారణం రెండు seconds కాదు. ప్రభావం చూపే overhead ఏమిటంటే, router ప్రతి request ను full model call తో classify చేయడం. అప్పుడు ప్రతి request కు మరో inference జరుగుతుంది. అది ఇతర inference లాగే bill అవుతుంది మరియు queue లో వేచి ఉంటుంది. ఈ రెండింటి కింద పైన వివరించిన cache arithmetic ఉంటుంది. అది overhead కాదు. Routing optimize చేయాల్సిన అసలు పనికే అయ్యే ఖర్చు అది.

మీరు స్వయంగా నిర్వహించే server లో కూడా ఇదే నియమం వర్తిస్తుంది. అయితే మార్పులకు అవకాశం తక్కువగా ఉంటుంది. Prompt cache కు local equivalent, GPU memory లో ఉండే KV cache లోని prefix caching. ఒకే GPU పై రెండు models ను host చేస్తే, ఆ memory వాటి మధ్య పంచబడుతుంది. అందువల్ల ప్రతి model కు చిన్న KV cache మాత్రమే ఉంటుంది మరియు prefixes త్వరగా evict అవుతాయి. కాబట్టి రెండు local models మధ్య routing చేయడం వల్ల రెండింటి cache hit rate ఒకేసారి తగ్గవచ్చు. దీనికి hardware sizing చేస్తుంటే, router కంటే VPS పై coding agent కు వాస్తవంగా అవసరమైన memory మరియు CPU తో ప్రారంభించడం ఎక్కువ ఉపయోగకరం.

నిర్ణయ నియమం

• లభ్యత కోసం providers మధ్య route చేయండి. ప్రత్యామ్నాయం request విఫలమవడం అయితే, ఏ ఖర్చైనా సరైన ఖర్చే. fallback ను అదే tool call format ఉన్న model కు pin చేయండి. ప్రతి call ను ఏ model అందించిందో log చేయండి.
• task boundaries వద్ద మాత్రమే cost కోసం tiers మధ్య route చేయండి. rename కోసం Haiku, refactor కోసం Opus ఎంచుకోవడం session ప్రారంభానికి ముందు ఒకసారి తీసుకునే మంచి నిర్ణయం. అదే session లో turn thirty వద్ద తీసుకునే నిర్ణయం మాత్రం తప్పు.
• agentic పనుల కోసం ప్రతి session కు ఒక model ను pin చేయండి. session విలువ దాని warm cache లో ఉంటుంది. model మార్చడాన్ని cache clear చేయడంతో సమానంగా పరిగణించండి. ఎందుకంటే వాస్తవంగా జరిగేది అదే.
• subagents ను స్వేచ్ఛగా route చేయండి. fresh, small context తో ప్రారంభమయ్యే subagent కోల్పోవడానికి warm cache ఉండదు. అందువల్ల దాని పనికి సరిపోయే ఏ model పైనైనా దాన్ని నడపవచ్చు. agent లో routing దాదాపు ఉచితంగా ఉండే ఏకైక స్థలం ఇదే.

దీన్ని నిర్మించడానికి gateway పనిని నిర్వహిస్తుంది: model aliases మరియు explicit fallback lists. కనిష్ఠ LiteLLM proxy config ఇలా ఉంటుంది.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

agent ను agent-primary కు point చేస్తే, ఆ model అందుబాటులో లేనంత వరకు అది ఒకే model పై కొనసాగుతుంది. రెండు entries ఒకే provider లో ఉంటాయి. అందువల్ల fallback అమలైనప్పుడు tool call format మారదు. ఆ సమయంలో tier మార్పును మీరు అంగీకరించాల్సి ఉంటుంది. అయితే ప్రత్యామ్నాయం request విఫలమవడం కాబట్టి మాత్రమే ఆ trade-off విలువైనది. ఇది cost routing ను జోడించని availability routing. చాలా coding agents కోరుకునే కలయిక ఇదే. keys మరియు budgets తో సహా పూర్తి నిర్మాణం మీ స్వంత VPS పై self-hosted LiteLLM gateway ను నడపడం లో వివరించబడింది. ఈ post లో దాన్ని ఉద్దేశపూర్వకంగా మళ్లీ ఇవ్వలేదు.

ఒకే సరైన model ఏ router కంటే మెరుగ్గా పనిచేసే సందర్భం

అభ్యర్థనల క్లిష్టతలో తేడాలను నిర్వహించడానికి routing ఉపయోగపడుతుంది. Coding agent లో ఈ తేడాలు కనిపించేదానికంటే తక్కువగా ఉంటాయి. ఎందుకంటే ప్రతి call లో ఖరీదైన భాగం ఒకే prefix గా ఉంటుంది; call ఏం అడుగుతుందన్నది దానిని మార్చదు. Prefix ప్రధాన భాగంగా మారిన తర్వాత, మీ చవక tier మరియు ఖరీదైన tier మధ్య వ్యయ తేడా వాటి output ధరల తేడాకు దగ్గరవుతుంది. Agent ఉపయోగించే tokens లో output భాగం సాధారణంగా చిన్నదే.

అందువల్ల సాధారణంగా ఒకే model ను ఒకసారి ఎంచుకుని, caching ను ప్రారంభించి, మీరు diff చదవడానికి ఆగే విరామాలను కవర్ చేసేంత ఎక్కువ TTL (time to live) ఉంచడం మంచిది. Anthropic base input ధరకు 2 రెట్లతో one hour cache write అందిస్తుంది. ఇది రెండు reads తర్వాతే తన ఖర్చును భర్తీ చేస్తుంది. అందువల్ల ఏ router కంటే ఇది తరచుగా మెరుగైన నియంత్రణ సాధనం. Opus, Sonnet మరియు Haiku యొక్క నేరుగా పోలిక ఆధారంగా tier ను ఉద్దేశపూర్వకంగా ఎంచుకోండి. Bill ఇప్పటికీ సమస్యగా ఉంటే, mid-session switching కాకుండా VPSలో AI agent ఖర్చులను నియంత్రించడం లో చూపిన విధంగా budgets మరియు చిన్న contexts ఉపయోగించి ఖర్చును తగ్గించండి.

అభ్యర్థనలు పరస్పరం స్వతంత్రంగా మరియు చిన్నవిగా ఉన్నప్పుడు, లేదా subagents తాజా contexts తో ప్రారంభమైనప్పుడు route చేయండి. ఒకే పని చేసే ఒక దీర్ఘ session ఉన్నప్పుడు model ను స్థిరంగా ఉంచండి. ఎక్కువ coding agent పనులు రెండో రకానికి చెందుతాయి. అందుకే మీ chat product లో డబ్బు ఆదా చేసే router ఇక్కడ నిశ్శబ్దంగా మీకు అదనపు ఖర్చు కలిగించవచ్చు. మీరు ఇంకా agent ను ఎంచుకోకపోతే, Claude Code, Cursor, Codex మరియు Copilot పోలిక ప్రతి tool model selection ను ఎలా నిర్వహిస్తుందో వివరిస్తుంది. వీటిలో కొన్ని ఈ నిర్ణయాన్ని మీ బదులు తీసుకుంటాయి.

FAQ

సెషన్ మధ్యలో మోడల్ మార్చితే prompt cache నిజంగా కోల్పోతారా?

అవును. Prompt cacheలు prompt prefix యొక్క hash ఆధారంగా గుర్తించబడతాయి మరియు ప్రతి model కు విడిగా నిల్వ చేయబడతాయి. అందువల్ల వేరే model కు పంపిన request, ఆ prefix ను ఇంతకుముందు చూడని store పై hash అవుతుంది. దానికి ఏదీ కనిపించదు. పూర్తి uncached input ధర చెల్లించాలి. Caching ప్రారంభించి ఉంటే దానికి అదనంగా cache write ధర కూడా చెల్లించాలి. తిరిగి పాత model కు మారినా అసలు entry తిరిగి రాదు. సాధారణంగా అప్పటికి default five minute lifetime ముగిసిపోతుంది. Response usage object లోని cache_read_input_tokens మరియు cache_creation_input_tokens fields ను పరిశీలించండి. దీర్ఘమైన session లో cached tokens సంఖ్య zeroగా కనిపించడం దీనికి సంకేతం.

Agent కోసం తక్కువ ధర model కు routing చేయడం ఎప్పుడైనా చౌకగా ఉంటుందా?

కోల్పోయే warm cache లేనప్పుడు మాత్రమే. Anthropicలో cache read ధర base input ధరకు 0.1 రెట్లు ఉంటుంది. అందువల్ల Haiku 4.5లో uncached input ధర కంటే Opus 5లో warm read ధర తక్కువగా ఉంటుంది. Sessionలో పెద్ద cached prefix ఏర్పడిన తర్వాత, input పరంగా ప్రస్తుత model ఇప్పటికే చౌకైన ఎంపికగా ఉంటుంది. Context తాజాగా మరియు చిన్నగా ఉన్నప్పుడు routing ప్రయోజనకరంగా ఉంటుంది: task ప్రారంభంలో లేదా అవసరమైన context మాత్రమే తీసుకెళ్లే subagentలో.

Task మధ్యలో నా agent ప్రవర్తన ఎందుకు మారింది?

Gateway fallback అమలైందో లేదో పరిశీలించండి. Primary modelపై rate limit లేదా 5xx వచ్చినప్పుడు gateway standby modelపై retry చేస్తుంది. అలాగే primary modelను కొన్ని seconds పాటు cooldownలో ఉంచుతుంది. అందువల్ల task మిగిలిన భాగం వేరే చోట నడుస్తుంది. దీనివల్ల error లేదా warning కనిపించదు. Task విజయవంతమైందని కూడా నివేదించవచ్చు. Gateway request log లేదా response metadataలోని model field మాత్రమే నమ్మదగిన రికార్డు. మీరు fallbacks ఉపయోగిస్తే ప్రతి requestకు దాన్ని log చేయండి.

ప్రతి providerలో tool calls ఒకే విధంగా పనిచేస్తాయా?

ఖచ్చితంగా కాదు. Anthropic's Messages API tool_use మరియు tool_result content blocksను ఉపయోగిస్తుంది. OpenAI-compatible APIs tool_calls arrayను ఉపయోగిస్తాయి. ఆ arrayలోని function.arguments JSON-encoded stringగా ఉంటుంది. సాధారణ సందర్భాలను gateway బాగా అనువదిస్తుంది. అయితే parallel tool calls మరియు strict schema enforcement ప్రతి providerలో వేరుగా ఉంటాయి. Self-hosted vLLMలో మీ model familyకు సరిపోయే --enable-auto-tool-choice మరియు --tool-call-parser సెట్ చేయాలి. Strict schema constraint లేకపోతే server raw text నుంచి tool callsను extract చేస్తుందని vLLM documentation పేర్కొంటుంది. అందువల్ల arguments కొన్నిసార్లు malformedగా ఉండవచ్చు.

Coding session కోసం cache TTLను ఎంతకు సెట్ చేయాలి?

నిరంతర పని కోసం default five minute lifetime ఉపయోగించండి. Turns మధ్యలో మనిషి diffs చదివే సందర్భంలో one hour option ఉపయోగించండి. Anthropicలో five minute write ధర base input ధరకు 1.25 రెట్లు, one hour write ధర 2 రెట్లు ఉంటుంది. Read ధర 0.1 రెట్లు. ఒక readతో five minute write ఖర్చు తిరిగి వస్తుంది. రెండు readsతో one hour write ఖర్చు తిరిగి వస్తుంది. అందువల్ల తిరిగి వచ్చి కొనసాగిస్తారని ఆశించే ఏ sessionలోనైనా cold prefix కోసం మళ్లీ చెల్లించడం కంటే ఎక్కువ lifetime సాధారణంగా చౌకగా ఉంటుంది.