بهینه‌سازی هزینه ایجنت‌های برنامه‌نویسی با مسیریابی مدل

تأثیر مسیریابی چندمدلی بر یک ایجنت برنامه‌نویسی

مسیریابی چندمدلی (Multi-model routing)، هر درخواست را به ارزان‌ترین مدلی می‌فرستد که توانایی پردازش آن را دارد. این روش در ترافیک چت به‌خوبی عمل می‌کند. اما در یک ایجنت برنامه‌نویسی، معمولاً هزینه‌اش بیش از صرفه‌جویی آن است؛ زیرا بخش عمده هزینه یک ایجنت مربوط به پیشوند پرامپت (prompt prefix) است که برای هر مدل به‌صورت جداگانه کش می‌شود و تغییر مدل باعث از دست رفتن این کش می‌گردد.

قانونی که این مطلب از آن دفاع می‌کند چنین است: برای دسترسی‌پذیری، بین ارائه‌دهندگان مختلف مسیریابی کنید؛ برای کاهش هزینه، فقط در مرزهای وظایف (task boundaries) بین سطوح مختلف مدل‌ها جابه‌جا شوید؛ و برای هر فعالیت ایجنتی، در طول یک نشست (session) تنها از یک مدل ثابت استفاده کنید. استدلال‌های این رویکرد در ادامه آمده است.

چهار اصطلاح که در اینجا تعریف می‌شوند: مسیریاب (Router) برای هر درخواست یک مدل را انتخاب می‌کند. دروازه (Gateway) پروکسی‌ای است که درخواست از آن عبور می‌کند و ممکن است عمل مسیریابی را انجام دهد یا ندهد. کش پرامپت (Prompt cache) قابلیتی است که در آن ارائه‌دهنده، پیشوند پردازش‌شده پرامپت شما را ذخیره می‌کند تا درخواست‌های بعدی که آن پیشوند را تکرار می‌کنند، با کسری از قیمت ورودی محاسبه شوند. کش KV (یا کش کلید-مقدار) همان مفهوم را در سروری که خودتان اجرا می‌کنید، پیاده‌سازی می‌کند.

چرا ترافیک چت به‌خوبی مسیریابی می‌شود اما ترافیک عامل (agent) خیر

یک درخواست چت شامل یک نوبت است. درخواست می‌رسد، دسته‌بندی می‌شود، به مدل ارسال شده و پاسخ بازمی‌گردد. هیچ داده‌ای به درخواست بعدی منتقل نمی‌شود. یک مسیریاب می‌تواند این پرسش را به یک مدل کوچک و پرسش بعدی را به یک مدل بزرگ بفرستد، بدون آنکه هیچ‌کدام از درخواست‌ها از وقوع دیگری مطلع باشند. این همان حجم کاری است که تقریباً تمام بنچمارک‌های مسیریابی اندازه‌گیری می‌کنند و مسیریاب‌های خوب در این زمینه واقعاً عملکرد مطلوبی دارند.

یک نوبتِ عامل (agent turn) تنها یک درخواست نیست. یک دستور ساده مانند "تست ناموفق را اصلاح کن" به بیست تا 60 فراخوانی API تبدیل می‌شود. هر فراخوانی، کل گفتگو را مجدداً ارسال می‌کند: پرامپت سیستم، تعریف تمام ابزارها، تمام فایل‌هایی که عامل خوانده و خروجی تمام دستوراتی که مشاهده کرده است. زمینه (context) فقط بزرگ‌تر می‌شود. تا فراخوانی سی‌ام، پیشوند تکراری می‌تواند ده‌ها هزار توکن باشد، در حالی که محتوای واقعاً جدید در هر فراخوانی تنها چند صد توکن است.

این ساختار، معنای کلمه "گران" را تغییر می‌دهد. در چت، هزینه تقریباً برابر است با قیمت مدل ضرب‌در تعداد درخواست. در حلقه عامل، هزینه برابر است با پیشوند که در تک‌تک فراخوانی‌ها دوباره محاسبه و صورت‌حساب می‌شود. ادامه این مطلب از همین یک واقعیت نشأت می‌گیرد.

کش پرامپت مختص هر مدل است و ایجنت درون آن قرار دارد

شرکت Anthropic هزینه خواندن از کش را 0.1 برابر قیمت پایه ورودی و هزینه نوشتن در کش (با ماندگاری پنج دقیقه) را 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 برابر با 0.50 دلار به ازای هر میلیون توکن است. هزینه ورودی بدون کش در مدل Haiku 4.5، که ارزان‌ترین مدل فهرست‌شده است، 1.00 دلار می‌باشد. بنابراین، خواندن مجدد یک پیشوند (prefix) گرم در گران‌ترین مدل، به ازای هر توکن ورودی، ارزان‌تر از خواندن همان پیشوند به صورت سرد در ارزان‌ترین مدل است.

همین یک مقایسه، اکثر برنامه‌های مسیریابی (routing) را نقض می‌کند. مسیریابی که کار را به یک رده پایین‌تر منتقل می‌کند، در حال مقایسه قیمت‌های لیست‌شده است. اما ایجنتی که در میانه نشست (session) قرار دارد، قیمت لیست‌شده را برای مدلی که هم‌اکنون از آن استفاده می‌کند نمی‌پردازد. این ایجنت هزینه خواندن از کش را می‌پردازد که از قبل پایین‌تر از نرخ ورودی بدون کشِ مدل ارزان‌تر است.

کش‌ها بر اساس هشِ پیشوند پرامپت کلیدگذاری می‌شوند و مختص هر مدل هستند. درخواست به یک مدل متفاوت، با حافظه‌ای (store) مطابقت داده می‌شود که هرگز آن را ندیده است؛ بنابراین چیزی پیدا نمی‌کند و باید قیمت کامل را بپردازد. کش همچنین دارای سلسله‌مراتب است: ابتدا ابزارها، سپس سیستم و در نهایت پیام‌ها. تغییر در هر سطح، آن سطح و تمام سطوح بعدی را نامعتبر می‌کند؛ این یعنی ویرایش تعریف یک ابزار، کش پرامپت سیستم که پشت آن قرار دارد را از بین می‌برد. ایجنت‌هایی که ابزارها را در زمان اجرا (runtime) ثبت می‌کنند، بدون اینکه حتی با مسیریاب درگیر شوند، با این مشکل مواجه می‌شوند.

هزینه واقعی یک تغییر مدل در میانه نشست

یک نشست را با پیش‌زمینه (prefix) ثابت 40,000 توکنی در نظر بگیرید؛ اندازه‌ای عادی برای زمانی که یک ایجنت تعدادی فایل را مطالعه کرده است. در ادامه، هزینه پیش‌زمینه برای یک نوبت (turn) بر اساس قیمت‌های لیست‌شده در بالا محاسبه شده است.

[
  {
    "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 با کش گرم، برای پیش‌زمینه آن نوبت 0.020 دلار هزینه دارد. اولین نوبت پس از تغییر مسیر به Sonnet 5، معادل 0.100 دلار هزینه دارد، زیرا Sonnet هیچ ورودی برای این پیش‌زمینه ندارد و باید یکی ایجاد کند. بازگشت به Opus 5 نیز 0.250 دلار هزینه دارد، زیرا ورودی اصلی در مدتی که نشست در مدل دیگری بود، منقضی شده است.

بنابراین، این رفت و برگشت شامل پرداخت هزینه دو بار نوشتن در کش برای اجتناب از دو بار خواندن از کش است. در مقابل، این تغییر مدل باعث شد یک نوبت خروجی با قیمت خروجی Sonnet به جای Opus تولید شود. بلوک جزئیات، کل مسیر را محاسبه می‌کند: صرفه‌جویی در حد کسری از یک سنت است، در حالی که جریمه کش به ده‌ها سنت می‌رسد. جریمه بیش از یک مرتبه بزرگی بیشتر است و با افزایش طول پیش‌زمینه رشد می‌کند، در حالی که صرفه‌جویی چنین نیست.

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

فرمت‌های فراخوانی ابزار در میان ارائه‌دهندگان یکسان نیستند

یک ایجنت در واقع حلقه‌ای از فراخوانی ابزار است، بنابراین فرمت فراخوانی ابزار به شکلی اهمیت دارد که در چت‌های معمولی هرگز مطرح نیست. Messages API در Anthropic یک بلوک محتوایی tool_use برمی‌گرداند و انتظار دارد یک بلوک tool_result دریافت کند. APIهای سازگار با OpenAI یک آرایه tool_calls برمی‌گردانند که در آن function.arguments یک رشته با انکودینگ JSON است، نه یک شیء تو در تو. یک درگاه (gateway) این دو را به هم ترجمه می‌کند و برای فراخوانی‌های عادی، این ترجمه تمیز انجام می‌شود.

مشکلات در لبه‌ها ظاهر می‌شوند. فراخوانی‌های موازی ابزار، که در آن مدل چندین فراخوانی را در یک پاسخ ارسال می‌کند، به شکل‌های متفاوتی نمایش داده می‌شوند و در همه جا به صورت یکسان پشتیبانی نمی‌شوند. اعمال سخت‌گیرانه طرح‌واره (schema) قابلیتی است که به ارائه‌دهنده بستگی دارد؛ بنابراین مدلی که در یک اندپوینت آرگومان‌های معتبر طبق طرح‌واره را تضمین می‌کند، در اندپوینت دیگر فقط به سمت آرگومان‌های معتبر متمایل است. ایجنت این تفاوت را به عنوان نتیجه ابزار حاوی خطای تجزیه (parse error) می‌بیند و سپس تلاش می‌کند با صرف یک نوبت دیگر، آن را اصلاح کند. آن نوبت‌های اصلاحی با قیمت کامل پیشوند (prefix price) محاسبه می‌شوند، بنابراین عدم تطابق فرمت هم در صورت‌حساب و هم در متن گفتگو (transcript) خود را نشان می‌دهد.

اندپوینت‌های self-hosted نیاز دارند که این مورد به‌طور صریح پیکربندی شود. سرور سازگار با OpenAI در vLLM به --enable-auto-tool-choice به همراه یک --tool-call-parser که با خانواده مدل (hermes، mistral، llama3_json و سایر موارد) مطابقت داشته باشد، و همچنین یک قالب چت که پیام‌های با نقش ابزار را مدیریت کند، نیاز دارد. مستندات vLLM در مورد محدودیت‌های این مسیر صریح است: با tool_choice="auto" و بدون محدودیت سخت‌گیرانه طرح‌واره، vLLM فراخوانی‌های ابزار را از متن خام استخراج می‌کند، بنابراین ممکن است آرگومان‌ها گاهی اوقات بدشکل باشند یا طرح‌واره پارامترهای تابع را نقض کنند. انتخاب پارسر اشتباه برای مدل، یک خطای پیکربندی است که به صورت ایجنتی ظاهر می‌شود که نمی‌تواند ابزارها را فراخوانی کند؛ دانستن این موضوع پیش از هدایت ترافیک به سمت آن ارزشمند است. تفاوت بین Ollama و vLLM برای میزبانی مدل‌ها توسط خودتان در اینجا اهمیت دارد، زیرا این دو ابزار، فراخوانی ابزار را با شرایط متفاوتی ارائه می‌دهند.

تغییر رفتار در fallback میان‌وظیفه‌ای بدون بروز خطا

قابلیت fallback routing بیش از هر ویژگی دیگری ممکن است به‌طور تصادفی فعال شود. یک gateway به‌گونه‌ای پیکربندی می‌شود که در صورت دریافت خطای rate limit یا 5xx از مدل اول، تلاش مجددی با مدل دیگری انجام دهد و سپس مدل شکست‌خورده را برای چند ثانیه در وضعیت cooldown قرار دهد. این رفتار برای ترافیک چت کاملاً مناسب است. اما در یک وظیفه (task) طولانیِ agent، این یعنی نیمه دوم وظیفه شما توسط مدلی اجرا شده که آن را انتخاب نکرده‌اید.

هیچ گزارشی در این باره ثبت نمی‌شود. وظیفه شکست نمی‌خورد، agent هشداری نمی‌دهد و وضعیت خروج (exit status) موفقیت‌آمیز است. نتیجه، وظیفه‌ای است که طرح آن توسط یک مدل نوشته شده و ویرایش‌هایش توسط مدل دیگری انجام شده است؛ با لحن و عادت‌هایی که در میانه کار تغییر کرده‌اند. تنها نشانه قابل‌اطمینان، فیلد model در لاگ درخواست gateway یا متادیتای پاسخ است. بنابراین اگر از قابلیت fallback استفاده می‌کنید، حتماً این فیلد را به ازای هر درخواست لاگ کنید و در صورتی که نتیجه غیرمنتظره بود، آن را بررسی کنید. عیب‌یابی رفتار سیستم بدون دانستن اینکه کدام مدل آن را تولید کرده، زمان بیشتری نسبت به زمانی که fallback صرفه‌جویی کرده است، هدر می‌دهد.

همین دام در فشرده‌سازی context نیز وجود دارد. بسیاری از agentها تاریخچه طولانی را با فراخوانی یک مدل کوچک خلاصه می‌کنند. اگر آن فراخوانی از مدل متفاوتی استفاده کند یا system prompt متفاوتی داشته باشد، ورودی cache مخصوص به خود را می‌نویسد و cache نشست اصلی را به‌روزرسانی نمی‌کند؛ در نتیجه، نوبت بعدی که به‌طور کامل اجرا می‌شود، هزینه یک prefix سرد (cold prefix) را متحمل خواهد شد. فشرده‌سازی باعث صرفه‌جویی در توکن‌ها شد اما cache را از دست داد.

سربار مسیریابی واقعی است، اما تأخیر آن نقطهٔ آسیب‌پذیر نیست

مسیریاب‌ها برای هر درخواست کار اضافه‌ای انجام می‌دهند و دقت در میزان این کار اهمیت دارد. DigitalOcean گزارش می‌دهد که مدل Arch-Router آن‌ها، قصد مسیریابی را در حدود 51 میلی‌ثانیه با دقت مسیریابی 93.17% در ارزیابی‌های داخلی خود حل می‌کند. این ارقام متعلق به آن‌هاست، بر اساس اندازه‌گیری و بنچمارک خودشان است، نه ما و نه یک نتیجهٔ جهانی. اگر این اعداد را همان‌طور که هستند بپذیریم، نتیجه اطمینان‌بخش است: 51 میلی‌ثانیه برای چهل فراخوانی عامل، حدود دو ثانیه به وظیفه‌ای که چندین دقیقه طول می‌کشد اضافه می‌کند.

دو ثانیه چیزی نیست که مسیریابی را در اینجا پرهزینه می‌کند. سرباری که واقعاً آسیب می‌زند، مسیریابی است که با یک فراخوانی کامل مدل دسته‌بندی می‌کند، زیرا این کار به معنای یک استنتاج دوم برای هر درخواست است که مانند هر فراخوانی دیگری صورت‌حساب و در صف قرار می‌گیرد. در زیر هر دو مورد، محاسبات کش که در بالا ذکر شد قرار دارد که اصلاً سربار محسوب نمی‌شود. این هزینهٔ همان چیزی است که مسیریابی قرار بود آن را بهینه‌سازی کند.

در سروری که خودتان مدیریت می‌کنید، همین قاعده با آزادی عمل کمتری صدق می‌کند. معادل محلی کشِ پرامپت، کشِ پیشوند (prefix caching) در KV cache است که در حافظهٔ GPU قرار دارد. میزبانی دو مدل روی یک GPU، آن حافظه را بین آن‌ها تقسیم می‌کند، بنابراین هر کدام KV cache کوچک‌تری دارند و پیشوندها را زودتر حذف می‌کنند. بنابراین، مسیریابی بین دو مدل محلی می‌تواند نرخ موفقیت کش (cache hit rate) را برای هر دو به‌طور همزمان کاهش دهد. اگر در حال تعیین ابعاد سخت‌افزار برای این کار هستید، حافظه و CPU مورد نیاز یک عامل کدنویسی روی VPS نقطهٔ شروع مفیدتری نسبت به یک مسیریاب است.

قانون تصمیم‌گیری

• برای دسترسی‌پذیری، درخواست‌ها را بین ارائه‌دهندگان مختلف مسیریابی کنید. زمانی که جایگزین، یک درخواست ناموفق است، هر هزینه‌ای، هزینهٔ درستی است. fallback را روی مدلی با همان فرمت فراخوانی ابزار (tool call) تنظیم کنید تا حلقهٔ عامل (agent loop) به کار خود ادامه دهد و ثبت کنید که هر فراخوانی توسط کدام مدل پاسخ داده شده است.
• مسیریابی بین سطوح مختلف (tiers) را فقط در مرزهای وظایف انجام دهید تا هزینه‌ها کنترل شوند. انتخاب Haiku برای تغییر نام و Opus برای بازنویسی کد، تصمیمی درست است که یک‌بار پیش از شروع نشست (session) گرفته می‌شود. این تصمیم در نوبت سی‌ام همان نشست، یک تصمیم اشتباه است.
• برای هر فعالیت عامل‌محور (agentic)، در هر نشست فقط یک مدل را ثابت نگه دارید. ارزش یک نشست در کش گرم (warm cache) آن است. تغییر مدل را مانند پاک کردن آن کش در نظر بگیرید، زیرا دقیقاً همین کار را انجام می‌دهد.
• زیرعامل‌ها (subagents) را آزادانه مسیریابی کنید. زیرعاملی که با یک کانتکست تازه و کوچک شروع می‌شود، کش گرمی برای از دست دادن ندارد، بنابراین می‌تواند روی هر مدلی که مناسب وظیفه‌اش باشد اجرا شود. این تنها جایی در داخل یک عامل است که مسیریابی تقریباً بدون هزینه است.

برای نحوهٔ ساخت این سیستم، gateway کار را انجام می‌دهد: استفاده از نام‌های مستعار مدل (model aliases) و لیست‌های صریح fallback. یک پیکربندی حداقلی برای LiteLLM proxy به این صورت است.

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 هدایت کنید تا روی یک مدل باقی بماند، مگر اینکه آن مدل در دسترس نباشد. هر دو ورودی روی یک ارائه‌دهنده قرار دارند، بنابراین فرمت فراخوانی ابزار هنگام فعال شدن fallback تغییر نمی‌کند. شما همچنان تغییر سطح (tier) را در آن لحظه می‌پذیرید، که این معامله‌ای است که تنها به این دلیل ارزش انجام دارد که جایگزین آن، یک درخواست ناموفق است. این همان مسیریابی برای دسترسی‌پذیری بدون مسیریابی هزینه‌محور است؛ ترکیبی که اکثر عامل‌های برنامه‌نویسی به آن نیاز دارند. ساخت کامل این سیستم، شامل کلیدها و بودجه‌بندی‌ها، در اجرای LiteLLM gateway روی VPS شخصی پوشش داده شده است و این مطلب عمداً آن را تکرار نمی‌کند.

زمانی که یک مدلِ به‌دقت انتخاب‌شده، بهتر از هر مسیریاب (Router) عمل می‌کند

مسیریابی (Routing) راهکاری برای مدیریت تفاوت در دشواری درخواست‌هاست. یک عامل (Agent) برنامه‌نویسی، برخلاف تصور، واریانس کمتری در این زمینه دارد؛ زیرا بخش هزینه‌بر هر فراخوانی، پیش‌وند (prefix) ثابتی است که فارغ از محتوای درخواست، تکرار می‌شود. هنگامی که این پیش‌وند بر هزینه غالب شود، تفاوت قیمت بین لایه ارزان و گران به تفاوت در قیمت خروجی‌ها محدود می‌شود و خروجی، سهم کوچکی از توکن‌های یک عامل را تشکیل می‌دهد.

بنابراین، رویکرد صادقانه و پیش‌فرض این است که یک مدل را انتخاب کنید، کشینگ (caching) را فعال کرده و TTL (زمان ماندگاری) را به اندازه‌ای طولانی تنظیم کنید که وقفه‌های حین مطالعه diffها را پوشش دهد. سرویس Anthropic قابلیت کش یک‌ساعته را با هزینه 2 برابر ورودی پایه ارائه می‌دهد که پس از دو بار خواندن، هزینه خود را جبران می‌کند؛ این روش اغلب اهرم بهتری نسبت به هر نوع مسیریاب است. مدل خود را با استفاده از مقایسه مستقیم Opus، Sonnet و Haiku به‌دقت انتخاب کنید. اگر همچنان مشکل هزینه دارید، به‌جای تغییر مدل در میان نشست (session)، از بودجه‌بندی و کاهش context مطابق با کنترل هزینه‌های عامل هوش مصنوعی روی VPS استفاده کنید.

زمانی از مسیریابی استفاده کنید که درخواست‌ها مستقل و کوتاه هستند، یا زمانی که زیر-عامل‌ها (subagents) با context تازه شروع به کار می‌کنند. زمانی از مدل ثابت (Pin) استفاده کنید که یک نشست طولانی برای انجام یک وظیفه مشخص دارید. بیشتر کارهای عامل برنامه‌نویسی از نوع دوم است؛ به همین دلیل مسیریابی که در محصولات چت باعث صرفه‌جویی می‌شود، در اینجا به‌طور پنهانی هزینه شما را افزایش می‌دهد. اگر هنوز در مورد خودِ عامل تصمیم نگرفته‌اید، مقایسه Claude Code با Cursor، Codex و Copilot بررسی می‌کند که هر کدام چگونه انتخاب مدل را مدیریت می‌کنند و برخی از آن‌ها این تصمیم را برای شما انجام می‌دهند.

FAQ

آیا تغییر مدل در میانه نشست واقعاً باعث از دست رفتن کش پرامپت می‌شود؟

بله. کش‌های پرامپت بر اساس هش پیشوند پرامپت کلیدگذاری شده و به ازای هر مدل ذخیره می‌شوند؛ بنابراین درخواستی که به مدل دیگری ارسال شود، با حافظه‌ای تطبیق داده می‌شود که هرگز آن پیشوند را ندیده است. در نتیجه، چیزی پیدا نمی‌شود و هزینه کامل ورودی بدون کش پرداخت می‌گردد و اگر کش فعال باشد، هزینه نوشتن در کش نیز به آن اضافه می‌شود. بازگشت به مدل قبلی نیز ورودی اصلی را بازیابی نمی‌کند، زیرا معمولاً طول عمر پیش‌فرض 5 دقیقه در آن زمان منقضی شده است. فیلدهای cache_read_input_tokens و cache_creation_input_tokens را در شیء usage پاسخ بررسی کنید: نوبتی که در یک نشست طولانی، صفر توکن کش‌شده می‌خواند، نشانه این اتفاق است.

آیا مسیریابی به یک مدل ارزان‌تر، همیشه برای یک ایجنت به‌صرفه‌تر است؟

فقط زمانی که کش گرمی برای از دست دادن وجود نداشته باشد. خواندن از کش در Anthropic معادل 0.1 برابر ورودی پایه هزینه دارد، که باعث می‌شود خواندن از کش گرم در Opus 5 ارزان‌تر از نرخ ورودی بدون کش در Haiku 4.5 باشد. هنگامی که یک نشست دارای پیشوند کش‌شده بزرگی است، مدل فعلی از قبل گزینه ارزان‌تری برای ورودی محسوب می‌شود. مسیریابی زمانی صرفه اقتصادی دارد که کانتکست تازه و کوچک باشد: در شروع یک وظیفه، یا در یک زیر-ایجنت که فقط کانتکست مورد نیاز خود را حمل می‌کند.

چرا رفتار ایجنت من در میانه یک وظیفه تغییر کرد؟

بررسی کنید که آیا fallback درگاه (gateway) فعال شده است یا خیر. محدودیت نرخ (rate limit) یا خطای 5xx در مدل اصلی باعث می‌شود درگاه، درخواست را روی مدل جایگزین (standby) دوباره ارسال کند و مدل اصلی را برای چند ثانیه در وضعیت cooldown قرار دهد، بنابراین باقی وظیفه در جای دیگری اجرا می‌شود. این اتفاق هیچ خطا یا هشداری ایجاد نمی‌کند و وظیفه همچنان موفقیت‌آمیز گزارش می‌شود. فیلد model در لاگ درخواست درگاه یا متادیتای پاسخ، تنها رکورد قابل اعتماد است؛ بنابراین اگر از fallback استفاده می‌کنید، آن را برای هر درخواست لاگ کنید.

آیا فراخوانی ابزارها در همه ارائه‌دهندگان به یک شکل کار می‌کند؟

دقیقاً خیر. Messages API در Anthropic از بلوک‌های محتوایی tool_use و tool_result استفاده می‌کند، در حالی که APIهای سازگار با OpenAI از آرایه tool_calls استفاده می‌کنند که function.arguments آن یک رشته با انکودینگ JSON است. یک درگاه موارد رایج را به‌خوبی ترجمه می‌کند، اما فراخوانی‌های موازی ابزار و اعمال سخت‌گیرانه طرحواره (schema) در هر ارائه‌دهنده متفاوت است. در vLLM که خودتان میزبانی می‌کنید، باید --enable-auto-tool-choice و --tool-call-parser منطبق با خانواده مدل خود را تنظیم کنید. مستندات vLLM اشاره می‌کند که بدون محدودیت سخت‌گیرانه طرحواره، سرور فراخوانی‌های ابزار را از متن خام استخراج می‌کند، بنابراین ممکن است آرگومان‌ها گاهی اوقات ناقص یا اشتباه باشند.

طول عمر (TTL) کش را برای یک نشست کدنویسی چقدر باید تنظیم کنم؟

برای کار مداوم از طول عمر پیش‌فرض 5 دقیقه و برای زمانی که انسان تفاوت‌ها (diffs) را بین نوبت‌ها می‌خواند، از گزینه یک ساعت استفاده کنید. Anthropic هزینه نوشتن 5 دقیقه‌ای را 1.25 برابر ورودی پایه و نوشتن یک ساعته را 2 برابر محاسبه می‌کند، در حالی که هزینه خواندن 0.1 برابر است. هزینه نوشتن 5 دقیقه‌ای با یک بار خواندن و هزینه نوشتن یک ساعته با دو بار خواندن جبران می‌شود؛ بنابراین در هر نشستی که انتظار دارید به آن بازگردید و ادامه دهید، طول عمر بیشتر معمولاً هزینه کمتری نسبت به پرداخت هزینه برای پیشوند سرد (cold prefix) دارد.