Coding agent-এ multi-model routing কি সাশ্রয়ী?

কোডিং agent-এ multi-model routing-এর প্রভাব

Multi-model routing প্রতিটি অনুরোধ এমন মডেলে পাঠায়, যা সেটি পরিচালনা করতে পারে এবং যার খরচ সবচেয়ে কম। Chat traffic-এর ক্ষেত্রে এটি ভালোভাবে কাজ করে। কিন্তু coding agent-এর ক্ষেত্রে এটি সাধারণত সাশ্রয়ের চেয়ে বেশি খরচ তৈরি করে। কারণ agent-এর বিলের বড় অংশ আসে এমন একটি prompt prefix থেকে, যা প্রতিটি মডেলের জন্য cached থাকে। মডেল পরিবর্তন করলে সেই cache বাতিল হয়ে যায়।

এই লেখায় যে নিয়মের পক্ষে যুক্তি দেওয়া হয়েছে তা হলো: availability-এর জন্য provider বদলে routing করুন, cost কমানোর জন্য শুধু task boundary-তে tier বদলে routing করুন, এবং agent-ধর্মী কাজের ক্ষেত্রে প্রতি session-এ একটি মডেল নির্দিষ্ট করে রাখুন। নিচের অংশে এর কারণ ব্যাখ্যা করা হয়েছে।

চারটি শব্দ একবার সংজ্ঞায়িত করা যাক। Router প্রতিটি অনুরোধের জন্য একটি মডেল নির্বাচন করে। Gateway হলো সেই proxy, যার মধ্য দিয়ে অনুরোধ যায়; এটি routing করতেও পারে, নাও পারে। Prompt cache হলো provider-এর সংরক্ষিত prompt-এর processed prefix। পরে কোনো অনুরোধে একই prefix পুনরায় পাঠানো হলে input price-এর একটি অংশ হিসেবে তার বিল করা হয়। KV cache (key value cache) একই ধারণা, তবে এটি আপনি নিজে চালানো server-এর ভিতরে ব্যবহৃত হয়।

চ্যাট ট্রাফিক ভালোভাবে রাউট হয়, কিন্তু এজেন্ট ট্রাফিক হয় না

একটি chat request এক টার্নের হয়। এটি আসে, শ্রেণিবদ্ধ হয়, একটি model-এ যায় এবং ফলাফল ফেরত দেয়। পরের request-এ এর কোনো তথ্য বহন করা হয় না। একটি router এই প্রশ্নটি একটি ছোট model-এ এবং পরের প্রশ্নটি একটি বড় model-এ পাঠাতে পারে; কোনো request-ই জানে না যে অন্যটি আগে ঘটেছে। প্রায় সব routing benchmark এই ধরনের workload পরিমাপ করে, এবং ভালো router-গুলো এতে সত্যিই ভালো কাজ করে।

একটি agent turn একটি request নয়। "fix the failing test"-এর মতো একটি নির্দেশনা 20 থেকে 60টি API call-এ পরিণত হতে পারে। প্রতিটি call-এ পুরো conversation আবার পাঠানো হয়: system prompt, প্রতিটি tool definition, agent যে প্রতিটি file পড়েছে, এবং দেখা প্রতিটি command output। Context ক্রমেই বড় হয়। 30তম call-এ পুনরাবৃত্ত prefix-এ কয়েক দশ হাজার token থাকতে পারে, অথচ প্রতিটি call-এ প্রকৃত নতুন content থাকে মাত্র কয়েক শ token।

এই গঠনটি "expensive" শব্দটির অর্থ বদলে দেয়। Chat-এ cost মোটামুটি model-এর price এবং request-এর গুণফলের সমান। Agent loop-এ প্রতিটি call-এ prefix-এর জন্য আবার billing হয়। এই একটি তথ্য থেকেই এই পোস্টের বাকি বিষয়গুলো অনুসরণ করে।

Prompt cache প্রতি model-এর জন্য আলাদা, এবং agent তার ভেতরেই থাকে

Anthropic cache read-এর মূল্য base 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-টি প্রথমটির সঙ্গে row ধরে তুলনা করুন, column ধরে নয়। Opus 5-এ cache read-এর মূল্য প্রতি million token-এ 0.50 dollar। তালিকাভুক্ত মডেলগুলোর মধ্যে সবচেয়ে সস্তা Haiku 4.5-এ uncached input-এর মূল্য 1.00 dollar। তাই সবচেয়ে দামী মডেলে একটি warm prefix পুনরায় পড়ার জন্য প্রতি input token-এ যে খরচ হয়, তা সবচেয়ে সস্তা মডেলে একই prefix প্রথমবার পড়ার খরচের চেয়েও কম।

এই একটি তুলনাই অধিকাংশ routing plan-এর ভিত্তি বদলে দেয়। কোনো router কাজকে “নিচের” tier-এ পাঠালে তা তালিকামূল্য তুলনা করছে। কিন্তু একটি agent session-এর মাঝামাঝি অবস্থায় যে model ব্যবহার করছে, তার জন্য তালিকামূল্য প্রযোজ্য নয়। সে cache read price দিচ্ছে, যা ইতিমধ্যে সস্তা model-এর uncached rate-এর নিচে।

Cache prompt prefix-এর hash-এর ওপর নির্ভর করে এবং প্রতি model-এর জন্য আলাদা। অন্য model-এ পাঠানো request এমন একটি store-এর বিরুদ্ধে hash হয়, যা সেটিকে আগে কখনও দেখেনি। তাই সেখানে কিছু পাওয়া যায় না এবং পূর্ণ মূল্য দিতে হয়। Cache-টিও একটি hierarchy: প্রথমে tools, তারপর system, তারপর messages। যেকোনো স্তরে পরিবর্তন হলে সেই স্তর এবং তার পরের সব স্তরের cache invalid হয়ে যায়। অর্থাৎ একটি tool definition সম্পাদনা করলে তার পেছনে থাকা system prompt cache-ও বাতিল হয়। Runtime-এ tools register করা agent-গুলো router-এ কোনো পরিবর্তন না করেও এই সমস্যায় পড়ে।

একটি সেশনের মাঝখানে একবার model পরিবর্তনের প্রকৃত খরচ

40,000 token-এর একটি স্থিতিশীল prefix-সহ একটি session বিবেচনা করুন। কোনো agent কয়েকটি file পড়ার পর এটি সাধারণ আকারের prefix হতে পারে। উপরের list price ব্যবহার করে একটি turn-এর prefix cost নিচে হিসাব করা হয়েছে।

[
  {
    "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 dollar। Sonnet 5-এ routing করার পর প্রথম turn-এর খরচ 0.100 dollar, কারণ Sonnet-এ এই prefix-এর কোনো entry নেই এবং সেটিকে একটি entry লিখতে হয়। আবার Opus 5-এ ফিরলে খরচ 0.250 dollar, কারণ session অন্য model-এ থাকা অবস্থায় আগের entry-টির মেয়াদ শেষ হয়ে যায়।

তাই round trip-এ দুটি cache read এড়াতে দুটি cache write-এর খরচ দিতে হয়। এর বিনিময়ে switch করার ফলে একটি turn-এর output Opus-এর বদলে Sonnet-এর output price-এ পাওয়া যায়। details block-এ পুরো হিসাব দেখানো হয়েছে: সাশ্রয় cent-এর ভগ্নাংশে সীমাবদ্ধ, কিন্তু cache-এর অতিরিক্ত খরচ দশমাংশ dollar-এ পৌঁছায়। অতিরিক্ত খরচটি এক 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

Tool call-এর format providerভেদে এক নয়

একটি agent tool-calling loop হিসেবে কাজ করে। তাই chat-এর ক্ষেত্রে যা গুরুত্বপূর্ণ নয়, tool call-এর ক্ষেত্রে format তা গুরুত্বপূর্ণ। Anthropic-এর Messages API একটি tool_use content block ফেরত দেয় এবং এর উত্তরে tool_result block প্রত্যাশা করে। OpenAI-compatible API-গুলো এমন একটি tool_calls array ফেরত দেয়, যেখানে function.arguments একটি nested object নয়, JSON-encoded string। একটি gateway এই দুই format-এর মধ্যে রূপান্তর করে। সাধারণ call-এর ক্ষেত্রে এই রূপান্তর নির্ভুল হয়।

সমস্যা দেখা দেয় edge case-এ। Parallel tool call-এ model একটি response-এ একাধিক call পাঠায়। বিভিন্ন provider-এ এগুলো ভিন্নভাবে উপস্থাপিত হয় এবং সব জায়গায় একইভাবে সমর্থিত নয়। Strict schema enforcement provider-নির্ভর feature। তাই একটি endpoint-এ schema-valid argument নিশ্চিত করা model অন্য endpoint-এ কেবল সাধারণত valid argument তৈরি করে। Agent এই পার্থক্যকে parse error-সহ একটি tool result হিসেবে দেখে। এরপর আরও একটি turn ব্যবহার করে এটি মেরামত করার চেষ্টা করে। এই repair turn-গুলোর জন্য সম্পূর্ণ prefix price প্রযোজ্য হয়। তাই format mismatch transcript-এর পাশাপাশি invoice-এও দেখা যায়।

Self-hosted endpoint-এ এটি স্পষ্টভাবে configure করতে হয়। vLLM-এর OpenAI-compatible server-এ model family-এর (hermes, mistral, llama3_json এবং অন্যান্য) সঙ্গে সামঞ্জস্যপূর্ণ একটি --tool-call-parser-সহ --enable-auto-tool-choice প্রয়োজন। Tool-role message পরিচালনা করতে পারে এমন একটি chat template-ও প্রয়োজন। vLLM documentation এই ব্যবস্থার সীমাবদ্ধতা স্পষ্টভাবে উল্লেখ করে: tool_choice="auto" ব্যবহার করা হলে এবং strict schema constraint না থাকলে vLLM raw text থেকে tool call শনাক্ত করে। ফলে argument মাঝে মাঝে malformed হতে পারে অথবা function-এর parameter schema লঙ্ঘন করতে পারে। Model-এর জন্য ভুল parser নির্বাচন করা একটি configuration error। এর ফল এমন একটি agent, যা tool call করতে পারে না। Traffic সেই endpoint-এ পাঠানোর আগে এই বিষয়টি জানা গুরুত্বপূর্ণ। নিজে model serve করার ক্ষেত্রে Ollama এবং vLLM-এর পার্থক্য এখানে গুরুত্বপূর্ণ, কারণ দুটি system ভিন্ন শর্তে tool calling প্রকাশ করে।

মাঝপথে fallback ব্যবহার হলে কোনো error ছাড়াই আচরণ বদলে যায়

ভুলবশত enable হয়ে যাওয়ার সম্ভাবনা সবচেয়ে বেশি এমন feature হলো fallback routing। একটি gateway এমনভাবে configure করা হয় যে প্রথম model rate limit বা 5xx ফেরত দিলে সেটি অন্য model-এ আবার চেষ্টা করে। এরপর ব্যর্থ model-টিকে কয়েক সেকেন্ডের জন্য cooldown-এ রাখা হয়। chat traffic-এর ক্ষেত্রে এটি সঠিক আচরণ। কিন্তু দীর্ঘ agent task-এর মধ্যে এর অর্থ হলো, আপনার task-এর দ্বিতীয় অর্ধ এমন একটি model-এ চলেছে, যেটি আপনি বেছে নেননি।

এটি কোনো জায়গায় report হয় না। task ব্যর্থ হয় না, agent সতর্ক করে না, এবং exit status success থাকে। ফলাফল হিসেবে এমন একটি task পাওয়া যায়, যার plan একটি model লিখেছে এবং edits অন্য একটি model করেছে। মাঝপথে tone ও কাজের ধরন বদলে যায়। একমাত্র নির্ভরযোগ্য signal হলো gateway-এর request log বা response metadata-তে থাকা model field। তাই fallback ব্যবহার করলে প্রতি request-এর জন্য ওই field log করুন এবং কোনো result অপ্রত্যাশিত হলে সেটি পরীক্ষা করুন। কোন model result তৈরি করেছে তা না জেনে আচরণ debug করতে গেলে fallback যে সময় বাঁচিয়েছে, তার চেয়ে বেশি সময় নষ্ট হয়।

একই সমস্যা context compression-এর ক্ষেত্রেও দেখা যায়। অনেক agent দীর্ঘ history সংক্ষিপ্ত করতে একটি ছোট model call করে। ওই call-এ ভিন্ন model বা ভিন্ন system prompt থাকলে সেটি নিজের cache entry লেখে এবং মূল session-এর cache refresh করে না। ফলে পরের পূর্ণ turn-এ cold prefix-এর খরচ দিতে হয়। Compression tokens বাঁচায়, কিন্তু cache হারায়।

Routing-এর overhead বাস্তব, তবে latency যেখানে ক্ষতি করে তা নয়

প্রতিটি অনুরোধে router অতিরিক্ত কাজ করে। এই কাজের পরিমাণ সম্পর্কে নির্ভুল থাকা জরুরি। DigitalOcean জানিয়েছে, তাদের Arch-Router model routing intent নির্ধারণ করতে প্রায় 51 milliseconds সময় নেয় এবং তাদের নিজস্ব evaluation-এ routing accuracy ছিল 93.17%। এগুলো তাদের measurement ও benchmark-এর ফলাফল; আমাদের নয় এবং সর্বজনীন ফলাফলও নয়। এই সংখ্যাগুলো সরাসরি গ্রহণ করলেও সিদ্ধান্তটি আশ্বস্ত করার মতো: চল্লিশটি agent call-এ 51 milliseconds করে যোগ হলে কয়েক মিনিট চলা একটি task-এ মোট প্রায় দুই seconds যোগ হয়।

এখানে routing-কে ব্যয়বহুল করে তোলে দুই seconds নয়। যে overhead সত্যিই ক্ষতি করে, তা হলো full model call দিয়ে classification করা router। কারণ এতে প্রতিটি request-এ দ্বিতীয় একটি inference চালাতে হয়, যা অন্য যেকোনো inference-এর মতোই bill ও queue হয়। এর নিচে আগের cache arithmetic-ও রয়েছে, যা overhead নয়। routing যে বিষয়টি optimize করার কথা ছিল, সেটিরই cost এটি।

আপনি নিজে চালানো server-এ একই নিয়ম প্রযোজ্য, তবে পরিবর্তনের সুযোগ কম। Prompt cache-এর local equivalent হলো KV cache-এ prefix caching, যা GPU memory-তে থাকে। একটি GPU-তে দুটি model host করলে memory তাদের মধ্যে ভাগ হয়ে যায়। ফলে প্রতিটি model-এর জন্য ছোট KV cache থাকে এবং prefix দ্রুত evict হয়। তাই দুটি local model-এর মধ্যে routing করলে একই সময়ে উভয় model-এর cache hit rate কমতে পারে। এ জন্য hardware sizing করলে router দিয়ে শুরু করার চেয়ে একটি VPS-এ coding agent-এর আসলে যত memory ও CPU প্রয়োজন দিয়ে শুরু করা বেশি কার্যকর।

রাউটিংয়ের সিদ্ধান্তের নিয়ম

• প্রাপ্যতার জন্য provider-এর মধ্যে route করুন। বিকল্প যদি request ব্যর্থ হওয়া হয়, তাহলে যেকোনো খরচই গ্রহণযোগ্য। Fallback এমন একটি model-এ নির্ধারণ করুন, যেটি একই tool call format ব্যবহার করে, যাতে agent-এর loop সচল থাকে। প্রতিটি call কোন model পরিবেশন করেছে, তা log করুন।
• শুধু task boundary-তে খরচের স্তর অনুযায়ী route করুন। Rename-এর জন্য Haiku এবং refactor-এর জন্য Opus বেছে নেওয়া session শুরুর আগে একবার নেওয়া ভালো সিদ্ধান্ত। একই session-এর turn thirty-তে এই সিদ্ধান্ত নেওয়া খারাপ সিদ্ধান্ত।
• Agent-সংক্রান্ত যেকোনো কাজে প্রতি session-এ একটি model নির্ধারণ করে রাখুন। একটি session-এর মূল্য তার warm cache-এ। Model পরিবর্তনকে cache পরিষ্কার করার মতো বিবেচনা করুন, কারণ কার্যত সেটিই ঘটে।
• Subagent-গুলোকে স্বাধীনভাবে route করুন। Fresh, small context নিয়ে শুরু করা subagent-এর হারানোর মতো কোনো warm cache থাকে না। তাই তার কাজের উপযোগী যেকোনো model-এ সেটি চালানো যায়। Agent-এর ভেতরে এটিই একমাত্র ক্ষেত্র, যেখানে routing প্রায় বিনামূল্যে।

এটি তৈরি করার কাজ gateway-ই করে: model alias এবং explicit fallback list ব্যবহার করে। একটি ন্যূনতম 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-এ থাকে। উভয় entry একই provider-এ আছে, তাই fallback সক্রিয় হলেও tool call format পরিবর্তিত হয় না। সেই মুহূর্তে tier পরিবর্তন মেনে নিতে হবে। তবে বিকল্প যদি request ব্যর্থ হওয়া হয়, তাহলে এই বিনিময় গ্রহণযোগ্য। এটি cost routing ছাড়া availability routing, এবং অধিকাংশ coding agent-এর জন্য এই সমন্বয়ই উপযুক্ত। Keys ও budgets-সহ সম্পূর্ণ setup নিজের VPS-এ self-hosted LiteLLM gateway চালানো-এ বর্ণনা করা হয়েছে। এই post-এ তা ইচ্ছাকৃতভাবে পুনরাবৃত্তি করা হয়নি।

যেকোনো router-এর চেয়ে সঠিকভাবে বাছাই করা একটি model যখন ভালো

Routing হলো request-এর জটিলতার ভিন্নতা সামলানোর একটি পদ্ধতি। Coding agent-এর ক্ষেত্রে এই ভিন্নতা যতটা মনে হয়, আসলে ততটা নয়। কারণ প্রতিটি call-এর ব্যয়বহুল অংশ একই prefix, call-এ যা চাওয়া হোক না কেন। Prefix-এর ব্যয় প্রাধান্য পেলে cheap tier এবং expensive tier-এর মূল্যের পার্থক্য output price-এর পার্থক্যের দিকে কমে আসে। আর agent-এর মোট token-এর তুলনায় output-এর অংশ ছোট।

তাই বাস্তবসম্মত default হলো একবার একটি model বেছে নিয়ে সেটিই ব্যবহার করা। Caching চালু রাখুন এবং TTL (time to live) এমন দীর্ঘ রাখুন, যাতে diff পড়ার জন্য থামলে সেই বিরতিও এতে অন্তর্ভুক্ত হয়। Anthropic base input-এর 2 গুণ মূল্যে এক ঘণ্টার cache write দেয়। দুইবার পড়ার পরই এর খরচ উঠে আসে। তাই অনেক ক্ষেত্রে যেকোনো router-এর চেয়ে এটি বেশি কার্যকর নিয়ন্ত্রণ। Opus, Sonnet এবং Haiku-এর সরাসরি তুলনা ব্যবহার করে tier সচেতনভাবে বেছে নিন। বিল যদি এখনও সমস্যা হয়, mid-session switching না করে VPS-এ AI agent-এর খরচ নিয়ন্ত্রণ-এ বর্ণিত পদ্ধতিতে budget এবং ছোট context ব্যবহার করে খরচ কমান।

Request-গুলো independent ও ছোট হলে, অথবা subagent-গুলো fresh context দিয়ে শুরু করলে route করুন। একটি long session-এ একটি কাজ চললে model pin করুন। Coding agent-এর অধিকাংশ কাজ দ্বিতীয় ধরনের। তাই আপনার chat product-এ যে router খরচ কমায়, এখানে সেটিই নীরবে খরচ বাড়াতে পারে। এখনও agent বেছে না নিলে Claude Code এবং Cursor, Codex ও Copilot-এর তুলনা দেখুন। এতে প্রতিটি agent model selection কীভাবে সামলায় তা ব্যাখ্যা করা হয়েছে। কিছু agent এই সিদ্ধান্ত আপনার হয়ে নেয়।

FAQ

সেশন চলাকালে মডেল পরিবর্তন করলে কি সত্যিই prompt cache হারিয়ে যায়?

হ্যাঁ। Prompt cache prompt prefix-এর hash-এর ওপর নির্ভর করে এবং প্রতিটি model-এর জন্য আলাদাভাবে সংরক্ষিত হয়। তাই অন্য model-এ পাঠানো request এমন একটি store-এর বিরুদ্ধে hash হয়, যেখানে ওই prefix আগে কখনও দেখা হয়নি। সেখানে কিছু পাওয়া যায় না এবং সম্পূর্ণ uncached input-এর মূল্য দিতে হয়। caching enabled থাকলে এর সঙ্গে cache write-এর মূল্যও যোগ হয়। পরে আগের model-এ ফিরে গেলেও মূল entry পুনরুদ্ধার হয় না, কারণ ততক্ষণে default five minute lifetime সাধারণত শেষ হয়ে যায়। Response usage object-এর cache_read_input_tokens এবং cache_creation_input_tokens field পরীক্ষা করুন। দীর্ঘ session-এ কোনো turn-এ cached token-এর সংখ্যা zero হলে সেটিই এর লক্ষণ।

Agent-এর জন্য সস্তা model-এ routing করা কি কখনও কম খরচের হয়?

শুধু তখনই, যখন হারানোর মতো কোনো warm cache নেই। Anthropic-এ cache read-এর মূল্য base input-এর 0.1 গুণ। তাই Haiku 4.5-এর uncached input rate-এর তুলনায় Opus 5-এ warm read-এর খরচ কম। Session-এ একবার বড় cached prefix তৈরি হয়ে গেলে input-এর ক্ষেত্রে বর্তমান model-ই ইতিমধ্যে সস্তা বিকল্প। Context নতুন এবং ছোট হলে routing সাশ্রয়ী হয়। যেমন task-এর শুরুতে, অথবা এমন subagent-এ, যা শুধু প্রয়োজনীয় context বহন করে।

Task-এর মাঝপথে আমার agent-এর আচরণ ভিন্ন হয়ে গেল কেন?

Gateway fallback সক্রিয় হয়েছিল কি না পরীক্ষা করুন। Primary model-এ rate limit বা 5xx হলে gateway standby model-এ retry করে এবং কয়েক সেকেন্ডের জন্য primary-কে cooldown-এ রাখে। ফলে task-এর বাকি অংশ অন্য model-এ চলে। এতে কোনো error বা warning দেখা যায় না এবং task সফল হয়েছে বলেই report করে। Gateway request log বা response metadata-এর model field-ই নির্ভরযোগ্য record। তাই fallback ব্যবহার করলে প্রতিটি request-এ এটি log করুন।

প্রতিটি provider-এ কি tool call একইভাবে কাজ করে?

পুরোপুরি নয়। Anthropic-এর Messages API-তে tool_use এবং tool_result content block ব্যবহৃত হয়। OpenAI-compatible API-তে tool_calls array ব্যবহৃত হয়, যার function.arguments হলো JSON-encoded string। Gateway সাধারণ ক্ষেত্রে ভালোভাবে অনুবাদ করে। তবে parallel tool call এবং strict schema enforcement provider অনুযায়ী ভিন্ন হয়। Self-hosted vLLM-এ --enable-auto-tool-choice সেট করতে হবে এবং model family-এর সঙ্গে সামঞ্জস্যপূর্ণ --tool-call-parser নির্ধারণ করতে হবে। vLLM documentation অনুযায়ী strict schema constraint না থাকলে server raw text থেকে tool call extract করে। তাই arguments মাঝে মাঝে malformed হতে পারে।

Coding session-এর জন্য cache TTL কতক্ষণ নির্ধারণ করা উচিত?

একটানা কাজের জন্য default five minute lifetime ব্যবহার করুন। Turn-এর মধ্যে মানুষ diff পড়লে one hour option ব্যবহার করুন। Anthropic পাঁচ মিনিটের write-এর জন্য base input-এর 1.25 গুণ এবং এক ঘণ্টার write-এর জন্য 2 গুণ মূল্য নেয়। Read-এর মূল্য 0.1 গুণ। পাঁচ মিনিটের write একবার read হলেই উঠে আসে। এক ঘণ্টার write উঠে আসতে দুইটি read লাগে। তাই ফিরে এসে কাজ চালিয়ে যাওয়ার সম্ভাবনা থাকলে দীর্ঘ lifetime সাধারণত cold prefix-এর জন্য বারবার মূল্য দেওয়ার চেয়ে কম খরচের হয়।