Coding agents के लिए Multi-model routing कैसे काम करता है

Multi-model routing का coding agent पर प्रभाव

Multi-model routing प्रत्येक request को सबसे सस्ते मॉडल पर भेजता है जो उसे प्रोसेस कर सके। Chat traffic पर यह अच्छा काम करता है। Coding agent के मामले में यह बचत से अधिक लागत बढ़ा देता है, क्योंकि agent का बिल मुख्य रूप से prompt prefix से बनता है जो प्रति मॉडल cache होता है, और मॉडल बदलने पर वह cache बेकार हो जाता है।

यह पोस्ट इस नियम का समर्थन करती है: उपलब्धता के लिए providers के बीच route करें, लागत के लिए केवल task boundaries पर tiers के बीच route करें, और agentic कार्यों के लिए प्रति session एक मॉडल को pin करें। नीचे दिया गया विवरण इसी तर्क पर आधारित है।

चार शब्द, जिनकी परिभाषा यहाँ दी गई है। Router प्रति request एक मॉडल चुनता है। Gateway वह proxy है जिससे होकर request गुजरती है, जो routing कर भी सकता है और नहीं भी। Prompt cache वह सुविधा है जहाँ provider आपके prompt के प्रोसेस किए गए prefix को store करता है, ताकि उसी prefix को दोहराने वाली बाद की request पर input मूल्य का केवल एक छोटा हिस्सा ही charge किया जाए। KV cache (key value cache) वही अवधारणा है जो आपके द्वारा चलाए जा रहे सर्वर के भीतर काम करती है।

चैट ट्रैफिक आसानी से राउट क्यों होता है और एजेंट ट्रैफिक क्यों नहीं

चैट रिक्वेस्ट एक टर्न (turn) की प्रक्रिया है। यह आती है, वर्गीकृत होती है, मॉडल के पास जाती है और परिणाम वापस आता है। इसमें कोई भी जानकारी अगली रिक्वेस्ट तक नहीं जाती। एक राउटर इस प्रश्न को एक छोटे मॉडल पर और अगले प्रश्न को एक बड़े मॉडल पर भेज सकता है, और किसी भी रिक्वेस्ट को यह पता नहीं होता कि दूसरी रिक्वेस्ट हुई थी। यह वह वर्कलोड है जिसे लगभग हर राउटिंग बेंचमार्क मापता है, और अच्छे राउटर इसमें वास्तव में सक्षम हैं।

एजेंट टर्न एक रिक्वेस्ट नहीं है। "fix the failing test" जैसा एक निर्देश बीस से साठ API कॉल्स में बदल जाता है। प्रत्येक कॉल पूरी बातचीत को फिर से भेजती है: सिस्टम प्रॉम्प्ट, प्रत्येक टूल की परिभाषा, एजेंट द्वारा पढ़ी गई प्रत्येक फाइल, और उसके द्वारा देखा गया प्रत्येक कमांड आउटपुट। कॉन्टेक्स्ट केवल बढ़ता जाता है। तीसवीं कॉल तक, दोहराया गया प्रीफिक्स हजारों टोकन का हो सकता है, जबकि प्रत्येक कॉल में वास्तव में नई सामग्री केवल कुछ सौ टोकन की होती है।

यह स्वरूप इस बात को बदल देता है कि "महंगा" शब्द का क्या अर्थ है। चैट में, लागत लगभग मॉडल की कीमत और रिक्वेस्ट का गुणनफल होती है। एजेंट लूप में, लागत वह प्रीफिक्स है, जिसका बिल हर एक कॉल पर फिर से बनता है। इस पोस्ट का बाकी हिस्सा इसी एक तथ्य पर आधारित है।

Prompt cache प्रति मॉडल होता है और एजेंट इसके भीतर रहता है

Anthropic, cache read की कीमत आधार इनपुट मूल्य का 0.1 गुना और पांच मिनट के cache write की कीमत 1.25 गुना निर्धारित करता है। ये अगस्त 2026 तक प्रकाशित सूची मूल्य हैं।

[
  {
    "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 की कीमत प्रति मिलियन टोकन 0.50 डॉलर है। Haiku 4.5 पर, जो कि सूचीबद्ध सबसे सस्ता मॉडल है, uncached इनपुट की कीमत 1.00 डॉलर है। इसलिए, सबसे महंगे मॉडल पर एक warm prefix को दोबारा पढ़ने की लागत, सबसे सस्ते मॉडल पर उसी prefix को cold पढ़ने की तुलना में प्रति इनपुट टोकन कम होती है।

यह एक तुलना अधिकांश routing योजनाओं को विफल कर देती है। जो router काम को एक स्तर "नीचे" भेजता है, वह सूची मूल्यों की तुलना कर रहा होता है। लेकिन सत्र के बीच में काम कर रहा एक एजेंट उस मॉडल पर सूची मूल्य नहीं चुका रहा होता है जिसका वह पहले से उपयोग कर रहा है। वह cache read मूल्य चुका रहा होता है, जो पहले से ही सस्ते मॉडल की uncached दर से कम है।

Caches, prompt prefix के hash पर आधारित होते हैं और ये प्रति मॉडल होते हैं। किसी भिन्न मॉडल के लिए किया गया अनुरोध एक ऐसे store के विरुद्ध hash होता है जिसने इसे पहले कभी नहीं देखा है, इसलिए उसे कुछ नहीं मिलता और वह पूरी कीमत चुकाता है। Cache एक पदानुक्रम (hierarchy) भी है: पहले tools, फिर system, और फिर messages। किसी भी स्तर पर किया गया परिवर्तन उस स्तर और उसके बाद की हर चीज़ को अमान्य कर देता है, जिसका अर्थ है कि एक tool definition को संपादित करने से उसके पीछे मौजूद system prompt cache समाप्त हो जाता है। जो एजेंट runtime पर tools को register करते हैं, वे router को छुए बिना ही इसका सामना करते हैं।

एक mid-session switch की वास्तविक लागत

एक ऐसे session पर विचार करें जिसमें 40,000 tokens का stable prefix हो, जो कि किसी agent द्वारा कुछ files पढ़ लेने के बाद एक सामान्य आकार है। नीचे एक single turn की prefix लागत दी गई है, जिसकी गणना ऊपर दी गई list prices के आधार पर की गई है।

[
  {
    "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"
  }
]

Opus 5 पर बने रहने और warm cache का उपयोग करने पर उस turn के prefix के लिए 0.020 dollars का खर्च आता है। Sonnet 5 पर routing करने के बाद पहले turn की लागत 0.100 dollars होती है, क्योंकि Sonnet के पास इस prefix के लिए कोई entry नहीं होती और उसे एक नई entry लिखनी पड़ती है। वापस Opus 5 पर आने की लागत 0.250 dollars होती है, क्योंकि session के बाहर रहने के दौरान मूल entry expire हो चुकी होती है।

इस प्रकार, round trip में दो cache reads से बचने के लिए दो cache writes का भुगतान करना पड़ता है। इसके बदले, switch ने Opus की output price के बजाय Sonnet की output price पर एक turn का output प्राप्त किया। details block में पूरी यात्रा का विवरण दिया गया है: बचत एक cent के अंश में होती है, जबकि cache penalty दसियों cents में होती है। penalty का आकार बचत से एक order of magnitude से भी अधिक बड़ा है, और यह prefix की लंबाई के साथ बढ़ता है, जबकि बचत नहीं बढ़ती।

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

विभिन्न प्रदाताओं के बीच टूल कॉल फॉर्मेट समान नहीं होते हैं

एक एजेंट एक टूल-कॉलिंग लूप होता है, इसलिए टूल कॉल का फॉर्मेट उस तरह मायने रखता है जैसा चैट के लिए कभी नहीं होता। Anthropic का Messages API एक tool_use कंटेंट ब्लॉक लौटाता है और बदले में एक tool_result ब्लॉक की अपेक्षा करता है। OpenAI-संगत API एक tool_calls ऐरे लौटाते हैं जिसमें function.arguments एक JSON-एन्कोडेड स्ट्रिंग होता है, न कि नेस्टेड ऑब्जेक्ट। एक गेटवे इन दोनों के बीच अनुवाद करता है, और सामान्य कॉल्स के लिए यह अनुवाद स्पष्ट होता है।

समस्याएं किनारों पर दिखाई देती हैं। पैरेलल टूल कॉल्स, जहाँ एक मॉडल एक ही रिस्पॉन्स में कई कॉल्स उत्सर्जित करता है, उन्हें अलग-अलग तरीके से दर्शाया जाता है और वे हर जगह समान रूप से समर्थित नहीं होते हैं। सख्त स्कीमा प्रवर्तन (strict schema enforcement) एक प्रति-प्रदाता सुविधा है, इसलिए जो मॉडल एक एंडपॉइंट पर स्कीमा-वैध तर्कों की गारंटी देता है, वह दूसरे पर केवल वैध तर्कों की ओर प्रवृत्त होता है। एजेंट इस अंतर को एक टूल परिणाम के रूप में देखता है जिसमें पार्स त्रुटि होती है, जिसे वह फिर एक और टर्न खर्च करके ठीक करने का प्रयास करता है। वे रिपेयर टर्न पूरे प्रीफिक्स मूल्य पर बिल किए जाते हैं, इसलिए फॉर्मेट का मेल न खाना ट्रांसक्रिप्ट के साथ-साथ इनवॉइस पर भी दिखाई देता है।

सेल्फ-होस्टेड एंडपॉइंट्स को इसे स्पष्ट रूप से कॉन्फ़िगर करने की आवश्यकता होती है। vLLM के OpenAI-संगत सर्वर को --enable-auto-tool-choice की आवश्यकता होती है, साथ ही मॉडल परिवार (hermes, mistral, llama3_json और अन्य) से मेल खाने वाला एक --tool-call-parser, और एक चैट टेम्प्लेट जो टूल-रोल संदेशों को संभालता है। vLLM दस्तावेज़ीकरण इस पथ की सीमाओं के बारे में सीधा है: tool_choice="auto" के साथ और बिना किसी सख्त स्कीमा बाधा के, vLLM रॉ टेक्स्ट से टूल कॉल्स निकालता है, इसलिए तर्क कभी-कभी गलत हो सकते हैं या फंक्शन के पैरामीटर स्कीमा का उल्लंघन कर सकते हैं। अपने मॉडल के लिए गलत पार्सर चुनना एक कॉन्फ़िगरेशन त्रुटि है जो एक ऐसे एजेंट के रूप में सामने आती है जो टूल कॉल नहीं कर सकता, जिसे उस पर ट्रैफिक रूट करने से पहले जानना महत्वपूर्ण है। यहाँ स्वयं मॉडल सर्व करने के लिए Ollama और vLLM के बीच का अंतर मायने रखता है, क्योंकि दोनों अलग-अलग शर्तों पर टूल कॉलिंग को एक्सपोज़ करते हैं।

मध्य-कार्य फॉलबैक बिना किसी त्रुटि के व्यवहार बदल देता है

Fallback routing वह फीचर है जिसके गलती से इनेबल होने की संभावना सबसे अधिक होती है। एक गेटवे को इस तरह कॉन्फ़िगर किया जाता है कि जब पहला मॉडल रेट लिमिट या 5xx त्रुटि देता है, तो वह दूसरे मॉडल पर पुनः प्रयास (retry) करे, और फिर विफल मॉडल को कुछ सेकंड के लिए कूलडाउन में डाल दे। चैट ट्रैफ़िक पर यह बिल्कुल सही काम करता है। लेकिन एक लंबे एजेंट कार्य के भीतर, इसका मतलब यह है कि आपके कार्य का दूसरा भाग उस मॉडल पर चला जिसे आपने चुना ही नहीं था।

इसकी रिपोर्ट कहीं नहीं मिलती। कार्य विफल नहीं होता, एजेंट कोई चेतावनी नहीं देता, और एग्जिट स्टेटस 'सफलता' (success) दिखाता है। आपको जो परिणाम मिलता है, वह एक ऐसा कार्य है जिसकी योजना एक मॉडल द्वारा बनाई गई थी और संपादन दूसरे द्वारा, जिसके कारण आधे रास्ते में ही टोन और कार्य करने के तरीके बदल जाते हैं। एकमात्र विश्वसनीय संकेत गेटवे के रिक्वेस्ट लॉग या रिस्पॉन्स मेटाडेटा में मौजूद model फ़ील्ड है। इसलिए, यदि आप फॉलबैक का उपयोग करते हैं, तो प्रति रिक्वेस्ट इस फ़ील्ड को लॉग करें और जब परिणाम अप्रत्याशित हो, तो इसे पढ़ें। यह जाने बिना कि किस मॉडल ने परिणाम उत्पन्न किया है, व्यवहार को डीबग करने में फॉलबैक द्वारा बचाए गए समय से कहीं अधिक समय बर्बाद होता है।

यही समस्या कॉन्टेक्स्ट कम्प्रेशन (context compression) में भी आती है। कई एजेंट एक छोटे मॉडल को कॉल करके लंबे इतिहास का सारांश (summarise) तैयार करते हैं। यदि वह कॉल किसी अलग मॉडल या अलग सिस्टम प्रॉम्प्ट का उपयोग करती है, तो वह अपनी स्वयं की कैश एंट्री लिखती है और मुख्य सत्र (main session) के कैश को रिफ्रेश नहीं करती है। परिणामस्वरूप, अगली बार जब पूरा टर्न चलता है, तो उसे कोल्ड प्रीफ़िक्स (cold prefix) की कीमत चुकानी पड़ती है। कम्प्रेशन ने टोकन तो बचा लिए, लेकिन कैश खो दिया।

Routing overhead वास्तविक है, लेकिन latency वह जगह नहीं है जहाँ यह नुकसान पहुँचाती है

Routers प्रत्येक request पर काम बढ़ाते हैं, और यह सटीक होना जरूरी है कि कितना। DigitalOcean की रिपोर्ट है कि उनका Arch-Router model लगभग 51 milliseconds में routing intent को resolve करता है, और उनके अपने मूल्यांकन में routing accuracy 93.17% है। ये उनके आंकड़े हैं, जो उनके मापन और benchmark से लिए गए हैं, न कि हमारे, और न ही ये कोई सार्वभौमिक परिणाम हैं। यदि इन्हें ज्यों का त्यों स्वीकार किया जाए, तो निष्कर्ष आश्वस्त करने वाला है: चालीस agent calls में 51 milliseconds का समय उस कार्य में लगभग दो सेकंड जोड़ता है जो कई मिनटों तक चलता है।

दो सेकंड वह कारण नहीं है जिससे यहाँ routing महंगी हो जाती है। जो overhead वास्तव में नुकसान पहुँचाता है, वह router है जो full model call के साथ classify करता है, क्योंकि यह प्रत्येक request पर एक दूसरी inference है, जिसे किसी अन्य की तरह ही bill किया जाता है और queue में रखा जाता है। इन दोनों के नीचे ऊपर दी गई cache arithmetic स्थित है, जो वास्तव में कोई overhead नहीं है। यह उस चीज की लागत है जिसे routing को optimize करना था।

अपने द्वारा चलाए जाने वाले सर्वर पर, वही नियम कम गुंजाइश के साथ लागू होता है। Prompt cache का स्थानीय समकक्ष KV cache में prefix caching है, जो GPU memory में रहता है। एक GPU पर दो models host करने से वह memory उनके बीच विभाजित हो जाती है, इसलिए प्रत्येक के पास छोटा KV cache रहता है और prefixes जल्दी हट जाते हैं। इसलिए दो स्थानीय models के बीच routing करने से दोनों के लिए cache hit rate एक साथ कम हो सकती है। यदि आप इसके लिए hardware का आकार निर्धारित कर रहे हैं, तो एक coding agent को VPS पर वास्तव में कितनी memory और CPU की आवश्यकता होती है router की तुलना में शुरुआत करने के लिए अधिक उपयोगी स्थान है।

निर्णय का नियम

• उपलब्धता के लिए प्रदाताओं के बीच रूट करें। जब विकल्प एक विफल अनुरोध हो, तो कोई भी लागत सही लागत है। फॉलबैक को उसी टूल कॉल फॉर्मेट वाले मॉडल पर पिन करें ताकि एजेंट का लूप काम करता रहे, और लॉग करें कि किस मॉडल ने प्रत्येक कॉल को सर्व किया।
• केवल कार्य सीमाओं (task boundaries) पर लागत के लिए टियर्स (tiers) के बीच रूट करें। रीनेम के लिए Haiku और रिफैक्टर के लिए Opus चुनना एक अच्छा निर्णय है जो सत्र शुरू होने से पहले एक बार लिया जाता है। सत्र के तीसवें टर्न पर यह निर्णय लेना गलत है।
• एजेंटिक कार्यों के लिए प्रति सत्र एक मॉडल पिन करें। एक सत्र का मूल्य उसका वार्म कैश (warm cache) है। मॉडल बदलने को वैसे ही देखें जैसे आप उस कैश को क्लियर करने को देखते हैं, क्योंकि यह वास्तव में वही करता है।
• सब-एजेंट्स को स्वतंत्र रूप से रूट करें। एक सब-एजेंट जो एक नए, छोटे संदर्भ (context) के साथ शुरू होता है, उसके पास खोने के लिए कोई वार्म कैश नहीं होता है, इसलिए वह अपने काम के अनुकूल किसी भी मॉडल पर चल सकता है। यह एजेंट के अंदर एकमात्र ऐसी जगह है जहाँ रूटिंग लगभग मुफ्त है।

इसे बनाने के तरीके के लिए, गेटवे काम करता है: मॉडल उपनाम (aliases) और स्पष्ट फॉलबैक सूचियाँ। एक न्यूनतम LiteLLM प्रॉक्सी कॉन्फ़िगरेशन इस तरह दिखता है।

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-primary पर पॉइंट करें और यह एक ही मॉडल पर तब तक रहता है जब तक कि वह मॉडल पहुंच योग्य न हो। दोनों प्रविष्टियाँ एक ही प्रदाता पर स्थित हैं, इसलिए फॉलबैक सक्रिय होने पर टूल कॉल फॉर्मेट नहीं बदलता है। आप उस क्षण टियर परिवर्तन स्वीकार करते हैं, जो केवल इसलिए एक सार्थक समझौता है क्योंकि विकल्प एक विफल अनुरोध है। यह बिना लागत रूटिंग के साथ उपलब्धता रूटिंग है, जो वह संयोजन है जिसे अधिकांश कोडिंग एजेंट चाहते हैं। कुंजियों और बजट सहित पूर्ण निर्माण, अपने स्वयं के VPS पर self-hosted LiteLLM gateway चलाना में कवर किया गया है, और यह पोस्ट जानबूझकर इसे दोहराती नहीं है।

जब एक सही चुना हुआ मॉडल किसी भी राउटर से बेहतर प्रदर्शन करता है

Routing अनुरोध की कठिनाई में आने वाले अंतर (variance) का समाधान है। एक कोडिंग एजेंट में यह अंतर उतना नहीं होता जितना दिखता है, क्योंकि हर कॉल का महंगा हिस्सा वही prefix होता है, चाहे कॉल में कुछ भी पूछा गया हो। एक बार जब prefix का प्रभाव बढ़ जाता है, तो आपके सस्ते और महंगे टियर के बीच का अंतर उनके output मूल्यों के अंतर तक सिमट जाता है, और एक एजेंट के कुल tokens में output का हिस्सा बहुत कम होता है।

इसलिए, सबसे ईमानदार डिफ़ॉल्ट तरीका यह है कि एक मॉडल चुनें, उसे एक बार सेट करें, caching चालू रखें और TTL (time to live) को इतना लंबा रखें कि वह उन अंतरालों को कवर कर सके जब आप diff पढ़ने के लिए रुकते हैं। Anthropic 2 गुना base input पर एक घंटे का cache write प्रदान करता है, जो दो बार पढ़ने के बाद ही अपनी लागत वसूल कर लेता है, और यह किसी भी राउटर की तुलना में अक्सर बेहतर विकल्प होता है। Opus, Sonnet और Haiku की सीधी तुलना का उपयोग करके सोच-समझकर टियर चुनें, और यदि बिल अभी भी समस्या है, तो mid-session स्विचिंग के बजाय VPS पर AI एजेंट की लागत को नियंत्रित करने के तरीके अपनाकर बजट और छोटे contexts के साथ खर्च कम करें।

Routing तब करें जब अनुरोध स्वतंत्र और छोटे हों, या जब subagents नए contexts के साथ शुरू हों। Pinning तब करें जब आपके पास एक ही काम करने वाला एक लंबा session हो। अधिकांश कोडिंग एजेंट का काम दूसरे प्रकार का होता है, यही कारण है कि जो राउटर आपके चैट प्रोडक्ट पर पैसे बचाता है, वह यहाँ चुपचाप आपका खर्च बढ़ा देगा। यदि आपने अभी तक एजेंट का चयन नहीं किया है, तो Claude Code की Cursor, Codex और Copilot के साथ तुलना यह बताती है कि प्रत्येक टूल मॉडल चयन को कैसे संभालता है, और उनमें से कुछ यह निर्णय आपके लिए पहले ही ले लेते हैं।

FAQ

क्या सेशन के बीच में मॉडल बदलने से प्रॉम्प्ट कैश वास्तव में खत्म हो जाता है?

हाँ। प्रॉम्प्ट कैश प्रॉम्प्ट प्रीफिक्स के हैश पर आधारित होते हैं और प्रति मॉडल स्टोर किए जाते हैं। इसलिए, किसी दूसरे मॉडल पर भेजा गया अनुरोध ऐसे स्टोर के विरुद्ध हैश होता है जिसने उस प्रीफिक्स को कभी नहीं देखा है। इसे कुछ नहीं मिलता और यह पूरी uncached इनपुट कीमत चुकाता है, और यदि कैशिंग सक्षम है तो ऊपर से कैश राइट की कीमत भी चुकानी पड़ती है। वापस स्विच करने पर भी मूल एंट्री रिकवर नहीं होती, क्योंकि तब तक डिफ़ॉल्ट पांच मिनट की लाइफटाइम आमतौर पर समाप्त हो चुकी होती है। रिस्पॉन्स यूसेज ऑब्जेक्ट में cache_read_input_tokens और cache_creation_input_tokens फ़ील्ड्स की जाँच करें: एक लंबा सेशन जिसमें शून्य कैश टोकन रीड होते हैं, इसका मुख्य लक्षण है।

क्या किसी एजेंट के लिए सस्ते मॉडल पर रूटिंग करना कभी सस्ता पड़ता है?

केवल तब, जब खोने के लिए कोई वार्म कैश न हो। Anthropic पर कैश रीड की कीमत बेस इनपुट का 0.1 गुना होती है, जो Opus 5 पर वार्म रीड को Haiku 4.5 की uncached इनपुट दर से नीचे ले आती है। एक बार जब किसी सेशन में एक बड़ा कैश किया हुआ प्रीफिक्स होता है, तो मौजूदा मॉडल इनपुट पर पहले से ही सस्ता विकल्प होता है। रूटिंग तब फायदेमंद होती है जब कॉन्टेक्स्ट नया और छोटा हो: किसी कार्य की शुरुआत में, या किसी ऐसे सब-एजेंट में जो केवल आवश्यक कॉन्टेक्स्ट ही साथ रखता है।

कार्य के बीच में मेरा एजेंट अलग व्यवहार क्यों करने लगा?

जाँचें कि क्या कोई गेटवे फॉलबैक ट्रिगर हुआ था। प्राइमरी मॉडल पर रेट लिमिट या 5xx एरर आने पर गेटवे स्टैंडबाय मॉडल पर पुनः प्रयास करता है और प्राइमरी को कुछ सेकंड के लिए कूलडाउन में डाल देता है, जिससे कार्य का शेष भाग कहीं और चलता है। इसमें कोई एरर या चेतावनी नहीं मिलती और कार्य सफल रिपोर्ट होता है। गेटवे रिक्वेस्ट लॉग या रिस्पॉन्स मेटाडेटा में model फ़ील्ड ही एकमात्र विश्वसनीय रिकॉर्ड है, इसलिए यदि आप फॉलबैक का उपयोग करते हैं तो इसे प्रति रिक्वेस्ट लॉग करें।

क्या टूल कॉल्स हर प्रोवाइडर पर एक समान काम करते हैं?

बिल्कुल नहीं। Anthropic का Messages API tool_use और tool_result कंटेंट ब्लॉक्स का उपयोग करता है, जबकि OpenAI-संगत API एक tool_calls ऐरे का उपयोग करते हैं जिसका function.arguments एक JSON-एन्कोडेड स्ट्रिंग होता है। एक गेटवे सामान्य मामलों को अच्छी तरह से ट्रांसलेट करता है, लेकिन पैरेलल टूल कॉल्स और सख्त स्कीमा एन्फोर्समेंट हर प्रोवाइडर के लिए अलग होते हैं। सेल्फ-होस्टेड vLLM पर आपको --enable-auto-tool-choice और अपने मॉडल परिवार से मेल खाता --tool-call-parser सेट करना होगा। vLLM डॉक्यूमेंटेशन नोट करता है कि सख्त स्कीमा बाधा के बिना सर्वर रॉ टेक्स्ट से टूल कॉल्स निकालता है, इसलिए तर्क (arguments) कभी-कभी गलत फॉर्मेट में हो सकते हैं।

कोडिंग सेशन के लिए मुझे कैश TTL कितना सेट करना चाहिए?

निरंतर काम के लिए डिफ़ॉल्ट पांच मिनट की लाइफटाइम का उपयोग करें, और जब कोई व्यक्ति टर्न्स के बीच डिफ्स (diffs) पढ़ रहा हो तो एक घंटे वाले विकल्प का उपयोग करें। Anthropic पांच मिनट वाले राइट की कीमत बेस इनपुट का 1.25 गुना और एक घंटे वाले राइट की कीमत 2 गुना रखता है, जबकि रीड की कीमत 0.1 गुना है। पांच मिनट वाला राइट एक ही रीड से वसूल हो जाता है, और एक घंटे वाला राइट दो रीड से। इसलिए, किसी भी ऐसे सेशन में जहाँ आप वापस आकर काम जारी रखने की उम्मीद करते हैं, लंबी लाइफटाइम आमतौर पर कोल्ड प्रीफिक्स के लिए भुगतान करने से सस्ती पड़ती है।