coding agents साठी multi-model routing कधी फायदेशीर?

कोडिंग एजंटवर multi-model routing चा परिणाम

multi-model routing प्रत्येक विनंती हाताळू शकणाऱ्या सर्वात स्वस्त model कडे पाठवते. Chat traffic साठी ही पद्धत चांगली काम करते. मात्र coding agent साठी बचत होण्याऐवजी खर्च वाढतो. याचे कारण असे की agent च्या बिलाचा मोठा भाग प्रत्येक model साठी cache केलेल्या prompt prefix मुळे ठरतो आणि model बदलल्यावर तो cache नष्ट होतो.

या लेखाचा युक्तिवाद असा आहे: उपलब्धतेसाठी providers मध्ये routing करा; खर्चासाठी tiers मध्ये routing फक्त task boundaries वर करा; आणि agent स्वरूपाच्या कामासाठी प्रत्येक session मध्ये एकच model निश्चित ठेवा. पुढील सर्व भागांमध्ये यामागील कारणे स्पष्ट केली आहेत.

चार संज्ञा एकदाच स्पष्ट करूया. router प्रत्येक विनंतीसाठी एक model निवडतो. gateway हा असा proxy आहे ज्यामधून विनंती जाते; तो routing करेलच असे नाही. prompt cache म्हणजे provider तुमच्या prompt चा प्रक्रिया केलेला prefix साठवतो, ज्यामुळे पुढील विनंतीत तोच prefix पुन्हा आल्यास input price च्या काही अंशाइतकेच शुल्क आकारले जाते. KV cache (key value cache) हीच संकल्पना तुम्ही स्वतः चालवत असलेल्या server च्या आत लागू होते.

चॅट ट्रॅफिक योग्य प्रकारे रूट होते, पण एजंट ट्रॅफिक तसे का होत नाही

चॅट विनंती म्हणजे एक turn असतो. ती येते, तिचे वर्गीकरण होते, ती मॉडेलकडे जाते आणि उत्तर परत येते. पुढील विनंतीपर्यंत काहीही पुढे नेले जात नाही. Router हा प्रश्न छोट्या मॉडेलकडे आणि पुढील प्रश्न मोठ्या मॉडेलकडे पाठवू शकतो. या दोन्ही विनंत्यांना एकमेकी घडल्याचे माहीत नसते. जवळजवळ प्रत्येक routing benchmark या workload चे मोजमाप करते आणि चांगले router हे काम खरोखर चांगल्या प्रकारे करतात.

एजंट turn म्हणजे एकच विनंती नसते. "अपयशी test दुरुस्त करा" यासारखी एक सूचना 20 ते 60 API calls मध्ये रूपांतरित होऊ शकते. प्रत्येक call मध्ये संपूर्ण conversation पुन्हा पाठवली जाते: system prompt, प्रत्येक tool definition, एजंटने वाचलेली प्रत्येक file आणि त्याने पाहिलेला प्रत्येक command output. Context सतत वाढत जातो. 30 व्या call पर्यंत पुन्हा पाठवला जाणारा prefix हजारो tokens चा होऊ शकतो, तर प्रत्येक call मधील खरोखर नवीन content काहीशे tokens इतकाच असतो.

या रचनेमुळे "महाग" या शब्दाचा अर्थ बदलतो. चॅटमध्ये खर्च साधारणपणे मॉडेलची किंमत आणि विनंती यांच्या गुणाकाराइतका असतो. एजंट loop मध्ये प्रत्येक call साठी prefix चा पुन्हा स्वतंत्रपणे खर्च आकारला जातो. या एका वस्तुस्थितीवर पुढील संपूर्ण लेख आधारित आहे.

Prompt cache प्रत्येक model साठी स्वतंत्र असतो आणि agent त्याच्यामध्ये राहतो

Anthropic cache read साठी मूळ input price च्या 0.1 पट आणि पाच मिनिटांच्या cache write साठी 1.25 पट शुल्क आकारते. ऑगस्ट 2026 पर्यंतची ही प्रकाशित 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"
  }
]

दुसरी series पहिल्या series शी आडव्या दिशेने, म्हणजेच columns ऐवजी rows नुसार, तुलना करा. Opus 5 वर cache read ची किंमत प्रति दशलक्ष tokens 0.50 dollars आहे. सूचीतील सर्वांत स्वस्त model असलेल्या Haiku 4.5 वर uncached input ची किंमत 1.00 dollars आहे. त्यामुळे सर्वांत महाग model वर warm prefix पुन्हा वाचण्याची प्रति input token किंमत, सर्वांत स्वस्त model वर तोच prefix cold स्थितीत वाचण्यापेक्षा कमी असते.

या एका तुलनेमुळे बहुतेक routing plans अपुरे ठरतात. Router काम एका tier वरून "खाली" हलवत असताना list prices ची तुलना करतो. परंतु session सुरू असलेल्या agent कडून तो आधी वापरत असलेल्या model साठी list price आकारली जात नाही. त्याच्याकडून cache read price आकारली जाते. ही किंमत स्वस्त model च्या uncached rate पेक्षाही आधीपासून कमी असते.

Caches prompt prefix च्या hash वर आधारित असतात आणि प्रत्येक model साठी स्वतंत्र असतात. वेगळ्या model कडे केलेली request अशा store विरुद्ध hash केली जाते ज्याने तो prefix कधी पाहिलेला नसतो. त्यामुळे cache मध्ये काही सापडत नाही आणि पूर्ण किंमत आकारली जाते. Cache ही hierarchy देखील असते: प्रथम tools, त्यानंतर system आणि त्यानंतर messages. कोणत्याही स्तरावर केलेला बदल त्या स्तराला आणि त्यानंतरच्या सर्व स्तरांना invalid करतो. त्यामुळे एका tool definition मध्ये केलेल्या बदलामुळे त्यामागे असलेला system prompt cache discard होतो. Runtime मध्ये tools register करणाऱ्या agents ना हा परिणाम router मध्ये कोणताही बदल न करता जाणवतो.

एका सत्राच्या मध्यात केलेल्या एका switch ची प्रत्यक्ष किंमत

40,000 token चा स्थिर prefix असलेले सत्र घ्या. Agent ने काही फाइल्स वाचल्यानंतर हा सामान्य आकार असतो. वरील 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"
  }
]

Warm cache सह Opus 5 वरच राहिल्यास त्या turn च्या prefix साठी 0.020 dollars खर्च होतात. Sonnet 5 कडे routing केल्यानंतरचा पहिला turn 0.100 dollars खर्च करतो, कारण Sonnet कडे या prefix साठी कोणतीही entry नसते आणि त्याला एक entry लिहावी लागते. पुन्हा Opus 5 वर आल्यावर 0.250 dollars खर्च होतात, कारण सत्र Sonnet वर असताना मूळ entry expire झालेली असते.

म्हणून round trip मध्ये दोन cache reads टाळण्यासाठी दोन cache writes करावे लागतात. त्या बदल्यात switch मुळे एका turn च्या output साठी Opus ऐवजी Sonnet ची किंमत लागू होते. Details block मध्ये संपूर्ण गणना दाखवली आहे: saving एका cent च्या अपूर्णांकाइतकी आहे, तर cache penalty दहा-दहा cents इतकी आहे. हा penalty एक order of magnitude पेक्षा जास्त मोठा आहे. Prefix ची लांबी वाढली की तो वाढतो, पण 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 च्या Messages API कडून tool_use content block मिळतो आणि त्याच्या प्रत्युत्तरात tool_result block अपेक्षित असतो. OpenAI-compatible APIs tool_calls array परत करतात. त्यामध्ये function.arguments हा nested object नसून JSON-encoded string असतो. Gateway या दोन्ही format मध्ये रूपांतर करते. सामान्य calls साठी हे रूपांतर व्यवस्थित होते.

अडचणी विशेष परिस्थितींमध्ये दिसतात. Parallel tool calls मध्ये model एका response मध्ये अनेक calls पाठवतो. त्यांचे प्रतिनिधित्व वेगवेगळे असते आणि सर्व ठिकाणी त्यांना समान प्रकारे support केले जात नाही. Strict schema enforcement हे प्रत्येक provider वर स्वतंत्रपणे उपलब्ध असते. त्यामुळे एका endpoint वर schema-valid arguments ची हमी देणारे model दुसऱ्या endpoint वर फक्त valid arguments देण्याकडे झुकते. Agent ला हा फरक parse error असलेल्या tool result च्या रूपात दिसतो. तो आणखी एक turn खर्च करून तो error दुरुस्त करण्याचा प्रयत्न करतो. या repair turns साठी पूर्ण prefix price आकारला जातो. त्यामुळे format mismatch transcript मध्येच नव्हे, तर invoice वरही दिसतो.

Self-hosted endpoints साठी ही रचना स्पष्टपणे configure करावी लागते. vLLM च्या OpenAI-compatible server ला --enable-auto-tool-choice आणि model family शी जुळणारा --tool-call-parser (hermes, mistral, llama3_json आणि इतर) आवश्यक असतो. तसेच tool-role messages हाताळणारा chat template देखील आवश्यक असतो. या मार्गाच्या मर्यादांबाबत vLLM documentation स्पष्ट आहे: tool_choice="auto" वापरले असताना आणि strict schema constraint नसताना, vLLM raw text मधून tool calls काढतो. त्यामुळे arguments कधीकधी चुकीच्या format मध्ये येऊ शकतात किंवा function च्या parameter schema चे उल्लंघन करू शकतात. तुमच्या model साठी चुकीचा parser निवडणे ही configuration error आहे. त्याचा परिणाम agent tools call करू शकत नाही अशा स्वरूपात दिसतो. Traffic त्या endpoint कडे पाठवण्यापूर्वी ही बाब माहिती असणे उपयुक्त ठरते. Ollama आणि vLLM वर स्वतः models serve करण्यामधील फरक येथे महत्त्वाचा आहे, कारण दोन्ही tool calling वेगवेगळ्या पद्धतीने उपलब्ध करून देतात.

मध्यवर्ती टप्प्यातील fallback मुळे त्रुटी न दाखवता वर्तन बदलते

चुकून सक्षम होण्याची सर्वाधिक शक्यता असलेले feature म्हणजे fallback routing. पहिल्या model कडून rate limit किंवा 5xx मिळाल्यावर gateway ने दुसऱ्या model वर पुन्हा प्रयत्न करावा, अशी configuration केली जाते. त्यानंतर काही seconds साठी अपयशी model cooldown मध्ये ठेवला जातो. Chat traffic साठी हे योग्य आहे. मात्र दीर्घ agent task मध्ये याचा अर्थ असा होतो की तुमच्या task चा दुसरा अर्धा भाग तुम्ही निवडला नसलेल्या model वर चालला.

हे कुठेही स्पष्टपणे दिसत नाही. Task fail होत नाही, agent warning देत नाही आणि exit status success असतो. परिणामी plan एका model ने लिहिलेला असतो, तर edits दुसऱ्या model ने केलेले असतात. मध्येच tone आणि काम करण्याच्या पद्धती बदलतात. एकमेव विश्वासार्ह संकेत म्हणजे gateway च्या request log मधील किंवा response metadata मधील model field. त्यामुळे fallbacks वापरत असल्यास प्रत्येक request साठी ते field log करा. Result अनपेक्षित वाटल्यास ते तपासा. कोणत्या model ने result तयार केला हे माहीत नसताना behaviour debug करण्यात fallback मुळे वाचलेल्या वेळेपेक्षा जास्त वेळ खर्च होतो.

हीच समस्या context compression मध्येही उद्भवते. अनेक agents दीर्घ history चा सारांश तयार करण्यासाठी small model ला call करतात. त्या call मध्ये वेगळा model किंवा वेगळा system prompt असल्यास तो स्वतःची cache entry लिहितो आणि main session ची cache refresh करत नाही. त्यामुळे पुढील full turn ला cold prefix ची किंमत मोजावी लागते. Compression मुळे tokens वाचतात; पण cache गमावला जातो.

रूटिंगचा अतिरिक्त खर्च खरा आहे; पण अडचण latency मध्ये नाही

प्रत्येक विनंतीवर routers अतिरिक्त काम करतात. हे काम किती आहे, याबाबत अचूक असणे महत्त्वाचे आहे. DigitalOcean च्या अहवालानुसार, त्यांच्या Arch-Router model ला त्यांच्या स्वतःच्या मूल्यांकनात 93.17% routing accuracy सह routing intent ठरवण्यासाठी सुमारे 51 milliseconds लागतात. हे त्यांचे आकडे आहेत. ते त्यांच्या मोजमाप आणि benchmark वर आधारित आहेत. ते आमचे आकडे नाहीत आणि हा सार्वत्रिक परिणामही नाही. हे आकडे जसेच्या तसे स्वीकारले, तरी निष्कर्ष दिलासादायक आहे: चाळीस agent calls साठी 51 milliseconds म्हणजे काही minutes चालणाऱ्या task मध्ये सुमारे दोन seconds ची भर.

येथे routing महाग ठरण्याचे कारण दोन seconds नाही. प्रत्यक्ष अडचण निर्माण करणारा अतिरिक्त खर्च असा router आहे, जो पूर्ण model call वापरून classification करतो. त्यामुळे प्रत्येक विनंतीवर दुसरे inference चालते आणि ते इतर कोणत्याही inference प्रमाणे bill तसेच queue केले जाते. या दोन्हींच्या खाली वर दिलेले cache arithmetic आहे. तो अतिरिक्त खर्च नाही. Routing ने optimize करायच्या गोष्टीचीच ती किंमत आहे.

तुम्ही स्वतः चालवत असलेल्या server वर हेच तत्त्व लागू होते; मात्र बदल करण्यासाठीची मोकळीक कमी असते. Prompt cache चा स्थानिक पर्याय म्हणजे KV cache मधील prefix caching. हा cache GPU memory मध्ये राहतो. एका GPU वर दोन models host केल्यास ती memory दोघांमध्ये विभागली जाते. त्यामुळे प्रत्येक model कडे लहान KV cache राहतो आणि prefixes लवकर evict होतात. परिणामी, दोन local models मध्ये routing केल्याने दोन्ही models चा cache hit rate एकाच वेळी कमी होऊ शकतो. यासाठी hardware चे sizing करत असाल, तर router पेक्षा VPS वर coding agent ला प्रत्यक्षात लागणारी memory आणि CPU यापासून सुरुवात करणे अधिक उपयुक्त ठरेल.

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

• उपलब्धतेसाठी providers मध्ये routing करा. पर्याय म्हणून request अयशस्वी होणार असेल, तर कोणताही खर्च योग्य आहे. Fallback साठी समान tool call format असलेले model निश्चित करा, जेणेकरून agent चा loop कार्यरत राहील. प्रत्येक call कोणत्या model ने हाताळला हे log मध्ये नोंदवा.
• केवळ task boundaries वर खर्चासाठी tiers मध्ये routing करा. rename साठी Haiku आणि refactor साठी Opus निवडणे हा session सुरू होण्यापूर्वी एकदाच घेतलेला योग्य निर्णय आहे. त्याच session मधील turn thirty वर असा निर्णय घेणे अयोग्य आहे.
• Agent-संबंधित कामासाठी प्रत्येक session मध्ये एकच model निश्चित करा. Session चे मूल्य त्याच्या warm cache मध्ये असते. Model बदलण्याकडे cache clear करण्यासारखे पाहा, कारण प्रत्यक्षात तेच घडते.
• Subagents साठी routing मोकळेपणाने करा. Fresh आणि लहान 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 कडे निर्देशित करा. त्यानंतर ते model unreachable होईपर्यंत एकाच model वर राहते. दोन्ही entries एकाच provider वर असल्यामुळे fallback सक्रिय झाल्यावर tool call format बदलत नाही. त्या क्षणी tier बदल स्वीकारावा लागतो. पर्याय request अयशस्वी होणे असल्यामुळेच हा tradeoff स्वीकारण्यास योग्य ठरतो. कोणतेही cost routing जोडलेले नसलेले हे availability routing आहे. Coding agents साठी बहुतेक वेळा हेच संयोजन योग्य असते. Keys आणि budgets यांसह संपूर्ण रचना तुमच्या स्वतःच्या VPS वर self-hosted LiteLLM gateway चालवणे येथे दिली आहे. हा लेख ती माहिती जाणीवपूर्वक पुन्हा देत नाही.

एकदा योग्य निवडलेले एक मॉडेल कोणत्याही router पेक्षा चांगले ठरते

विनंतीच्या अवघडपणातील फरक हाताळण्यासाठी routing हा उपाय आहे. Coding agent मध्ये हा फरक दिसतो त्यापेक्षा कमी असतो, कारण प्रत्येक call चा महागडा भाग समान prefix असतो; call मध्ये काय मागितले आहे यावर त्याचा परिणाम होत नाही. Prefix चा वाटा प्रमुख ठरल्यानंतर तुमच्या स्वस्त tier आणि महागड्या tier मधील फरक त्यांच्या output prices मधील फरकापर्यंत कमी होतो. Agent च्या एकूण tokens मध्ये output चा वाटा लहान असतो.

म्हणून व्यवहार्य default म्हणजे एकच मॉडेल एकदा निवडणे, caching सुरू ठेवणे आणि पुरेसा मोठा TTL (time to live) ठेवणे. त्यामुळे diff वाचण्यासाठी तुम्ही थांबता त्या वेळेतील अंतरही cache मध्ये समाविष्ट होते. Anthropic base input च्या 2 times दराने one hour cache write देते. दोन reads नंतर त्याचा खर्च भरून निघतो. त्यामुळे अनेकदा कोणत्याही router पेक्षा हा अधिक प्रभावी उपाय ठरतो. Opus, Sonnet आणि Haiku यांची थेट तुलना करून tier जाणीवपूर्वक निवडा. तरीही bill ही समस्या असेल, तर mid-session switching करण्याऐवजी VPS वर AI agent चे खर्च नियंत्रित करणे यामध्ये सांगितल्याप्रमाणे budgets आणि लहान contexts वापरून खर्च कमी करा.

विनंत्या स्वतंत्र आणि लहान असतील किंवा subagents नव्या contexts ने सुरू होत असतील, तेव्हा route करा. एकाच कामासाठी एकच दीर्घ session चालू असेल, तेव्हा मॉडेल pin करा. Coding agent चे बहुतेक काम दुसऱ्या प्रकारात येते. त्यामुळे तुमच्या chat product वर पैसे वाचवणारा router येथे नकळत तुमचा खर्च वाढवू शकतो. तुम्ही अजून agent निवडलेला नसेल, तर Claude Code, Cursor, Codex आणि Copilot यांची तुलना प्रत्येक agent model selection कसे हाताळतो हे स्पष्ट करते. त्यांपैकी काही agent हा निर्णय तुमच्यासाठी घेतात.

FAQ

मध्येच model बदलल्यास prompt cache खरोखर नष्ट होतो का?

होय. Prompt cache हे prompt prefix च्या hash वर आधारित असतात आणि प्रत्येक model साठी स्वतंत्रपणे साठवले जातात. त्यामुळे दुसऱ्या model कडे पाठवलेल्या request चा hash अशा store विरुद्ध तयार होतो, ज्याने तो prefix यापूर्वी पाहिलेला नसतो. तेथे काहीही सापडत नाही आणि पूर्ण uncached input price द्यावी लागते. Caching enabled असल्यास त्यावर cache write चा खर्चही होतो. पुन्हा पहिल्या model कडे switch केल्याने मूळ 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 पट आहे. त्यामुळे Opus 5 वरील warm read ची किंमत Haiku 4.5 वरील uncached input rate पेक्षा कमी होते. Session मध्ये मोठा cached prefix तयार झाल्यावर input साठी सध्याचा model आधीच स्वस्त पर्याय असतो. Context fresh आणि लहान असताना routing फायदेशीर ठरते. हे task च्या सुरुवातीला किंवा फक्त आवश्यक context ठेवणाऱ्या subagent मध्ये लागू होते.

Task च्या मध्यावर माझा agent वेगळ्या प्रकारे का वागला?

Gateway fallback सक्रिय झाला का ते तपासा. Primary model वर rate limit किंवा 5xx आल्यास gateway standby model वर retry करते आणि काही seconds साठी primary ला cooldown मध्ये ठेवते. त्यामुळे task चा उर्वरित भाग दुसऱ्या model वर चालतो. यामुळे कोणतीही error किंवा warning दिसत नाही आणि task success दाखवतो. Gateway request log किंवा response metadata मधील model field हा याचा एकमेव विश्वसनीय record आहे. त्यामुळे fallbacks वापरत असल्यास प्रत्येक request साठी ते log करा.

प्रत्येक provider वर tool calls एकाच प्रकारे कार्य करतात का?

तंतोतंत नाही. Anthropic's Messages API मध्ये tool_use आणि tool_result content blocks वापरले जातात. OpenAI-compatible APIs मध्ये function.arguments हे JSON-encoded string असलेल्या tool_calls array चा वापर केला जातो. Gateway सामान्य प्रकरणांचे translation चांगल्या प्रकारे करते. मात्र parallel tool calls आणि strict schema enforcement प्रत्येक provider नुसार वेगवेगळे असतात. Self-hosted vLLM वर --enable-auto-tool-choice सेट करणे आवश्यक आहे. तसेच तुमच्या model family शी जुळणारे --tool-call-parser सेट करावे लागते. Strict schema constraint नसल्यास server raw text मधून tool calls काढतो, असे vLLM documentation मध्ये नमूद आहे. त्यामुळे arguments कधीकधी चुकीच्या format मध्ये असू शकतात.

Coding session साठी cache TTL किती ठेवावे?

सलग कामासाठी default five minute lifetime वापरा. दोन turns मधील diffs मानव वाचत असल्यास one hour पर्याय वापरा. Anthropic मध्ये five minute write ची किंमत base input च्या 1.25 पट आणि one hour write ची किंमत 2 पट आहे. Cache read ची किंमत 0.1 पट आहे. Five minute write ची भरपाई एका read मधून होते. One hour write ची भरपाई दोन reads मधून होते. त्यामुळे session पुन्हा सुरू करून काम पुढे चालू ठेवण्याची अपेक्षा असल्यास, cold prefix साठी पुन्हा पैसे देण्यापेक्षा longer lifetime सहसा स्वस्त पडते.