Coding agent-ல் multi-model routing செய்வதன் விளைவுகள்

Coding agent-ல் multi-model routing செய்யும் தாக்கம்

Multi-model routing, ஒவ்வொரு கோரிக்கையையும் (request) அதைக் கையாளக்கூடிய மலிவான மாதிரிக்கு (model) அனுப்புகிறது. Chat traffic-க்கு இது நன்றாகச் செயல்படுகிறது. ஆனால், ஒரு coding agent-ல் இது சேமிக்கும் தொகையை விட அதிக செலவை ஏற்படுத்துகிறது. ஏனெனில், ஒரு agent-ன் கட்டணத்தில் பெரும்பகுதி prompt prefix-ஆல் தீர்மானிக்கப்படுகிறது; இது ஒவ்வொரு மாதிரிக்கும் தனித்தனியாக cache செய்யப்படுகிறது. மாதிரிகளை மாற்றும்போது அந்த cache நீக்கப்பட்டுவிடுகிறது.

இந்தக் கட்டுரை முன்வைக்கும் விதி இதுதான்: கிடைக்கும் தன்மையை (availability) உறுதிப்படுத்த providers-க்கு இடையே routing செய்யுங்கள்; செலவைக் குறைக்க task எல்லைகளில் மட்டும் tiers-க்கு இடையே routing செய்யுங்கள்; agentic செயல்பாடுகளுக்கு ஒரு session-க்கு ஒரு மாதிரியை மட்டும் பயன்படுத்துங்கள். கீழே உள்ளவை இதற்கான காரணங்கள்.

நான்கு கலைச்சொற்கள், ஒருமுறை வரையறுக்கப்படுகின்றன. Router என்பது ஒவ்வொரு கோரிக்கைக்கும் ஒரு மாதிரியைத் தேர்வு செய்கிறது. Gateway என்பது கோரிக்கை கடந்து செல்லும் proxy ஆகும்; இது routing-ஐச் செய்யலாம் அல்லது செய்யாமலும் இருக்கலாம். Prompt cache என்பது உங்கள் prompt-ன் செயலாக்கப்பட்ட prefix-ஐ provider சேமித்து வைப்பதாகும்; இதனால் அதே prefix-ஐ மீண்டும் பயன்படுத்தும் அடுத்தடுத்த கோரிக்கைகளுக்கு, input விலையில் ஒரு சிறு பகுதி மட்டுமே கட்டணமாக வசூலிக்கப்படும். KV cache (key value cache) என்பது நீங்கள் சொந்தமாக இயக்கும் server-க்குள் இதே கருத்தைப் பயன்படுத்துவதாகும்.

Chat traffic ஏன் சரியாக routing செய்யப்படுகிறது, ஆனால் agent traffic ஏன் செய்யப்படுவதில்லை

ஒரு chat கோரிக்கை என்பது ஒரு முறை மட்டுமே நடக்கும் பரிமாற்றம். அது வருகிறது, வகைப்படுத்தப்படுகிறது, ஒரு model-க்கு செல்கிறது, பதிலளிக்கிறது. அடுத்த கோரிக்கைக்கு எதுவும் கொண்டு செல்லப்படுவதில்லை. ஒரு router இந்த கேள்வியை ஒரு சிறிய model-க்கும், அடுத்த கேள்வியை ஒரு பெரிய model-க்கும் அனுப்ப முடியும்; எந்தவொரு கோரிக்கைக்கும் மற்றொன்று நடந்தது தெரியாது. இதுவே பெரும்பாலான routing benchmark-கள் அளவிடும் பணிச்சுமை, இதில் சிறந்த router-கள் சிறப்பாகச் செயல்படுகின்றன.

ஒரு agent-ன் செயல்பாடு என்பது ஒரே ஒரு கோரிக்கை அல்ல. "தோல்வியுற்ற test-ஐ சரிசெய்" போன்ற ஒரு கட்டளை, இருபது முதல் அறுபது API அழைப்புகளாக மாறுகிறது. ஒவ்வொரு அழைப்பும் முழு உரையாடலையும் மீண்டும் அனுப்புகிறது: system prompt, ஒவ்வொரு tool definition, agent படித்த ஒவ்வொரு கோப்பு, அது பார்த்த ஒவ்வொரு command output என அனைத்தும் இதில் அடங்கும். context தொடர்ந்து வளர்ந்துகொண்டே இருக்கும். முப்பதாவது அழைப்பின் போது, மீண்டும் மீண்டும் வரும் prefix பல்லாயிரக்கணக்கான tokens-ஆக இருக்கலாம், ஆனால் ஒவ்வொரு அழைப்பிலும் புதிதாக வரும் உள்ளடக்கம் சில நூறு tokens மட்டுமே.

இந்த வடிவம் "expensive" (செலவுமிக்கது) என்ற சொல்லின் அர்த்தத்தையே மாற்றுகிறது. Chat-ல், செலவு என்பது தோராயமாக model-ன் விலை பெருக்கல் கோரிக்கைகளின் எண்ணிக்கை. ஒரு agent loop-ல், செலவு என்பது ஒவ்வொரு அழைப்பிலும் மீண்டும் வசூலிக்கப்படும் prefix-ன் கட்டணம். இந்த பதிவின் மீதமுள்ள பகுதிகள் இந்த ஒரு உண்மையை அடிப்படையாகக் கொண்டவை.

Prompt cache ஒவ்வொரு model-க்கும் தனிப்பட்டது, agent அதற்குள்ளேயே இயங்குகிறது

Anthropic, cache read-க்கு அடிப்படை input விலையில் 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-ன் விலை மில்லியன் tokens-க்கு 0.50 டாலர்கள். பட்டியலில் உள்ள மலிவான model-ஆன Haiku 4.5-ல், uncached input-ன் விலை 1.00 டாலர்கள். எனவே, மிகவும் விலையுயர்ந்த model-ல் ஏற்கனவே உள்ள (warm) prefix-ஐ மீண்டும் படிப்பது, மலிவான model-ல் அதே prefix-ஐ புதிதாக (cold) படிப்பதை விடக் குறைவான செலவே ஆகும்.

இந்த ஒரு ஒப்பீடு பெரும்பாலான routing திட்டங்களை மாற்றியமைக்கிறது. ஒரு router வேலையை ஒரு அடுக்கு "கீழே" நகர்த்தும்போது, அது பட்டியல் விலைகளை மட்டுமே ஒப்பிடுகிறது. ஆனால், ஒரு session-ன் பாதியில் இருக்கும் agent, தான் ஏற்கனவே பயன்படுத்தும் model-க்கு பட்டியல் விலையைச் செலுத்துவதில்லை. அது cache read விலையைச் செலுத்துகிறது, இது மலிவான model-ன் uncached விலையை விடக் குறைவு.

Caches, prompt prefix-ன் hash மதிப்பை அடிப்படையாகக் கொண்டவை மற்றும் அவை ஒவ்வொரு model-க்கும் தனித்தனியானவை. வேறொரு model-க்கு அனுப்பப்படும் கோரிக்கை, இதுவரை அந்த hash-ஐப் பார்த்திராத ஒரு store-ஐ அணுகும்; எனவே அங்கு எதுவும் கிடைக்காது மற்றும் முழு விலையும் வசூலிக்கப்படும். Cache ஒரு படிநிலை அமைப்பைக் கொண்டது: முதலில் tools, பிறகு system, அதன் பிறகு messages. ஏதேனும் ஒரு நிலையில் மாற்றம் ஏற்பட்டால், அந்த நிலையும் அதற்குப் பின் வரும் அனைத்தும் செல்லாததாகிவிடும். அதாவது, ஒரு tool definition-ஐ மாற்றினால், அதற்குப் பின்னால் இருக்கும் system prompt cache நீக்கப்படும். Runtime-ல் tools-ஐப் பதிவு செய்யும் agents, router-ஐத் தொடாமலேயே இந்தச் சிக்கலைச் சந்திக்கின்றன.

ஒரு mid-session மாற்றத்தின் உண்மையான செலவு

ஒரு agent சில கோப்புகளைப் படித்த பிறகு, 40,000 tokens கொண்ட நிலையான prefix-ஐக் கொண்ட ஒரு session-ஐக் கருத்தில் கொள்வோம். கீழே உள்ள பட்டியலில் கொடுக்கப்பட்டுள்ள விலைகளின் அடிப்படையில், ஒரு 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"
  }
]

Opus 5-ல் warm cache-உடன் தொடர்ந்து இருப்பது, அந்த turn-ன் prefix-க்கு 0.020 டாலர் செலவாகும். Sonnet 5-க்கு மாறிய பிறகு வரும் முதல் turn-க்கு 0.100 டாலர் செலவாகும், ஏனெனில் Sonnet-ல் இந்த prefix-க்கான entry இல்லை, அதை அது புதிதாக எழுத வேண்டும். மீண்டும் Opus 5-க்குத் திரும்பும்போது 0.250 டாலர் செலவாகும், ஏனெனில் session வெளியே இருந்த நேரத்தில் அசல் entry காலாவதியாகிவிடும்.

எனவே, இரண்டு cache reads-ஐத் தவிர்க்க, இந்த round trip-ல் இரண்டு cache writes செய்ய வேண்டியுள்ளது. இதற்குப் பதிலாக, இந்த மாற்றத்தின் மூலம் Sonnet-ன் output விலையில் ஒரு turn output கிடைக்கிறது. விவரங்கள் அடங்கிய தொகுப்பு முழுப் பயணத்தையும் விளக்குகிறது: சேமிப்பு ஒரு cent-ன் பின்னங்களாக உள்ளது, ஆனால் cache அபராதம் (penalty) பத்து cent-களாக உள்ளது. இந்த அபராதம் பத்து மடங்குக்கும் மேலாக அதிகமாக உள்ளது, மேலும் 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

வெவ்வேறு providers-ல் tool call வடிவங்கள் ஒன்றாக இருப்பதில்லை

ஒரு agent என்பது tool-களை அழைக்கும் ஒரு loop ஆகும், எனவே chat-ல் இல்லாத அளவிற்கு இதில் tool call வடிவம் முக்கியத்துவம் பெறுகிறது. Anthropic-ன் Messages API ஒரு tool_use content block-ஐத் திருப்பித் தருகிறது, மேலும் அதற்குப் பதிலாக ஒரு tool_result block-ஐ எதிர்பார்க்கிறது. OpenAI-இணக்கமான (OpenAI-compatible) API-கள் ஒரு tool_calls array-ஐத் திருப்பித் தருகின்றன; இதில் function.arguments என்பது nested object-ஆக இல்லாமல், JSON-encoded string-ஆக இருக்கும். ஒரு gateway இவ்விரண்டிற்கும் இடையே மொழிபெயர்ப்பு செய்கிறது, சாதாரண அழைப்புகளுக்கு இந்த மொழிபெயர்ப்பு சரியாக அமையும்.

விளிம்பு நிலைகளில் (edges) சிக்கல்கள் தோன்றுகின்றன. ஒரு model ஒரே பதிலில் பல அழைப்புகளை வெளியிடும் Parallel tool calls, எல்லா இடங்களிலும் ஒரே மாதிரியாகக் குறிப்பிடப்படுவதில்லை மற்றும் ஆதரிக்கப்படுவதில்லை. Strict schema enforcement என்பது ஒவ்வொரு provider-க்கும் உரிய தனிப்பட்ட வசதியாகும். எனவே, ஒரு endpoint-ல் schema-valid arguments-ஐ உறுதி செய்யும் model, மற்றொரு endpoint-ல் அவ்வாறு செயல்படாது. இந்த வேறுபாட்டை agent ஒரு parse error கொண்ட tool result-ஆகக் கருதுகிறது, அதைச் சரிசெய்ய அது மற்றொரு turn-ஐப் பயன்படுத்துகிறது. அந்த repair turns-களுக்கு முழு prefix விலையும் வசூலிக்கப்படுகிறது, எனவே format பொருந்தாமை என்பது 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 ஆவணங்கள் இந்த வழிமுறையின் வரம்புகளைத் தெளிவாகக் கூறுகின்றன: tool_choice="auto" மற்றும் strict schema constraint இல்லாத நிலையில், vLLM raw text-லிருந்து tool call-களைப் பிரித்தெடுக்கிறது. இதனால் arguments சில நேரங்களில் தவறாக இருக்கலாம் அல்லது function-ன் parameter schema-வை மீறலாம். உங்கள் model-க்குத் தவறான parser-ஐத் தேர்ந்தெடுப்பது ஒரு configuration பிழையாகும்; இது tool-களை அழைக்க முடியாத agent-ஆக வெளிப்படும். இதற்கு traffic-ஐ அனுப்பும் முன், Ollama மற்றும் vLLM மூலம் model-களை நீங்களே இயக்குவதற்கு இடையிலான வேறுபாடு பற்றித் தெரிந்துகொள்வது அவசியம், ஏனெனில் இவை இரண்டும் வெவ்வேறு நிபந்தனைகளின் கீழ் tool calling-ஐ வழங்குகின்றன.

இடைக்கால fallback மாற்றங்கள் பிழையின்றி நடத்தையை மாற்றுகின்றன

Fallback routing என்பது தற்செயலாகச் செயல்படுத்தப்படக்கூடிய ஒரு அம்சமாகும். முதல் மாதிரி (model) rate limit அல்லது 5xx பிழையைத் தரும்போது, மற்றொரு மாதிரியில் மீண்டும் முயற்சி செய்யுமாறு gateway கட்டமைக்கப்படுகிறது; பின்னர் தோல்வியுற்ற மாதிரியைச் சில நொடிகள் cooldown நிலையில் வைக்கிறது. Chat traffic-க்கு இது சரியான அணுகுமுறை. ஆனால், நீண்ட agent task-ன் நடுவில் இது நடந்தால், உங்கள் பணியின் இரண்டாம் பாதி நீங்கள் தேர்ந்தெடுக்காத ஒரு மாதிரியால் இயக்கப்படும்.

இதை எங்கும் பதிவு செய்வதில்லை. பணி தோல்வியடைவதில்லை, agent எச்சரிக்கை தருவதில்லை, exit status வெற்றிகரமாகவே இருக்கும். இதன் விளைவாக, ஒரு மாதிரியால் திட்டமிடப்பட்டு, மற்றொரு மாதிரியால் திருத்தப்பட்ட ஒரு பணி கிடைக்கிறது; இதில் பாதியிலேயே தொனியும் (tone) செயல்பாட்டு முறைகளும் மாறிவிடுகின்றன. gateway-ன் request log அல்லது response metadata-வில் உள்ள model புலம் மட்டுமே இதற்கான நம்பகமான சான்றாகும். எனவே, நீங்கள் fallback-களைப் பயன்படுத்தினால், ஒவ்வொரு கோரிக்கையிலும் அந்தப் புலத்தைப் பதிவு செய்து, முடிவுகள் எதிர்பாராதவிதமாக இருக்கும்போது அதைச் சரிபார்க்கவும். எந்த மாதிரி முடிவை உருவாக்கியது என்று தெரியாமல் நடத்தையை debug செய்வது, fallback மூலம் மிச்சப்படுத்திய நேரத்தை விட அதிக நேரத்தை வீணாக்கும்.

Context compression-லும் இதே சிக்கல் ஏற்படுகிறது. பல agent-கள் நீண்ட வரலாற்றைச் சுருக்க ஒரு சிறிய மாதிரியைப் பயன்படுத்துகின்றன. அந்த அழைப்பு வேறு ஒரு மாதிரியையோ அல்லது வேறு ஒரு system prompt-ஐயோ பயன்படுத்தினால், அது தனது சொந்த cache entry-ஐ உருவாக்கும்; முதன்மை session-ன் cache-ஐ அது புதுப்பிக்காது. இதனால், அடுத்த முழுச் சுழற்சியின்போது (full turn) cold prefix-க்கான கட்டணத்தைச் செலுத்த வேண்டியிருக்கும். சுருக்கம் மூலம் tokens மிச்சப்படுத்தப்பட்டாலும், cache இழக்கப்படுகிறது.

Routing overhead என்பது உண்மைதான், ஆனால் latency-ஆல் பெரிய பாதிப்பு இல்லை

ஒவ்வொரு கோரிக்கைக்கும் (request) routers கூடுதல் வேலைப்பளுவைச் சேர்க்கின்றன, அது எவ்வளவு என்பதைத் துல்லியமாக அறிவது அவசியம். DigitalOcean-ன் Arch-Router மாதிரி, 93.17% துல்லியத்துடன் சுமார் 51 milliseconds-ல் routing நோக்கத்தைத் தீர்மானிப்பதாக அவர்கள் தெரிவிக்கின்றனர். இவை அவர்களது அளவீடுகள் மற்றும் benchmark-ல் இருந்து பெறப்பட்டவை; இவை பொதுவான முடிவுகள் அல்ல. இவற்றை அப்படியே எடுத்துக்கொண்டால், முடிவு நம்பிக்கையளிப்பதாகவே உள்ளது: நாற்பது agent அழைப்புகளுக்கு 51 milliseconds என்பது, பல நிமிடங்கள் ஓடும் ஒரு பணிக்குக் கூடுதலாகச் சேர்க்கப்படும் சுமார் இரண்டு வினாடிகள் மட்டுமே.

இங்கே routing-ஐ விலை உயர்ந்ததாக மாற்றுவது அந்த இரண்டு வினாடிகள் அல்ல. பாதிப்பை ஏற்படுத்தும் overhead என்பது, முழுமையான model அழைப்பின் மூலம் வகைப்படுத்தும் router ஆகும். ஏனெனில், இது ஒவ்வொரு கோரிக்கையிலும் இரண்டாவது inference-ஐ உருவாக்குகிறது; இது மற்றவற்றைப் போலவே கட்டணத்திற்கும் வரிசைக்கும் (queue) உட்பட்டது. இவை இரண்டிற்கும் அடியில் மேலே குறிப்பிட்ட cache கணக்கீடு உள்ளது, இது overhead கிடையாது. இது routing எதை மேம்படுத்த வேண்டுமோ, அதன் செலவாகும்.

நீங்கள் சொந்தமாக இயக்கும் server-ல், இதே விதி குறைவான இடவசதியுடன் பொருந்தும். Prompt cache-ன் உள்ளூர் இணையானது KV cache-ல் உள்ள prefix caching ஆகும், இது GPU memory-ல் இருக்கும். ஒரே GPU-வில் இரண்டு models-ஐ host செய்வது அந்த memory-ஐ இரண்டாகப் பிரிக்கும்; எனவே ஒவ்வொன்றும் சிறிய KV cache-ஐயே வைத்திருக்கும் மற்றும் prefix-களை விரைவாக நீக்கும் (evict). எனவே, இரண்டு உள்ளூர் models-க்கு இடையே routing செய்வது, இரண்டின் cache hit rate-ஐயும் ஒரே நேரத்தில் குறைக்கலாம். இதற்காக நீங்கள் hardware-ஐத் தேர்வு செய்கிறீர்கள் என்றால், ஒரு coding agent-க்கு VPS-ல் தேவைப்படும் memory மற்றும் CPU என்பது router-ஐ விடத் தொடங்குவதற்கு மிகவும் பயனுள்ள இடமாகும்.

முடிவெடுக்கும் விதி

• கிடைக்கும் தன்மையை உறுதிப்படுத்த பல்வேறு providers இடையே route செய்யவும். ஒரு கோரிக்கை தோல்வியடைவதே மாற்று என்றால், எந்தவொரு செலவும் சரியானதே. முகவரின் (agent) loop தொடர்ந்து இயங்குவதற்கு, அதே tool call format-ஐக் கொண்ட ஒரு model-க்கு fallback-ஐ இணைக்கவும். எந்த model ஒவ்வொரு கோரிக்கையையும் நிறைவேற்றியது என்பதை log செய்யவும்.
• பணி எல்லைகளில் (task boundaries) மட்டும் செலவைக் குறைக்க tiers இடையே route செய்யவும். ஒரு கோப்பை மறுபெயரிட Haiku-வையும், refactor செய்ய Opus-வையும் தேர்ந்தெடுப்பது, session தொடங்குவதற்கு முன் எடுக்கப்படும் ஒரு சரியான முடிவாகும். அதே முடிவை session-ன் முப்பதாவது சுற்றில் எடுப்பது தவறானது.
• Agentic பணிகளுக்கு ஒரு session-க்கு ஒரு model-ஐ மட்டும் பயன்படுத்தவும். ஒரு session-ன் மதிப்பு அதன் warm cache-ல் உள்ளது. model-களை மாற்றுவதை cache-ஐ அழிப்பதற்கு சமமாகக் கருதவும், ஏனெனில் அதுதான் நடக்கும்.
• Subagents-ஐ தாராளமாக route செய்யவும். புதிய மற்றும் சிறிய context-உடன் தொடங்கும் ஒரு subagent-க்கு இழப்பதற்கு warm cache எதுவும் இல்லை. எனவே, அதன் பணிக்கு ஏற்ற எந்த model-லும் அதை இயக்கலாம். ஒரு agent-க்குள் routing-ஐ எந்தவித பாதிப்பும் இன்றி செய்யக்கூடிய ஒரே இடம் இதுதான்.

இதை எவ்வாறு உருவாக்குவது என்பதற்கு, gateway-ன் செயல்பாடே அடிப்படையாகும்: model aliases மற்றும் தெளிவான fallback பட்டியல்கள். ஒரு குறைந்தபட்ச 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 அணுக முடியாத நிலை ஏற்படும் வரை அது அதிலேயே இருக்கும். இரண்டு உள்ளீடுகளும் ஒரே provider-ல் இருப்பதால், fallback செயல்படும்போது tool call format மாறாது. அந்தத் தருணத்தில் tier மாற்றத்தை நீங்கள் ஏற்றுக்கொள்கிறீர்கள்; கோரிக்கை தோல்வியடைவதைத் தவிர்ப்பதற்காக மட்டுமே இந்தச் சமரசம் செய்யப்படுகிறது. இது செலவு சார்ந்த routing இல்லாமல், கிடைக்கும் தன்மையை (availability) உறுதிப்படுத்தும் routing ஆகும். பெரும்பாலான coding agents விரும்புவது இந்த அமைப்பைத்தான். Keys மற்றும் budgets உள்ளிட்ட முழுமையான கட்டமைப்பு, உங்கள் சொந்த VPS-ல் LiteLLM gateway-ஐ இயக்குதல் என்ற பகுதியில் விவரிக்கப்பட்டுள்ளது. எனவே, இந்தப் பதிவில் அது மீண்டும் விளக்கப்படவில்லை.

ஒரு சிறந்த model எந்த router-ஐயும் விடச் சிறப்பாகச் செயல்படும்போது

கோரிக்கைகளின் கடினத்தன்மையில் உள்ள மாறுபாட்டிற்கு routing ஒரு தீர்வாகும். ஒரு coding agent-க்குத் தோன்றுவதை விட மாறுபாடு குறைவாகவே உள்ளது, ஏனெனில் ஒவ்வொரு அழைப்பிலும் அதிக செலவாகும் பகுதி அதன் prefix தான், அது எதைக் கேட்கிறது என்பது முக்கியமல்ல. ஒருமுறை prefix ஆதிக்கம் செலுத்திவிட்டால், உங்கள் மலிவான tier மற்றும் விலையுயர்ந்த tier-க்கு இடையிலான வித்தியாசம் அவற்றின் output விலையை நோக்கிச் சுருங்கிவிடும், மேலும் ஒரு agent-ன் tokens-ல் output என்பது சிறிய பங்கையே கொண்டுள்ளது.

எனவே, நேர்மையான இயல்புநிலை (default) என்பது ஒரு model-ஐத் தேர்ந்தெடுத்து, caching-ஐ ஆன் செய்து, நீங்கள் ஒரு diff-ஐப் படிக்க இடைநிறுத்தம் செய்யும்போது ஏற்படும் இடைவெளிகளை ஈடுகட்ட போதுமான TTL (time to live) காலத்தை அமைப்பதாகும். Anthropic ஒரு மணிநேர cache write-ஐ அடிப்படை input-ஐ விட 2 மடங்கு விலையில் வழங்குகிறது, இது இரண்டு முறை வாசித்தாலே அதன் செலவை ஈடுகட்டிவிடும், இது எந்த router-ஐ விடவும் சிறந்த வழியாகும். Opus, Sonnet மற்றும் Haiku ஆகியவற்றின் நேரடி ஒப்பீட்டைப் பயன்படுத்தி கவனமாக ஒரு tier-ஐத் தேர்ந்தெடுக்கவும். ஒருவேளை கட்டணம் இன்னும் சிக்கலாக இருந்தால், session-க்கு இடையில் switching செய்வதற்குப் பதிலாக, VPS-ல் AI agent செலவுகளைக் கட்டுப்படுத்துதல் என்பதில் உள்ளபடி budgets மற்றும் சிறிய contexts மூலம் அதைக் குறைக்கவும்.

கோரிக்கைகள் தனித்தனியாகவும் குறுகியதாகவும் இருக்கும்போது அல்லது subagents புதிய contexts-உடன் தொடங்கும்போது routing செய்யவும். ஒரு நீண்ட session ஒரே வேலையைச் செய்யும்போது model-ஐ pin செய்யவும். பெரும்பாலான coding agent வேலைகள் இரண்டாவது வகையைச் சேர்ந்தவை, அதனால்தான் உங்கள் chat product-ல் பணத்தைச் சேமிக்கும் router, இங்கே உங்களுக்கு மறைமுகமாகச் செலவை ஏற்படுத்தும். நீங்கள் இன்னும் agent-ஐத் தீர்மானிக்கவில்லை என்றால், Claude Code, Cursor, Codex மற்றும் Copilot ஆகியவற்றின் ஒப்பீடு ஒவ்வொன்றும் model தேர்வை எவ்வாறு கையாள்கிறது என்பதை விளக்குகிறது, அவற்றில் சில இந்த முடிவை உங்களுக்காகவே எடுத்துக்கொள்கின்றன.

FAQ

ஒரு session-க்கு இடையில் மாடல்களை மாற்றினால் prompt cache இழக்கப்படுமா?

ஆம். Prompt caches என்பவை prompt prefix-ன் hash மதிப்பை அடிப்படையாகக் கொண்டவை மற்றும் ஒவ்வொரு மாடலுக்கும் தனித்தனியாகச் சேமிக்கப்படுபவை. எனவே, வேறொரு மாடலுக்கு அனுப்பப்படும் கோரிக்கை, அந்த prefix-ஐ இதுவரை பார்த்திராத ஒரு சேமிப்பகத்தில் hash செய்யப்படுகிறது. அங்கு எதையும் கண்டறிய முடியாததால், முழுமையான uncached input கட்டணமும், caching வசதி இயக்கப்பட்டிருந்தால் அதற்கான cache write கட்டணமும் வசூலிக்கப்படும். மீண்டும் பழைய மாடலுக்கு மாறினாலும் அசல் தரவு கிடைக்காது, ஏனெனில் அதற்குள் இயல்பான ஐந்து நிமிட காலாவதி நேரம் முடிந்திருக்கும். பதில் பயன்பாட்டு பொருளில் (response usage object) உள்ள cache_read_input_tokens மற்றும் cache_creation_input_tokens புலங்களைச் சரிபார்க்கவும்: நீண்ட session-ல் cached tokens எதையும் படிக்காத ஒரு turn, இதற்கான அறிகுறியாகும்.

ஒரு agent-க்கு மலிவான மாடலுக்கு routing செய்வது எப்போதுமே சிக்கனமானதா?

இழப்பதற்கு warm cache இல்லாதபோது மட்டுமே இது சிக்கனமானது. Anthropic-ல் ஒரு cache read என்பது அடிப்படை input கட்டணத்தில் 0.1 மடங்கு மட்டுமே. இது Opus 5-ல் உள்ள warm read-ஐ, Haiku 4.5-ன் uncached input கட்டணத்தை விடக் குறைவாக மாற்றுகிறது. ஒரு session-ல் பெரிய cached prefix இருக்கும்போது, ஏற்கனவே உள்ள மாடலே input-க்கு மலிவான தேர்வாகிவிடுகிறது. context புதியதாகவும் சிறியதாகவும் இருக்கும்போது மட்டுமே routing பயன் தரும்: ஒரு பணியின் தொடக்கத்தில் அல்லது தனக்குத் தேவையான context-ஐ மட்டும் கொண்டுள்ள subagent-ல் இது பொருந்தும்.

ஒரு பணியின் பாதியில் எனது agent ஏன் வித்தியாசமாகச் செயல்பட்டது?

Gateway fallback நிகழ்ந்ததா என்று சரிபார்க்கவும். முதன்மை மாடலில் rate limit அல்லது 5xx பிழை ஏற்பட்டால், gateway தானாகவே standby மாடலுக்கு மாறி, முதன்மை மாடலைச் சில நொடிகள் cooldown-ல் வைக்கும். இதனால் பணியின் மீதிப் பகுதி வேறொரு இடத்தில் இயங்கும். இது எந்தப் பிழையையும் எச்சரிக்கையையும் காட்டாது, பணி வெற்றிகரமாக முடிந்ததாகவே காட்டும். Gateway கோரிக்கை log அல்லது பதில் metadata-வில் உள்ள model புலம் மட்டுமே இதற்கான நம்பகமான ஆதாரமாகும். எனவே, நீங்கள் fallback-களைப் பயன்படுத்தினால், ஒவ்வொரு கோரிக்கைக்கும் இதை log செய்யவும்.

அனைத்து provider-களிலும் tool calls ஒரே மாதிரியாகச் செயல்படுமா?

துல்லியமாகச் சொல்ல முடியாது. Anthropic-ன் Messages API tool_use மற்றும் tool_result content blocks-ஐப் பயன்படுத்துகிறது. அதேசமயம் OpenAI-இணக்கமான API-கள் tool_calls array-ஐப் பயன்படுத்துகின்றன, இதில் function.arguments என்பது JSON-encoded string ஆகும். ஒரு gateway பொதுவான நிகழ்வுகளைச் சரியாக மொழிபெயர்க்கும், ஆனால் parallel tool calls மற்றும் கடுமையான schema அமலாக்கம் ஆகியவை ஒவ்வொரு provider-க்கும் மாறுபடும். Self-hosted vLLM-ல் நீங்கள் --enable-auto-tool-choice மற்றும் உங்கள் மாடல் குடும்பத்திற்குப் பொருத்தமான --tool-call-parser-ஐ அமைக்க வேண்டும். கடுமையான schema கட்டுப்பாடு இல்லையெனில், server raw text-லிருந்து tool calls-ஐப் பிரித்தெடுக்கும் என்றும், இதனால் சில நேரங்களில் arguments தவறான வடிவத்தில் இருக்கலாம் என்றும் vLLM ஆவணங்கள் குறிப்பிடுகின்றன.

Coding session-க்கு cache TTL-ஐ எவ்வளவு நேரம் அமைக்க வேண்டும்?

தொடர்ச்சியான வேலைகளுக்கு இயல்பான ஐந்து நிமிட காலாவதி நேரத்தைப் பயன்படுத்தவும். மனிதர்கள் turn-களுக்கு இடையே diff-களைப் படிக்கும்போது ஒரு மணிநேர விருப்பத்தைப் பயன்படுத்தவும். Anthropic ஐந்து நிமிட write-க்கு அடிப்படை input-ஐப் போல 1.25 மடங்கும், ஒரு மணிநேர write-க்கு 2 மடங்கும் கட்டணம் வசூலிக்கிறது; read-க்கு 0.1 மடங்கு மட்டுமே. ஐந்து நிமிட write கட்டணம் ஒரு முறை read செய்வதிலேயே ஈடுசெய்யப்பட்டுவிடும், ஒரு மணிநேர write கட்டணம் இரண்டு முறை read செய்வதில் ஈடுசெய்யப்படும். எனவே, நீங்கள் மீண்டும் வந்து பணியைத் தொடர வாய்ப்புள்ள எந்தவொரு session-லும், நீண்ட காலாவதி நேரமே cold prefix-க்கான கட்டணத்தை விடக் குறைவான செலவைத் தரும்.