Coding agents کے لیے multi-model routing یا ایک model؟

کوڈنگ ایجنٹ کے لیے متعدد ماڈلز کی routing کے اثرات

متعدد ماڈلز کی routing ہر request کو ایسے کم ترین لاگت والے model کو بھیجتی ہے جو اسے سنبھال سکتا ہو۔ chat traffic پر یہ طریقہ اچھی طرح کام کرتا ہے۔ coding agent میں عموماً اس سے بچت کے مقابلے میں لاگت زیادہ ہو جاتی ہے، کیونکہ agent کا bill زیادہ تر اس prompt prefix سے بنتا ہے جو ہر model کے لیے cache ہوتا ہے، اور model تبدیل کرنے سے یہ cache ضائع ہو جاتا ہے۔

اس تحریر میں پیش کیا گیا اصول یہ ہے: availability کے لیے providers کے درمیان route کریں، cost کے لیے tiers کے درمیان صرف task boundaries پر route کریں، اور agentic کام میں ہر session کے لیے ایک ہی model مقرر رکھیں۔ ذیل میں اس کی وجہ بیان کی گئی ہے۔

چار اصطلاحات، ایک مرتبہ متعین۔ router ہر request کے لیے ایک model منتخب کرتا ہے۔ gateway وہ proxy ہے جس سے request گزرتی ہے؛ یہ خود route بھی کر سکتی ہے یا نہیں بھی۔ prompt cache اس provider کی جانب سے آپ کے prompt کے process شدہ prefix کو محفوظ کرنا ہے، تاکہ بعد کی وہ request جس میں یہی prefix دوبارہ شامل ہو، input price کے صرف ایک حصے پر bill ہو۔ KV cache (key value cache) اسی تصور کی وہ صورت ہے جو آپ خود چلانے والے server کے اندر استعمال کرتے ہیں۔

چیٹ ٹریفک اچھی طرح route کیوں ہوتی ہے، جبکہ agent ٹریفک نہیں ہوتی

چیٹ کی درخواست ایک turn ہوتی ہے۔ یہ آتی ہے، classify ہوتی ہے، model تک جاتی ہے، اور جواب واپس آ جاتا ہے۔ اگلی درخواست کے لیے کچھ بھی باقی نہیں رہتا۔ Router یہ سوال ایک چھوٹے model کو اور اگلا سوال ایک بڑے model کو بھیج سکتا ہے، اور دونوں درخواستوں کو ایک دوسرے کے بارے میں علم نہیں ہوتا۔ تقریباً ہر routing benchmark اسی workload کی پیمائش کرتا ہے، اور اچھے routers واقعی اس کام میں مؤثر ہوتے ہیں۔

Agent کا turn ایک درخواست نہیں ہوتا۔ "failing test کو ٹھیک کریں" جیسی ایک instruction سے 20 سے 60 API calls بن سکتی ہیں۔ ہر call میں پوری conversation دوبارہ بھیجی جاتی ہے: system prompt، ہر tool definition، agent کی پڑھی ہوئی ہر file، اور اس کے دیکھے ہوئے ہر command output سمیت۔ Context مسلسل بڑھتا رہتا ہے۔ 30ویں call تک repeated prefix دسیوں ہزار tokens پر مشتمل ہو سکتا ہے، جبکہ ہر call میں واقعی نیا content چند سو tokens کا ہوتا ہے۔

اس ساخت سے "expensive" کا مطلب بدل جاتا ہے۔ چیٹ میں لاگت تقریباً model کی قیمت کو request سے ضرب دینے کے برابر ہوتی ہے۔ Agent loop میں prefix کی لاگت ہر call پر دوبارہ وصول ہوتی ہے۔ اس پوری تحریر کی باقی بحث اسی ایک حقیقت سے نکلتی ہے۔

Prompt cache ہر model کے لیے الگ ہوتا ہے، اور agent اسی cache کے اندر رہتا ہے

Anthropic، cache read کے لیے بنیادی input price کا 0.1 گنا، اور پانچ منٹ کے cache write کے لیے 1.25 گنا قیمت لیتا ہے۔ یہ شائع شدہ فہرستی قیمتیں ہیں، August 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"
  }
]

دوسری series کو پہلی series کے مقابل، rows کے لحاظ سے پڑھیں، columns کے لحاظ سے نہیں۔ Opus 5 پر cache read کی قیمت فی million tokens 0.50 dollars ہے۔ درج فہرست models میں سب سے سستے model، Haiku 4.5، پر uncached input کی قیمت 1.00 dollars ہے۔ اس لیے سب سے مہنگے model پر warm prefix کو دوبارہ پڑھنے کی فی input token قیمت، سب سے سستے model پر اسی prefix کو پہلی بار پڑھنے کی قیمت سے بھی کم ہے۔

یہ ایک موازنہ routing کے زیادہ تر منصوبوں کو ناکام بنا دیتا ہے۔ جو router کام کو کسی tier میں "نیچے" منتقل کرتا ہے، وہ فہرستی قیمتوں کا موازنہ کر رہا ہوتا ہے۔ لیکن session کے دوران agent پہلے سے استعمال کیے جانے والے model پر فہرستی قیمت ادا نہیں کر رہا ہوتا۔ وہ cache read کی قیمت ادا کرتا ہے، جو پہلے ہی سستے model کی uncached rate سے کم ہوتی ہے۔

Caches، prompt prefix کے hash کی بنیاد پر keyed ہوتے ہیں، اور ہر model کے لیے الگ ہوتے ہیں۔ کسی مختلف model کو بھیجی گئی request ایسے store کے خلاف hash ہوتی ہے جس نے اسے پہلے کبھی نہیں دیکھا، اس لیے اسے کچھ نہیں ملتا اور مکمل قیمت ادا کرنا پڑتی ہے۔ Cache ایک hierarchy بھی ہے: پہلے tools، پھر system، پھر messages۔ کسی بھی level میں تبدیلی اس level اور اس کے بعد آنے والے تمام levels کو invalid کر دیتی ہے۔ اس کا مطلب ہے کہ ایک tool definition میں ترمیم کرنے سے اس کے بعد موجود system prompt cache ضائع ہو جاتا ہے۔ جو agents runtime پر tools register کرتے ہیں، وہ router کو چھوئے بغیر ہی اس مسئلے سے دوچار ہوتے ہیں۔

درمیانی سیشن میں ایک بار ماڈل تبدیل کرنے کی اصل لاگت

فرض کریں کہ کسی سیشن میں 40,000 tokens کا مستحکم prefix موجود ہے۔ ایجنٹ کے چند 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 پر route کرنے کے بعد پہلے turn کی لاگت 0.100 dollars ہے، کیونکہ Sonnet کے پاس اس prefix کا کوئی entry نہیں ہے اور اسے ایک entry لکھنی پڑتی ہے۔ Opus 5 پر واپس آنے کی لاگت 0.250 dollars ہے، کیونکہ session کے دور رہنے کے دوران اصل entry expire ہو گئی۔

اس طرح واپس آنے جانے کے عمل میں دو cache reads سے بچنے کے لیے دو cache writes کی ادائیگی ہوتی ہے۔ اس کے مقابلے میں switch سے ایک turn کا output Opus کی بجائے Sonnet کی output price پر حاصل ہوتا ہے۔ details block میں پورا حساب موجود ہے: saving cent کے ایک حصے تک محدود رہتی ہے، جبکہ cache penalty دسیوں cents تک پہنچتی ہے۔ penalty ایک order of magnitude سے بھی زیادہ بڑی ہے۔ prefix کی length بڑھنے کے ساتھ 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

مختلف providers میں tool call formats یکساں نہیں ہوتے

Agent ایک tool-calling loop ہوتا ہے، اس لیے tool call format کی اہمیت chat کے مقابلے میں کہیں زیادہ ہوتی ہے۔ Anthropic کی Messages API ایک tool_use content block واپس کرتی ہے اور جواب میں tool_result block کی توقع رکھتی ہے۔ OpenAI-compatible APIs ایک tool_calls array واپس کرتی ہیں، جس میں function.arguments nested object کے بجائے JSON-encoded string ہوتا ہے۔ Gateway دونوں formats کے درمیان translation کرتا ہے، اور عام calls کے لیے یہ translation درست رہتی ہے۔

مسائل edge cases میں سامنے آتے ہیں۔ Parallel tool calls میں model ایک response کے اندر کئی calls جاری کرتا ہے، لیکن مختلف providers انہیں مختلف انداز میں represent کرتے ہیں اور ہر جگہ یکساں طور پر support نہیں کرتے۔ Strict schema enforcement ہر provider کی الگ feature ہے۔ اس لیے جو model ایک endpoint پر schema-valid arguments کی ضمانت دیتا ہے، وہ دوسرے endpoint پر صرف valid arguments دینے کی طرف مائل ہوتا ہے۔ Agent اس فرق کو parse error پر مشتمل tool result کے طور پر دیکھتا ہے، اور پھر ایک اور turn استعمال کرکے اسے درست کرنے کی کوشش کرتا ہے۔ ان repair turns پر full prefix price کے حساب سے billing ہوتی ہے، اس لیے format mismatch transcript کے ساتھ invoice پر بھی ظاہر ہوتا ہے۔

Self-hosted endpoints پر یہ configuration صراحت کے ساتھ دینی ہوتی ہے۔ vLLM کے OpenAI-compatible server کو --enable-auto-tool-choice کے ساتھ model family کے مطابق matching --tool-call-parser (hermes، mistral، llama3_json اور دیگر) اور ایسا chat template درکار ہوتا ہے جو tool-role messages کو handle کرے۔ vLLM کی documentation اس path کی حدود واضح کرتی ہے: tool_choice="auto" اور strict schema constraint کے بغیر vLLM raw text سے tool calls extract کرتا ہے، اس لیے arguments کبھی کبھار malformed ہو سکتے ہیں یا function کے parameter schema کی خلاف ورزی کر سکتے ہیں۔ اپنے model کے لیے غلط parser منتخب کرنا ایک configuration error ہے، جو ایسے agent کی صورت میں ظاہر ہوتا ہے جو tools call نہیں کر سکتا۔ Traffic اس endpoint کی طرف route کرنے سے پہلے یہ بات جاننا ضروری ہے۔ Ollama اور vLLM کے درمیان models خود serve کرنے کا فرق یہاں اہم ہے، کیونکہ دونوں tool calling کو مختلف شرائط کے تحت expose کرتے ہیں۔

درمیانِ کام کے دوران fallback رویّہ تبدیل کر دیتا ہے، مگر کوئی error نہیں آتا

Fallback routing وہ feature ہے جو غلطی سے enable ہونے کا سب سے زیادہ امکان رکھتی ہے۔ Gateway کو اس طرح configure کیا جاتا ہے کہ پہلا model rate limit یا 5xx واپس کرے تو یہ دوسرے model پر دوبارہ کوشش کرے، پھر ناکام model کو کچھ seconds کے لیے cooldown میں رکھ دے۔ Chat traffic کے لیے یہ بالکل درست ہے۔ لیکن طویل agent task کے دوران اس کا مطلب یہ ہے کہ task کا دوسرا نصف ایسے model پر چلا جسے آپ نے منتخب نہیں کیا تھا۔

اس کی کوئی اطلاع نہیں ملتی۔ Task fail نہیں ہوتا، agent warning نہیں دیتا، اور exit status success ہوتا ہے۔ نتیجے میں task کا plan ایک model لکھتا ہے اور edits دوسرا model کرتا ہے؛ درمیان میں tone اور کام کرنے کے طریقے بدل جاتے ہیں۔ واحد قابلِ اعتماد signal gateway کے request log یا response metadata میں موجود model field ہے۔ اس لیے اگر آپ fallbacks استعمال کرتے ہیں تو ہر request کے لیے اس field کو log کریں اور نتیجہ غیر متوقع ہونے پر اسے پڑھیں۔ یہ معلوم کیے بغیر behaviour debug کرنا کہ اسے کس model نے پیدا کیا، fallback سے بچائے گئے وقت سے زیادہ وقت ضائع کرتا ہے۔

یہی مسئلہ context compression میں بھی پیش آتا ہے۔ بہت سے agents طویل history کا خلاصہ بنانے کے لیے ایک چھوٹے model کو call کرتے ہیں۔ اگر اس call میں مختلف model یا مختلف system prompt ہو تو یہ اپنی cache entry لکھتا ہے اور main session کی cache entry refresh نہیں کرتا۔ نتیجتاً اگلے مکمل turn میں cold prefix کی لاگت دوبارہ ادا کرنی پڑتی ہے۔ Compression نے tokens تو بچائے، مگر cache ضائع کر دی۔

Routing کا اضافی بوجھ حقیقی ہے، لیکن مسئلہ latency نہیں

Routers ہر request پر اضافی کام کرتے ہیں، اور یہ درست طور پر سمجھنا ضروری ہے کہ یہ کام کتنا ہے۔ DigitalOcean کے مطابق، ان کا Arch-Router model routing intent تقریباً 51 milliseconds میں resolve کرتا ہے، جبکہ ان کی اپنی evaluation میں routing accuracy 93.17% تھی۔ یہ انہی کے اعداد و شمار ہیں، ان کی measurement اور benchmark سے حاصل ہوئے ہیں؛ یہ ہمارے اعداد و شمار نہیں اور نہ ہی universal result ہیں۔ اگر ان اعداد و شمار کو جوں کا توں تسلیم کریں تو نتیجہ اطمینان بخش ہے: 40 agent calls پر 51 milliseconds کا مجموعہ کئی منٹ چلنے والے task میں تقریباً 2 seconds کا اضافہ کرتا ہے۔

یہ 2 seconds routing کو مہنگا نہیں بناتے۔ اصل اضافی بوجھ اس router سے پیدا ہوتا ہے جو full model call کے ذریعے classification کرتا ہے، کیونکہ ہر request پر دوسری inference چلتی ہے، جس کے لیے دوسرے call کی طرح billing اور queueing ہوتی ہے۔ اس کے نیچے اوپر بیان کیا گیا cache arithmetic موجود ہے، جو اضافی بوجھ نہیں ہے۔ یہ اسی چیز کی لاگت ہے جسے routing کو بہتر بنانا تھا۔

اپنے زیر انتظام server پر یہی اصول کم گنجائش کے ساتھ لاگو ہوتا ہے۔ Prompt cache کے مقامی متبادل کو KV cache میں prefix caching کہتے ہیں، اور یہ GPU memory میں موجود ہوتی ہے۔ ایک GPU پر 2 models host کرنے سے یہ memory دونوں کے درمیان تقسیم ہو جاتی ہے۔ نتیجتاً ہر model کے پاس چھوٹی KV cache رہتی ہے اور prefixes جلدی evict ہو جاتے ہیں۔ اس لیے 2 local models کے درمیان routing بیک وقت دونوں کی cache hit rate کم کر سکتی ہے۔ اگر آپ اس کے لیے hardware sizing کر رہے ہیں تو VPS پر coding agent کو درکار memory اور CPU router کے مقابلے میں شروع کرنے کے لیے زیادہ مفید جگہ ہے۔

فیصلہ کرنے کا اصول

• دستیابی کے لیے providers کے درمیان route کریں۔ جب متبادل failed request ہو تو کوئی بھی لاگت قابلِ قبول ہے۔ fallback کو ایسے model کے ساتھ pin کریں جو اسی tool call format کو استعمال کرتا ہو، تاکہ agent کا loop چلتا رہے، اور ہر call کے لیے log کریں کہ کون سا model استعمال ہوا۔
• لاگت کے لیے tiers کے درمیان صرف task boundaries پر route کریں۔ rename کے لیے Haiku اور refactor کے لیے Opus منتخب کرنا ایک اچھا فیصلہ ہے، اگر session شروع ہونے سے پہلے ایک بار کیا جائے۔ اسی session کے turn thirty پر یہ فیصلہ کرنا برا فیصلہ ہے۔
• agentic کام کے لیے ہر session میں ایک model pin کریں۔ session کی قدر اس کے warm cache میں ہے۔ models تبدیل کرنے کو اسی طرح سمجھیں جیسے cache صاف کرنا، کیونکہ عملی طور پر یہی ہوتا ہے۔
• subagents کو آزادانہ route کریں۔ 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 پر point کریں، اور جب تک وہ model unreachable نہ ہو جائے، agent اسی model پر رہتا ہے۔ دونوں entries ایک ہی provider پر ہیں، اس لیے fallback فعال ہونے پر tool call format تبدیل نہیں ہوتا۔ اس وقت tier change قبول کرنا پڑتا ہے، لیکن یہ trade صرف اسی لیے قابلِ قبول ہے کہ متبادل failed request ہے۔ یہ availability routing ہے، جس کے ساتھ cost routing شامل نہیں، اور یہی وہ امتزاج ہے جو زیادہ تر coding agents چاہتے ہیں۔ مکمل طریقہ، جس میں keys اور budgets بھی شامل ہیں، اپنے VPS پر self-hosted LiteLLM gateway چلانا میں دیا گیا ہے؛ یہ post اسے جان بوجھ کر دوبارہ بیان نہیں کرتا۔

جب ایک درست منتخب کیا گیا model ہر router سے بہتر ہو

Routing، request کی difficulty میں variance کا حل ہے۔ Coding agent میں یہ variance بظاہر کم ہے، کیونکہ ہر call کا مہنگا حصہ ایک ہی prefix ہوتا ہے، چاہے call میں کچھ بھی پوچھا گیا ہو۔ جب prefix غالب آ جائے تو cheap tier اور expensive tier کے درمیان فرق ان کی output prices کے فرق تک محدود ہو جاتا ہے، جبکہ output کسی agent کے tokens کا چھوٹا حصہ ہوتا ہے۔

اس لیے مناسب default یہ ہے کہ ایک ہی model ایک بار منتخب کریں، caching فعال کریں، اور TTL (time to live) اتنا طویل رکھیں کہ diff پڑھنے کے لیے رکنے کے دوران cache برقرار رہے۔ Anthropic، base input کی 2 گنا قیمت پر ایک گھنٹے کی cache write پیش کرتا ہے۔ یہ دو بار پڑھنے کے بعد اپنی لاگت پوری کر دیتی ہے، اور اکثر کسی بھی router کے مقابلے میں زیادہ مؤثر طریقہ ہوتی ہے۔ Tier کا انتخاب سوچ سمجھ کر Opus، Sonnet اور Haiku کا براہ راست موازنہ استعمال کرتے ہوئے کریں۔ اگر اس کے باوجود bill مسئلہ ہو تو mid-session switching کے بجائے اسے budgets اور چھوٹے contexts کے ذریعے کم کریں، جیسا کہ VPS پر AI agent کی لاگت کو قابو کرنا میں بیان کیا گیا ہے۔

جب requests ایک دوسرے سے independent اور مختصر ہوں، یا subagents نئے contexts سے شروع ہوں، تو Route کریں۔ جب ایک long session میں ایک ہی job کی جا رہی ہو تو model کو Pin کریں۔ Coding agent کا زیادہ تر کام دوسری قسم میں آتا ہے۔ اسی لیے جو router آپ کی chat product میں رقم بچاتا ہے، وہ یہاں خاموشی سے آپ کی لاگت بڑھا سکتا ہے۔ اگر آپ نے ابھی agent کا انتخاب نہیں کیا تو Claude Code، Cursor، Codex اور Copilot کا موازنہ میں بتایا گیا ہے کہ ہر agent model selection کیسے handle کرتا ہے، اور ان میں سے کچھ یہ فیصلہ خود کرتے ہیں۔

FAQ

کیا سیشن کے درمیان model تبدیل کرنے سے واقعی prompt cache ضائع ہو جاتی ہے؟

ہاں۔ Prompt cache کو prompt prefix کے hash کی بنیاد پر key کیا جاتا ہے اور ہر model کے لیے الگ محفوظ کیا جاتا ہے، اس لیے مختلف model کو بھیجی گئی request ایسے store کے خلاف hash ہوتی ہے جس نے وہ prefix کبھی نہیں دیکھا ہوتا۔ اسے کچھ نہیں ملتا اور مکمل uncached input price ادا کرنی پڑتی ہے۔ اگر 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 کو route کرنا کبھی زیادہ سستا ہوتا ہے؟

صرف اس وقت جب ضائع ہونے کے لیے کوئی warm cache موجود نہ ہو۔ Anthropic پر cache read کی قیمت base input کا 0.1 گنا ہے۔ اس لیے Opus 5 پر warm read، Haiku 4.5 پر uncached input rate سے کم قیمت رکھتی ہے۔ جب session میں بڑا cached prefix موجود ہو تو input کے لیے موجودہ model پہلے ہی سستا انتخاب ہوتا ہے۔ Routing اس وقت فائدہ مند ہے جب context نیا اور مختصر ہو، مثلاً task کے آغاز میں یا ایسے subagent میں جو صرف مطلوبہ context ساتھ لے کر چلتا ہو۔

Task کے دوران میرے agent کا رویہ مختلف کیوں ہو گیا؟

دیکھیں کہ gateway fallback فعال ہوا تھا یا نہیں۔ Primary model پر rate limit یا 5xx آنے سے gateway standby model پر retry کرتا ہے اور primary کو کچھ seconds کے لیے cooldown میں ڈال دیتا ہے، اس لیے task کا باقی حصہ کسی دوسرے model پر چلتا ہے۔ اس عمل میں کوئی error یا warning ظاہر نہیں ہوتی اور task پھر بھی success رپورٹ کرتا ہے۔ Gateway request log یا response metadata میں model field ہی قابل اعتماد record ہے۔ اس لیے اگر آپ fallbacks استعمال کرتے ہیں تو اسے ہر request کے ساتھ log کریں۔

کیا tool calls ہر provider پر ایک جیسے کام کرتے ہیں؟

مکمل طور پر نہیں۔ Anthropic's Messages API میں tool_use اور tool_result content blocks استعمال ہوتے ہیں، جبکہ OpenAI-compatible APIs میں function.arguments کے ذریعے JSON-encoded string رکھنے والا tool_calls array استعمال ہوتا ہے۔ Gateway عام صورتوں کا ترجمہ درست طور پر کر دیتا ہے، لیکن parallel tool calls اور strict schema enforcement ہر provider کے لحاظ سے مختلف ہوتے ہیں۔ Self-hosted vLLM پر آپ کو --enable-auto-tool-choice set کرنا ہوگا اور اپنے model family سے مطابقت رکھنے والا --tool-call-parser مقرر کرنا ہوگا۔ vLLM documentation کے مطابق strict schema constraint کے بغیر server raw text سے tool calls extract کرتا ہے، اس لیے arguments کبھی کبھار malformed ہو سکتے ہیں۔

Coding session کے لیے cache TTL کتنی مقرر کرنی چاہیے؟

مسلسل کام کے لیے default five minute lifetime استعمال کریں۔ اگر human ہر turn کے درمیان diffs پڑھتا ہے تو one hour option استعمال کریں۔ Anthropic میں five minute write کی قیمت base input کا 1.25 گنا اور one hour write کی قیمت 2 گنا ہے، جبکہ read کی قیمت 0.1 گنا ہے۔ Five minute write ایک read سے اپنی قیمت پوری کر لیتی ہے، جبکہ one hour write کے لیے دو reads درکار ہیں۔ اس لیے جس session میں واپس آ کر کام جاری رکھنے کی توقع ہو، وہاں cold prefix کی دوبارہ قیمت ادا کرنے کے مقابلے میں longer lifetime عموماً کم خرچ ہوتی ہے۔