Problema abordării „ia GPT-4 și gata"
Majoritatea platformelor de inteligență artificială iau o decizie tăcută în locul tău: aleg un model care le convine, leagă totul de el și merg mai departe. Asta merge până când nu mai merge — până când modelul cade, până când un concurent scoate ceva mai bun pentru o sarcină anume, până când vrei să-ți aduci propria cheie API și să ții costul pe contul tău, până când ai nevoie să generezi imagini iar modelul implicit nu știe.
Leacul obișnuit este o listă derulantă. Alege un model, folosește-l peste tot, descurcă-te singur cu compromisurile. Asta nu e direcționare, e delegare. ToRun face ceva structural diferit.
Lanțul care pune capabilitățile pe primul loc
Fiecare cerere în ToRun trece prin patru etape înainte să atingă un model.
1. Modul stabilește suprafața de produs. Când deschizi o sesiune de Conversație sau pornești o sarcină de Cercetare, alegi un Mod. Modul nu e doar o etichetă de interfață: poartă un set definit de capabilități obligatorii și opționale. O sarcină de Cercetare are nevoie de unelte (căutare web), context lung și ieșire structurată. O sesiune obișnuită de conversație are nevoie implicit doar de generare de text.
2. Setul de capabilități devine filtru. ToRun ține un catalog de modele de la mulți furnizori — OpenAI, Anthropic/Claude, Google/Gemini, DeepSeek, xAI/Grok, Mistral și alții. Fiecare intrare poartă reuniunea capabilităților pe care modelul le acceptă cu adevărat: vedere, unelte, executarea codului, generare de imagini, sunet la intrare, sunet la ieșire, generare video, încorporări, reordonare, transmisie în timp real, raționament și altele. Setul din primul pas se compară cu acest catalog. Modelele care nu îndeplinesc toate capabilitățile obligatorii cad.
3. Clasarea preț-calitate alege câștigătorul. Dintre modelele care trec filtrul, ToRun ordonează după ceea ce este cererea de fapt. O întrebare scurtă și simplă se ordonează după cost, deci primești un răspuns rapid și ieftin. Una mai lungă sau mai grea se ordonează după capabilitate pe unitate de cost, față de un prag de calitate. O tură care poartă o imagine se ordonează după cât de bine vede modelul, nu după raționament pe leu. Executanții de fluxuri trec pe prioritatea calității, fiindcă un lanț automatizat care rulează nesupravegheat ar trebui să țintească cel mai bun rezultat, nu cea mai ieftină scurtătură. Utilizatorii BYOK intră altfel în tarifare, fiindcă cererea trece prin propriul lor cont la furnizor.
4. Lanțurile de rezervă absorb defectele furnizorului. Dacă modelul ales întoarce o eroare de serviciu, același lanț rulează din nou cu acel model exclus. Răspunde al doilea cel mai bun model apt. Nu vezi nicio eroare, decât dacă toți candidații viabili sunt scoși din funcțiune.
Un exemplu concret: vedere plus unelte
Să zicem că lipești o captură de ecran și îi ceri lui ToRun să caute pe web context despre ce arată. Această cerere atinge două capabilități deodată: vedere (modelul trebuie să accepte o imagine la intrare) și unelte (modelul trebuie să poată chema o funcție de căutare web).
Cu o abordare cu un singur model rămâi blocat: platforma ta acceptă acea combinație sau nu. Cu direcționare după capabilități, ToRun intersectează ambele cerințe. Filtrul îl trec doar modelele cu sprijin confirmat atât pentru vedere CÂT ȘI pentru chemarea uneltelor. Din acea listă scurtă, clasarea după preț și calitate alege pe cel mai bun pentru modul tău curent. Dacă principalul candidat este limitat sau scos din funcțiune, următorul servește cererea fără ca tu să faci nimic.
În practică asta contează: mulțimea modelelor cu vedere s-a schimbat mult în ultimul an și va continua să se schimbe. Direcționarea după capabilități face ca ToRun să ia automat în seamă modelele nou adăugate imediat ce intră în catalog, fără nicio actualizare din partea ta.
De ce câștigă asta față de legare
O platformă cu un singur model are o singură strategie de rezervă: să aștepte ca furnizorul să repare defectul. O platformă care pune capabilitățile pe primul loc are un catalog. Când OpenAI are un incident, cererile pe care le pot servi Anthropic sau Gemini sunt servite acolo. Când un model nou Mistral oferă un raport preț-calitate mai bun la ieșire structurată, intră în clasarea modurilor relevante fără migrare forțată.
Aceeași logică se aplică la BYOK. Când adaugi propria cheie API pentru un furnizor, acele date de acces rămân închise în stratul de direcționare. Cererile care se potrivesc modelelor apte ale acelui furnizor pot folosi cheia ta în loc de contul ToRun, mutând costul în relația ta cu furnizorul la nivelul de facturare potrivit. Lanțul de direcționare nu se schimbă: se schimbă doar ce date de acces se folosesc în momentul execuției.
Compromisul este cinstea: ToRun nu poate garanta că modelul cel mai ieftin va fi cel mai deștept pentru sarcina ta. Clasarea este la vedere — vezi ce s-a ales și de ce, și poți trece peste. Această transparență este scopul. Fiecare cerere scrie o înregistrare de facturare cu modelul folosit, unitatea de tarifare activă la execuție și defalcarea costului. Poți verifica orice apel și luni mai târziu, chiar după schimbări de tarife la furnizor, fiindcă instantaneul este înghețat în momentul în care cererea a rulat.
Un model care face totul este o ficțiune comodă. Ce vrei de fapt este o platformă care găsește modelul potrivit pentru fiecare sarcină și face această alegere lizibilă.