Naukowcy z kilku ośrodków badawczych opublikowali 13 lipca 2026 roku framework Agent-as-a-Router oraz jego konkretną implementację — ACRouter. To otwartoźródłowy system routowania modeli AI, który zamiast statycznej klasyfikacji promptów uczy się na bieżąco z historii wykonań, dynamicznie dobierając najtańszy model zdolny do rozwiązania danego zadania. W benchmarkach ACRouter osiągnął koszt 13,21 USD na pełnym zestawie testowym, wobec 34,02 USD przy strategii zawsze używaj Opus — oszczędność rzędu 2,6x bez pogorszenia jakości.
Najważniejsze w skrócie
- ACRouter kosztował 13,21 USD na pełnym zestawie testowym wobec 34,02 USD dla strategii Opus-only — 2,6x oszczędności
- Pętla C-A-F (Context-Action-Feedback) zastępuje statyczne klasyfikatory — router uczy się na wynikach każdego wykonania
- Orchestrator oparty na Qwen 3.5 (0,8B parametrów) — lekki, możliwy do samohostowania
- Testowany na ~10 000 zadaniach z 8 modelami (Claude Opus 4.6, GPT-5.4, Qwen3-Max, GLM-5 i inne)
- Kod i wagi routera dostępne na GitHubie i Hugging Face na licencji Apache 2.0
Problem routowania modeli AI
W środowiskach produkcyjnych AI żaden model nie dominuje we wszystkich kategoriach zadań. Inżynierowie od dawna próbują mapować zadania do tańszych modeli otwartych tam, gdzie jest to możliwe, rezerwując drogie modele frontier dla złożonego wnioskowania. W praktyce stosuje się dwa podejścia: reguły heurystyczne (jeśli prompt zawiera dane słowa kluczowe, trafi do modelu X) oraz statyczne klasyfikatory trenowane na historycznych danych.
Oba mają wspólną wadę: są statyczne. Gdy zmienia się dystrybucja zadań lub do oferty wchodzi nowy model, klasyfikator nie wie, że stary routing jest już nieoptymalny. Zespół badaczy nazwał to deficytem informacyjnym — router ocenia wyłącznie prompt, nigdy nie widząc, czy model rzeczywiście wykonał zadanie poprawnie.
Agent-as-a-Router: pętla C-A-F
Framework Agent-as-a-Router rozwiązuje deficyt informacyjny przez pętlę C-A-F. Gdy napływa nowy prompt, router sprawdza historię podobnych zadań w pamięci wektorowej i na tej podstawie wybiera model. Po wykonaniu zadania system obserwuje wynik (kompilacja SQL się powiodła albo nie, kod przeszedł testy albo nie) i zapisuje ten feedback do pamięci. Następny podobny prompt trafi już do modelu, który w przeszłości poradził sobie z analogicznym zadaniem.
ACRouter, konkretna implementacja tego frameworku, składa się z trzech komponentów: Orchestratora (wybór modelu na podstawie pamięci), Verifier (ocena wyniku — sukces / porażka) i Memory (magazyn wektorowy). Warstwa narzędziowa podpina Verifier do realnego środowiska wykonawczego — interpretera Pythona, bazy danych lub sandboxa agentycznego — dzięki czemu sygnał zwrotny pochodzi z faktycznego wykonania, nie z oceny LLM.
Sam Orchestrator to lekki model Qwen 3.5 z 0,8 miliarda parametrów, dostrajany za pomocą adaptera LoRA?LoRA: Low-Rank Adaptation — tania metoda dostrajania modelu, w której trenuje się małe dodatkowe macierze zamiast wszystkich wag.. Może działać lokalnie, bez konieczności przesyłania promptów do chmury. To celowy wybór projektantów: ciężki model w roli routera zabiłby ekonomikę całego rozwiązania.
Benchmarki: żaden model nie dominuje
Badacze zbudowali CodeRouterBench — zestaw ~10 000 zadań ze zweryfikowanymi wynikami dla 8 modeli frontier. Wyniki bazowe pokazują skalę problemu: Claude Opus 4.6 osiąga najwyższą średnią wydajność, ale w projektowaniu algorytmów przegrywa z GLM-5 (o 86% w wydajności relatywnej), a w generowaniu testów z Qwen3-Max (o 111%). Opus kosztuje jednocześnie około 12 razy więcej niż tańsze modele jak Kimi-K2.5.
| Model | Mocna strona |
|---|---|
| Claude Opus 4.6 | najwyższa średnia wydajność |
| GLM-5 | projektowanie algorytmów (+86% vs Opus) |
| Qwen3-Max | generowanie testów (+111% vs Opus) |
| Kimi-K2.5 | najniższy koszt (~12× taniej niż Opus) |
ACRouter konsekwentnie osiągał niższy skumulowany żal?Skumulowany żal (cumulative regret): Miara łącznej straty względem zawsze najlepszego wyboru — im niższa, tym częściej router trafiał w optymalny model. (cumulative regret) niż statyczne routery i strategia Opus-only — zarówno na zadaniach in-distribution, jak i na trudniejszych zadaniach agentycznych (OOD), wymagających wieloetapowego planowania i debugowania. Na zbiorze in-distribution ACRouter kosztował 13,21 USD wobec 34,02 USD dla Opus-only. Na zbiorze OOD przewaga była podobna — przy lepszej skuteczności niż statyczne routery.
Kiedy ACRouter nie ma sensu
Badacze wprost wskazują ograniczenia własnego systemu. Framework świetnie sprawdza się w zadaniach weryfikowalnych — kod, SQL, zapytania do baz danych — gdzie Verifier dostaje jednoznaczny sygnał. Dla zadań subiektywnych, jak pisanie kreatywne czy ocena stylu, sygnał zwrotny jest niemożliwy do standaryzacji. ACRouter to również nadmiar inżynierski dla prostych aplikacji z małą liczbą zapytań, gdzie różnica kosztów będzie nieistotna.
Dlaczego to ważne?
Model routing staje się krytyczną warstwą stosu enterprise AI. Gdy firmy jednocześnie operują na kilku modelach — otwartych, zamkniętych, specjalizowanych — decyzja o tym, który model obsługuje dane zapytanie, bezpośrednio wpływa na marże i latencję.
Dotychczasowe routery były ślepe na wyniki: wybierały model na wejściu, nigdy nie ucząc się na wyjściu. ACRouter wprowadza mechanizm zbliżony do uczenia przez wzmacnianie na poziomie routera — ale bez kosztownego trenowania polityki od zera. Każda sesja produkcyjna jest jednocześnie generatorem danych treningowych.
Dla praktyków AI to zmiana jakościowa: infrastruktura modeli przestaje być statyczną konfiguracją, a staje się systemem samodoskonalącym. Wagi routera są dostępne publicznie, co umożliwia dostosowanie do własnego środowiska bez płacenia za API routera zewnętrznego dostawcy.
Co dalej?
- Kod i wagi modelu Orchestrator są dostępne na GitHubie (https://github.com/LanceZPF/agent-as-a-router) oraz Hugging Face na licencji Apache 2.0 — można je zaadaptować do własnego zestawu modeli
- Benchmark CodeRouterBench obejmuje ~10 000 zadań z 8 modelami — badacze planują rozszerzenie o nowe kategorie zadań agentycznych
- Integracja z Claude Code, Codex i OpenCode jest już wspierana przez warstwę narzędziową frameworku
