Multi-model routing para sa coding agents

Ano ang epekto ng multi-model routing sa coding agent

Ipinapadala ng multi-model routing ang bawat request sa pinakamurang model na kayang humawak nito. Maayos itong gumagana sa chat traffic. Sa coding agent, karaniwan itong mas magastos kaysa sa natitipid dahil ang malaking bahagi ng bill ng agent ay nagmumula sa prompt prefix na naka-cache sa bawat model. Kapag nagpalit ng model, nawawala ang cache na iyon.

Ito ang panuntunang ipinapaliwanag ng post na ito: mag-route sa pagitan ng mga provider para sa availability; mag-route sa pagitan ng mga tier para makatipid lamang sa hangganan ng bawat task; at mag-pin ng isang model sa bawat session para sa anumang agentic na gawain. Narito ang paliwanag.

Apat na termino ang minsanang tutukuyin. Ang router ang pumipili ng model para sa bawat request. Ang gateway ang proxy na dinaraanan ng request. Maaari rin itong mag-route, pero hindi ito palaging ganoon. Ang prompt cache ay ang pag-iimbak ng provider sa naprosesong prefix ng prompt mo. Dahil dito, ang susunod na request na inuulit ang prefix na iyon ay sinisingil sa maliit na bahagi ng input price. Ang KV cache (key value cache) ay kaparehong konsepto sa loob ng server na ikaw mismo ang nagpapatakbo.

Bakit mahusay ang pag-route ng chat traffic pero hindi ng agent traffic

Ang chat request ay isang turn. Dumarating ito, kino-classify, ipinapadala sa isang model, at ibinabalik ang resulta. Walang nagpapatuloy sa susunod na request. Maaaring ipadala ng router ang tanong na ito sa maliit na model at ang susunod naman sa malaking model, nang hindi alam ng alinmang request na naganap ang isa pa. Ito ang workload na sinusukat ng halos lahat ng routing benchmark, at talagang mahusay dito ang mga router.

Hindi isang request ang agent turn. Ang isang instruction gaya ng "ayusin ang failing test" ay nagiging dalawampu hanggang animnapung API call. Sa bawat call, muling ipinapadala ang buong conversation: ang system prompt, bawat tool definition, bawat file na nabasa ng agent, at bawat command output na nakita nito. Patuloy na lumalaki ang context. Pagsapit ng call 30, maaaring umabot sa sampu-sampung libong token ang paulit-ulit na prefix, samantalang ilang daang token lamang ang tunay na bagong content sa bawat call.

Binabago ng ganitong pattern ang kahulugan ng salitang "magastos." Sa chat, ang cost ay humigit-kumulang presyo ng model na minultiply sa request. Sa agent loop, ang cost ay nasa prefix, na muling sinisingil sa bawat call. Ang lahat ng sumusunod sa post na ito ay nagmumula sa iisang katotohanang iyon.

Ang prompt cache ay bawat model, at nananatili rito ang agent

Tinatapatan ng Anthropic ang halaga ng cache read sa 0.1 beses ng base input price, at ang five-minute cache write sa 1.25 beses nito. Ito ang mga published list price noong 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"
  }
]

Basahin ang ikalawang serye laban sa una, pahalang sa mga row sa halip na pababa sa mga column. Ang cache read sa Opus 5 ay 0.50 dollars bawat milyong token. Ang uncached input sa Haiku 4.5, ang pinakamurang modelong nakalista, ay 1.00 dollars. Kaya ang muling pagbasa sa warm prefix sa pinakamahal na model ay mas mura bawat input token kaysa sa cold read ng kaparehong prefix sa pinakamurang model.

Binabago ng iisang paghahambing na ito ang karamihan ng routing plan. Kapag inililipat ng router ang workload “pababa” ng tier, list prices ang ikinukumpara nito. Pero ang agent na nasa kalagitnaan ng session ay hindi nagbabayad ng list price sa model na ginagamit na nito. Cache read price ang binabayaran nito, at mas mababa na ito kaysa sa uncached rate ng murang model.

Naka-key ang mga cache sa hash ng prompt prefix, at bawat model ang may sariling cache. Kapag ibang model ang request, nagha-hash ito laban sa store na hindi pa ito nakita, kaya walang nahahanap at full price ang binabayaran. Hierarchy rin ang cache: tools muna, kasunod ang system, at pagkatapos ang messages. Kapag may binago sa alinmang level, nadi-disable ang cache sa level na iyon at sa lahat ng sumusunod dito. Ibig sabihin, kapag nag-edit ng isang tool definition, nabubura ang system prompt cache na nasa likod nito. Nararanasan ito ng mga agent na nagre-register ng tools habang runtime kahit walang binabago sa router.

Ano talaga ang gastos ng isang mid-session switch

Isaalang-alang ang isang session na may 40,000-token stable prefix, isang karaniwang laki kapag nakabasa na ang isang agent ng ilang file. Nasa ibaba ang prefix cost ng isang turn, batay sa mga list price sa itaas.

[
  {
    "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"
  }
]

Ang pananatili sa Opus 5 na may warm cache ay nagkakahalaga ng 0.020 dollars para sa prefix ng turn na iyon. Ang unang turn matapos mag-route pababa sa Sonnet 5 ay nagkakahalaga ng 0.100 dollars, dahil walang entry ang Sonnet para sa prefix na ito at kailangan nitong magsulat ng isa. Ang pagbabalik sa Opus 5 ay nagkakahalaga ng 0.250 dollars, dahil nag-expire ang orihinal na entry habang wala ang session.

Kaya ang round trip ay nagbabayad para sa dalawang cache write upang maiwasan ang dalawang cache read. Kapalit nito, nakakuha ang switch ng isang turn ng output sa output price ng Sonnet sa halip na sa presyo ng Opus. Ipinapakita ng details block ang buong kalkulasyon: ang natipid ay fraction lamang ng isang cent, samantalang ang cache penalty ay nasa mga tenths ng isang dollar. Mahigit isang order of magnitude ang diperensiya, at lumalaki ang penalty kasabay ng prefix length habang hindi nagbabago ang 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

Hindi pare-pareho ang mga format ng tool call sa bawat provider

Tool-calling loop ang isang agent, kaya mahalaga ang format ng tool call sa paraang hindi naman mahalaga sa chat. Nagbabalik ang Anthropic Messages API ng tool_use content block at inaasahan nito ang tool_result block bilang tugon. Nagbabalik naman ang mga OpenAI-compatible API ng tool_calls array kung saan ang function.arguments ay isang JSON-encoded na string, hindi isang nested object. Nagsasalin sa pagitan ng dalawang format ang isang gateway, at malinis ang translation para sa mga karaniwang call.

Lumilitaw ang mga problema sa mga edge case. Naiiba ang representation ng parallel tool calls, kung saan maraming call ang inilalabas ng model sa iisang response, at hindi pare-pareho ang support dito sa lahat ng provider. Per-provider feature ang strict schema enforcement. Kaya ang model na ginagarantiyahan ang schema-valid na arguments sa isang endpoint ay karaniwang valid lamang ang arguments sa ibang endpoint. Nakikita ng agent ang pagkakaiba bilang tool result na may parse error, at sinusubukan nitong ayusin ito sa pamamagitan ng isa pang turn. Sinisingil ang mga repair turn sa buong prefix price, kaya lumalabas sa invoice at sa transcript ang format mismatch.

Kailangang tahasang i-configure ang mga self-hosted endpoint. Nangangailangan ang OpenAI-compatible server ng vLLM ng --enable-auto-tool-choice kasama ng --tool-call-parser na tumutugma sa model family (hermes, mistral, llama3_json at iba pa), pati ng chat template na humahawak sa mga tool-role message. Malinaw ang vLLM documentation tungkol sa mga limitasyon ng path na ito: kapag tool_choice="auto" at walang strict schema constraint, kumukuha ang vLLM ng tool calls mula sa raw text, kaya maaaring paminsan-minsang mali ang format ng arguments o lumabag ang mga ito sa parameter schema ng function. Ang pagpili ng maling parser para sa model mo ay isang configuration error na lumalabas bilang agent na hindi makatawag ng tools. Mahalagang malaman ito bago mo i-route ang traffic dito. Mahalaga rito ang pagkakaiba ng Ollama at vLLM sa sariling pag-serve ng mga model, dahil magkaiba ang paraan ng pag-expose ng tool calling ng dalawang ito.

Nagbabago ang behavior sa gitna ng task nang walang error

Ang fallback routing ang feature na pinakamalamang ma-enable nang hindi sinasadya. Kino-configure ang gateway na mag-retry gamit ang ibang model kapag nagbalik ang unang model ng rate limit o 5xx, at pagkatapos ay inilalagay ang nag-fail na model sa cooldown nang ilang segundo. Para sa chat traffic, tama ang behavior na ito. Pero sa loob ng mahabang agent task, nangangahulugan itong tumakbo ang ikalawang bahagi ng task gamit ang model na hindi mo pinili.

Walang nagre-report nito. Hindi nagfa-fail ang task, hindi nagwa-warn ang agent, at success ang exit status. Ang makukuha mo ay task kung saan isang model ang sumulat ng plan at ibang model ang gumawa ng edits, kaya nagbabago sa kalagitnaan ang tono at mga nakasanayang paraan ng paggawa. Ang tanging maaasahang signal ay ang model field sa request log ng gateway o sa response metadata. Kaya kung gumagamit ka ng fallbacks, i-log ang field na ito sa bawat request at basahin ito kapag nakakagulat ang resulta. Ang pag-debug ng behavior nang hindi alam kung aling model ang gumawa nito ay mas nakakaubos ng oras kaysa sa oras na natipid ng fallback.

Nangyayari rin ang parehong problema sa context compression. Maraming agent ang nagsa-summarize ng mahabang history sa pamamagitan ng pagtawag sa isang maliit na model. Kung ibang model o ibang system prompt ang dala ng call na iyon, sarili nitong cache entry ang sinusulat nito at hindi nito nire-refresh ang cache ng pangunahing session. Dahil dito, magbabayad ang susunod na full turn para sa cold prefix. Nakatipid ng tokens ang compression, pero nawala ang cache.

Totoo ang routing overhead, pero hindi latency ang pangunahing problema

Nagdadagdag ng trabaho ang mga router sa bawat request, kaya mahalagang eksakto tayo sa pagtaya kung gaano ito kalaki. Iniulat ng DigitalOcean na nireresolba ng kanilang Arch-Router model ang routing intent sa humigit-kumulang 51 milliseconds, na may 93.17% routing accuracy sa sarili nilang evaluation. Ang mga numerong iyon ay mula sa kanila, sa sarili nilang measurement at benchmark, hindi sa amin at hindi rin pangkalahatang resulta. Kung tatanggapin natin ang mga ito nang ganoon mismo, nakaaaliw ang konklusyon: ang 51 milliseconds sa bawat isa sa 40 agent call ay humigit-kumulang dalawang segundo lamang na nadadagdag sa isang task na tumatakbo nang ilang minuto.

Hindi ang dalawang segundo ang nagpapamahal sa routing dito. Ang overhead na talagang nakaaapekto ay isang router na nagka-classify gamit ang full model call, dahil isa itong karagdagang inference sa bawat request, at bina-bill at ipinapila gaya ng iba pang request. Sa ilalim ng dalawang ito ay ang cache arithmetic sa itaas, na hindi naman overhead. Ito ang cost ng mismong bagay na dapat sana ay ino-optimize ng routing.

Sa server na ikaw mismo ang nagpapatakbo, pareho ang tuntunin pero mas kaunti ang puwedeng pag-adjust. Ang local equivalent ng prompt cache ay prefix caching sa KV cache, na nasa GPU memory. Kapag nag-host ka ng dalawang model sa isang GPU, hinahati ang memory sa pagitan ng mga ito. Dahil dito, mas maliit ang KV cache na napapanatili ng bawat model at mas maagang nadi-discard ang mga prefix. Kaya maaaring bumaba nang sabay ang cache hit rate ng dalawang local model kapag nagra-route sa pagitan ng mga ito. Kung nagso-size ka ng hardware para rito, mas kapaki-pakinabang na simulan sa memory at CPU na aktuwal na kailangan ng coding agent sa isang VPS kaysa sa router.

Ang tuntunin sa pagpapasya

• Mag-route sa iba't ibang provider para sa availability. Kapag ang alternatibo ay isang failed request, tamang gastos ang anumang halagang kailangan. I-pin ang fallback sa model na gumagamit ng parehong tool call format upang magpatuloy ang loop ng agent, at i-log kung aling model ang nagsilbi sa bawat call.
• Mag-route sa iba't ibang tier para sa gastos, at sa hangganan lang ng task. Ang pagpili ng Haiku para sa rename at Opus para sa refactor ay magandang desisyon kung gagawin nang isang beses bago magsimula ang session. Masamang desisyon ito kung gagawin sa turn thirty ng session na iyon.
• Mag-pin ng isang model bawat session para sa anumang agentic na gawain. Ang halaga ng session ay nasa warm cache nito. Ituring ang pagpapalit ng model na parang pag-clear sa cache, dahil iyon mismo ang ginagawa nito.
• Malaya mong i-route ang mga subagent. Ang subagent na nagsisimula gamit ang bago at maliit na context ay walang warm cache na mawawala, kaya maaari itong gumamit ng model na angkop sa gawain nito. Ito ang tanging bahagi sa loob ng isang agent kung saan halos walang gastos ang routing.

Para mabuo ito, ang gateway ang gumagawa ng trabaho: model aliases at mga tahasang fallback list. Ganito ang isang minimal na 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

Ituro ang agent sa agent-primary at mananatili ito sa isang model hanggang sa hindi na maabot ang model na iyon. Parehong nasa iisang provider ang dalawang entry, kaya hindi nagbabago ang tool call format kapag nag-trigger ang fallback. Tumatanggap ka pa rin ng pagbabago ng tier sa sandaling iyon, ngunit sulit lang ang trade-off na ito dahil ang alternatibo ay isang failed request. Availability routing ito na walang kalakip na cost routing, at ito ang kombinasyong pinakanaaangkop sa karamihan ng coding agent. Saklaw ng pagpapatakbo ng self-hosted LiteLLM gateway sa sarili mong VPS ang buong setup, kasama ang mga key at budget, kaya sadyang hindi na ito inuulit ng post na ito.

Kapag mas mahusay ang isang maingat na napiling model kaysa sa kahit anong router

Ang routing ay solusyon sa pagkakaiba-iba ng hirap ng mga request. Mas maliit ang pagkakaibang ito sa coding agent kaysa sa inaakala, dahil pareho ang magastos na bahagi ng bawat call: ang prefix, anuman ang hinihingi ng call. Kapag nangingibabaw ang prefix, lumiliit ang pagkakaiba ng mura at mahal mong tier hanggang sa halos katumbas na lamang ito ng pagkakaiba sa presyo ng output. Maliit na bahagi lamang ng mga token ng agent ang output.

Kaya ang praktikal na default ay isang model na minsang pinili, naka-enable ang caching, at sapat ang haba ng TTL (time to live) para saklawin ang mga pagitan kapag humihinto ka upang magbasa ng diff. Nag-aalok ang Anthropic ng one hour cache write sa 2 times base input. Nababayaran nito ang sarili nito pagkatapos ng dalawang pagbasa. Madalas, mas mabisa itong hakbang kaysa sa kahit anong router. Piliin nang maingat ang tier gamit ang direktang paghahambing ng Opus, Sonnet at Haiku. Kung bill pa rin ang problema, bawasan ito gamit ang budgets at mas maliliit na context gaya ng nasa pagkontrol sa gastos ng AI agent sa isang VPS, sa halip na magpalit ng model sa kalagitnaan ng session.

Gumamit ng routing kapag magkakahiwalay at maiikli ang mga request, o kapag nagsisimula ang mga subagent sa mga bagong context. I-pin ang model kapag iisang mahabang session ang gumagawa ng iisang trabaho. Karamihan sa trabaho ng coding agent ay ganitong uri. Dahil dito, ang router na nakakatipid sa iyong chat product ay maaaring tahimik na magdagdag ng gastos dito. Kung hindi mo pa napipili ang agent mismo, ipinapaliwanag sa paghahambing ng Claude Code, Cursor, Codex at Copilot kung paano pinipili ng bawat isa ang model. May ilan din na sila na ang gumagawa ng desisyong ito.

FAQ

Talaga bang nawawala ang prompt cache kapag nagpapalit ng model sa kalagitnaan ng session?

Oo. Ang prompt cache ay naka-key sa hash ng prompt prefix at naka-store bawat model, kaya kapag ipinadala ang request sa ibang model, nagha-hash ito laban sa store na hindi pa kailanman nakakita ng prefix na iyon. Walang nahahanap na entry, kaya babayaran ang buong uncached input price. Kung naka-enable ang caching, may dagdag ding bayad para sa cache write. Hindi rin maibabalik ang orihinal na entry kapag bumalik sa dating model, dahil karaniwang expired na ang default na five minute lifetime. Suriin ang cache_read_input_tokens at cache_creation_input_tokens fields sa response usage object. Ang turn na nagbabasa ng zero cached tokens sa mahabang session ang sintomas nito.

Mas mura ba minsan para sa isang agent ang pag-route sa mas murang model?

Oo, pero kapag walang warm cache na mawawala. Sa Anthropic, ang cache read ay nagkakahalaga ng 0.1 beses ng base input, kaya mas mababa ang halaga ng warm read sa Opus 5 kaysa sa uncached input rate sa Haiku 4.5. Kapag malaki na ang cached prefix ng session, ang kasalukuyang model na ang mas murang opsyon para sa input. Nagiging sulit ang pag-route kapag bago at maliit ang context: sa simula ng task o sa isang subagent na dala lamang ang kinakailangang context.

Bakit nag-iba ang behavior ng agent ko sa kalagitnaan ng task?

Suriin kung nag-trigger ang gateway ng fallback. Kapag nagkaroon ng rate limit o 5xx sa primary model, magre-retry ang gateway gamit ang standby model at ilalagay ang primary sa cooldown nang ilang segundo. Dahil dito, sa ibang model na tatakbo ang natitirang bahagi ng task. Walang error o warning na lalabas, at magre-report pa rin ng success ang task. Ang model field sa gateway request log o response metadata ang tanging maaasahang record. Kaya i-log ito sa bawat request kung gumagamit ka man ng fallbacks.

Pareho ba ang paggana ng tool calls sa lahat ng provider?

Hindi eksakto. Gumagamit ang Anthropic's Messages API ng tool_use at tool_result content blocks, samantalang gumagamit ang OpenAI-compatible APIs ng tool_calls array kung saan ang function.arguments ay isang JSON-encoded string. Maayos na naita-translate ng gateway ang mga karaniwang kaso, pero nagkakaiba ang parallel tool calls at strict schema enforcement depende sa provider. Sa self-hosted vLLM, kailangan mong i-set ang --enable-auto-tool-choice at ang --tool-call-parser na tugma sa model family mo. Ayon sa vLLM documentation, kapag walang strict schema constraint, kumukuha ang server ng tool calls mula sa raw text, kaya maaaring paminsan-minsang malformed ang arguments.

Gaano katagal dapat ang cache TTL para sa coding session?

Gamitin ang default na five minute lifetime para sa tuloy-tuloy na trabaho, at ang one hour option kapag nagbabasa ang tao ng diffs sa pagitan ng mga turn. Sa Anthropic, ang five minute write ay nagkakahalaga ng 1.25 beses ng base input, at ang one hour write ay 2 beses. Samantala, 0.1 beses ang halaga ng read. Nababayaran ng isang read ang five minute write, at ng dalawang read ang one hour write. Kaya sa session na inaasahan mong babalikan at ipagpapatuloy, karaniwang mas mura ang mas mahabang lifetime kaysa paulit-ulit na pagbabayad para sa cold prefix.