Majoritatea echipelor apelează un furnizor de modele direct din codul aplicației. Cheia API stă într-o variabilă de mediu, apelul SDK are trei rânduri și funcționează din prima. Cloudflare AI Gateway există din cauza a ceea ce se întâmplă mai departe. Vine factura și nimeni nu poate spune ce funcționalitate a provocat-o. Furnizorul are o după-amiază proastă și îți trage produsul după el. Un prompt de sistem este modificat și nu rămâne nicio urmă despre ce returna cel vechi.
Un gateway este un proxy între aplicația ta și furnizor. Fiecare cerere trece prin el, deci fiecare cerere poate fi numărată, jurnalizată, pusă în cache, limitată ca rată și, când furnizorul cade, reîncercată în altă parte. Este cea mai ieftină corecție structurală pentru trei probleme care altfel se rezolvă târziu și de mână.
Urmează ce face, ce impune spre deosebire de ce doar observă, cât costă în bani și în milisecunde și unde stau limitele oneste.
Chiar economisești punând un gateway în fața API-ului tău de model? Nu direct. Nucleul Cloudflare AI Gateway este gratuit pe toate planurile și nu adaugă niciun adaos peste inferență, deci economia vine din ce îți arată, nu din ce blochează. Atribuirea costurilor pe funcționalitate îți spune ce parte a produsului este scumpă, cache-ul elimină apelurile identice repetate acolo unde este sigur, iar rutarea de rezervă împiedică o pană a furnizorului să devină pana ta. Plafonarea bugetului există, dar ce se întâmplă când bugetul se termină este o decizie de produs, nu una de configurare.
Cele trei întrebări la care un apel direct către model nu poate răspunde
Orice argument pentru un gateway se reduce la una dintre cele trei întrebări pe care un apel SDK direct le lasă fără răspuns. Varianta abstractă, vizibilitate și control, nu convinge pe nimeni care trebuie să justifice munca.
Nimeni nu poate atribui factura
Facturarea pe token depinde de consum, iar facturile furnizorilor agregă. Primești un total lunar pe cheie API, nu un total pe funcționalitate. Dacă un rezumator, un asistent conversațional și o sarcină nocturnă de clasificare împart o cheie, factura nu poate spune care dintre ele s-a triplat. Răspunsul obișnuit este o cheie pentru fiecare funcționalitate, ceea ce merge până ai unsprezece funcționalități și o politică de rotație.
Nimeni nu poate reproduce eșecul
Când un apel eșuează în codul aplicației, supraviețuiește doar ce a prins jurnalul tău, de obicei un cod de stare și un mesaj trunchiat. Rar promptul exact, versiunea de model care a răspuns sau latența la care a renunțat. Reproducerea unui incident o zi mai târziu devine ghicitoare despre intrări. Între timp, o pană a furnizorului se propagă direct până la utilizatorii tăi.
Nimic nu plafonează o buclă scăpată de sub control
Un agent care se reîncearcă singur, un consumator de coadă care relivrează la eroare sau o buclă a cărei condiție de oprire un model o judecă mereu neîndeplinită: fiecare poate genera mii de apeluri înainte ca cineva să observe. Fără ceva pe traseu care să numere, primul semnal este factura. Limitele pe utilizator și opririle ferme nu există câtă vreme nicio componentă de pe traseu nu le impune, iar codul aplicației este un loc prost pentru ele, fiindcă fiecare punct de apel trebuie să își amintească.
Ce este Cloudflare AI Gateway și unde stă pe traseul cererii
Prezentarea generală a AI Gateway de la Cloudflare descrie un serviciu așezat între aplicația ta și furnizorii de modele de IA, ca să poți monitoriza consumul și să gestionezi felul în care aplicația scalează. Funcțiile sunt analiza, jurnalizarea, cache-ul, limitarea ratei și reîncercarea cu rezervă, pe toate planurile Cloudflare. Cloudflare susține că este nevoie de o singură linie de cod ca să începi, iar forma integrării explică de ce asta este aproape adevărat.
Integrarea înseamnă schimbarea URL-ului de bază
În loc să îndrepți SDK-ul către furnizor, îl îndrepți către o adresă de gateway care poartă identificatorul contului, identificatorul gateway-ului și numele furnizorului. Cloudflare documentează forma OpenAI ca https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}/openai, dată drept baseURL la construirea clientului. Numele modelelor, parametrii, streamingul și analiza răspunsului rămân cum erau. Lista de furnizori a Cloudflare acoperă două duzini de servicii după același tipar, printre care OpenAI, Anthropic, Google Vertex AI, Amazon Bedrock, Azure OpenAI, Mistral, Groq, DeepSeek, xAI și propriul Workers AI al Cloudflare.
Ce presupune această formă
Adoptarea este cu adevărat ieftină: o valoare de configurare pe serviciu, reversibilă prin readucerea ei la starea inițială, ceea ce face din asta una dintre puținele schimbări de infrastructură pe care le poți încerca fără un plan de proiect.
Cheia ta de furnizor trece acum prin Cloudflare, fiindcă proxy-ul trebuie să o transmită mai departe, dacă nu treci la chei stocate sau la credențiale gestionate de Cloudflare. Aceasta este o decizie de încredere, nu un detaliu.
Și tot ce se oferă este mărginit de ce poate vedea un proxy. El vede cereri și răspunsuri, nu intenția aplicației tale, motiv pentru care atribuirea cere să etichetezi tu cererile, în loc să aștepți ca gateway-ul să ghicească la ce servea un apel.
Analiza și jurnalizarea sunt funcțiile care economisesc banii
Gateway-ul numără fiecare cerere. Documentația despre jurnalizare a Cloudflare enumeră ce ține o intrare: promptul utilizatorului, răspunsul modelului, furnizorul, momentul, starea cererii, consumul de tokenuri, costul, durata și agentul de utilizator al clientului. Pe cerere, nu pe lună, și interogabil.
Fii direct despre motivul pentru care banii stau aici, și nu în funcțiile de impunere. Blocarea cheltuielii economisește costul apelurilor pe care le-ai oprit, ceea ce este mărginit. Să știi unde se duce cheltuiala schimbă ce construiești, ceea ce nu este.
Atribuirea nu se face automat. Metadatele personalizate atașează etichetele tale, de pildă numele funcționalității sau al clientului, ca analiza să poată grupa după ele. Sari peste asta și obții un total, adică fix ce îți dădea deja factura.
Cache-ul și cazurile în care un hit strică produsul
Cache-ul este funcția pornită cel mai des din motivul greșit și cea mai capabilă să strice un produs în tăcere.
Cum se construiește cheia de cache
Documentația despre cache a Cloudflare explică cheia drept un hash SHA-256 al furnizorului, al punctului final, al modelului, al antetului de autentificare și al corpului complet al cererii. O potrivire exactă pe tot este un hit, orice altceva este un miss. Deci un hit cere o cerere identică la nivel de octet, ceea ce este rar după prima tură pe un punct final conversațional care poartă istoric acumulat. Durata minimă de viață este de 60 de secunde, iar cea maximă de o lună. Controlul pe cerere vine din cf-aig-cache-ttl, cf-aig-skip-cache și cf-aig-cache-key, în timp ce cf-aig-cache-status returnează HIT sau MISS ca să poți măsura rata reală.
Când un hit este sigur și când nu este
Un hit este sigur acolo unde intrări identice trebuie să producă ieșiri identice și unde un răspuns mai vechi este acceptabil: clasificare, extragere structurată, traducerea unor șiruri fixe, embeddings ale unor documente neschimbate, trafic de evaluare. Este nesigur oriunde valoarea produsului depinde de variație. Dacă doi utilizatori pun aceeași întrebare și al doilea primește un răspuns generat pentru primul, setarea ta de temperatură este decorativă.
Eșecul mai grav ține de confidențialitate. Dacă în corpul cererii nu se află nimic care să distingă utilizatorii, un răspuns din cache poate trece granița dintre doi utilizatori, ceea ce este o divulgare și nu o problemă de calitate. Cache-ul acoperă, în plus, doar răspunsuri de tip text și imagine.
Limitarea ratei, reîncercările și rutarea de rezervă
Aceste trei lucruri sunt descrise împreună ca funcții de fiabilitate. Doar unul dintre ele constrânge cu adevărat costul.
Limitarea ratei plafonează cererile, nu tokenurile
Cloudflare oferă o fereastră fixă și una glisantă, iar cererile peste limită primesc un 429. Observă ce se numără: cererile. Un singur apel care poartă un context foarte mare costă mult mai mult decât unul scurt, iar limitatorul nu le poate deosebi. Limitarea ratei te apără de o buclă scăpată de sub control și de un punct final abuzat, nu de un prompt scump, iar a o trata drept control al costurilor este greșeala obișnuită.
Reîncercări și expirări
Anteturile de tratare a cererii de la Cloudflare permit până la 5 încercări cu cf-aig-max-attempts, o întârziere de până la 5000 de milisecunde cu cf-aig-retry-delay și o strategie constantă, liniară sau exponențială cu cf-aig-backoff. Antetul cf-aig-request-timeout se măsoară din clipa în care sosește prima parte a răspunsului, deci pe un apel cu streaming este o limită pentru timpul până la primul octet și nu pentru durata totală. La ultima încercare, gateway-ul așteaptă până se încheie cererea, oricât ar dura.
Rutarea de rezervă și-a schimbat forma
Universal Endpoint, care primea un vector de obiecte furnizor și îl parcurgea la eroare, este depreciat. Cloudflare îndrumă acum integrările noi către punctul final compatibil cu OpenAI și către Dynamic Routing pentru rezerve, reîncercări și rutare condiționată. O rută dinamică este un flux numit și versionat, construit vizual sau ca JSON, făcut din noduri de model, noduri condiționale care se ramifică după corpul cererii, anteturi sau metadate, noduri procentuale pentru teste A/B și noduri de limită de rată și de buget care deviază spre o rezervă la depășire. O invoci punând numele rutei acolo unde ar sta numele modelului.
Inspectarea a ce intră și a ce se întoarce
Fiindcă proxy-ul ține ambele jumătăți ale schimbului, le poate evalua. Guardrails de la Cloudflare interceptează prompturile utilizatorilor și răspunsurile modelelor, marchează conținutul pentru verificare sau îi blochează trecerea și aplică o singură politică indiferent de furnizorul care a răspuns.
Argumentul pentru politică pe traseu, și nu în cod, este că moderarea la nivel de aplicație trebuie scrisă o dată pentru fiecare punct de apel, iar punctul de apel adăugat săptămâna trecută este cel care o ratează. Prețul este că inspecția este ea însăși inferență: Guardrails se facturează ca utilizare Workers AI pe tokenuri, deci prețul crește cu lungimea a ceea ce inspectezi. Scanarea pentru prevenirea pierderii de date este gratuită pe toate planurile.
Ce s-a schimbat în timpul Agents Week din august 2026
Cloudflare a ținut prima sa Agents Week între 3 și 7 august 2026, iar în ultima zi a publicat unificarea Workers AI și AI Gateway într-un singur plan de control. Separă ce a fost livrat de ce a fost anunțat.
Ce a fost livrat: un singur binding de IA în loc de două, așa că env.AI.run() acoperă atât modelele Workers AI, cât și furnizorii externi. Rutarea prin gateway a devenit comportamentul implicit pentru Workers AI, nu o opțiune, iar gateway: { id: 'default' } creează gateway-ul la prima folosire și aduce jurnalizarea cererilor, urmărirea tokenurilor și atribuirea costurilor fără nicio altă modificare. Creditele au devenit cheltuibile între furnizori, deci Workers AI se plătește din același sold preplătit ca OpenAI sau Anthropic.
Ce nu a fost livrat: rutarea pornind de la model, în care ceri un model și platforma alege furnizorul, urmează abia de acum și nu este disponibilă, iar un router inteligent care clasifică prompturile rămâne un pilot intern. Este o consolidare a facturării, a bindingurilor și a tablourilor de bord, nu o capacitate nouă. Dacă apelai deja Workers AI la marginea rețelei fără gateway, primești acum observabilitate în mod implicit.
Cât costă Cloudflare AI Gateway
Pagina de prețuri a AI Gateway de la Cloudflare spune că funcțiile de bază disponibile astăzi sunt oferite gratuit, ceea ce acoperă analiza din tabloul de bord, cache-ul și limitarea ratei pe toate planurile. Toate cifrele de mai jos sunt prețurile publicate de Cloudflare în dolari americani, citate în moneda în care Cloudflare le publică.
Unde apar de fapt costurile
Jurnalele persistente sunt gratuite, dar plafonate în funcție de plan: 100.000 de jurnale pe toate gateway-urile pe Workers Free și 10 milioane pe gateway pe Workers Paid. Logpush, care exportă acele jurnale în altă parte, este o funcție a planului Paid, cu 10 milioane pe lună și 0,05 USD pentru fiecare milion suplimentar. Workers AI însuși, conform paginii sale de prețuri, include 10.000 de neurons pe zi fără cost și taxează 0,011 USD la fiecare 1.000 de neurons peste acest prag pe planul Paid, un neuron fiind unitatea Cloudflare pentru calcul pe GPU.
Facturarea unificată costă 5 la sută
Dacă folosești credențiale gestionate de Cloudflare în loc de propriile chei de furnizor, cumpărarea de credit poartă un comision de 5 la sută. Exemplul dat chiar de Cloudflare este un credit de 100 USD facturat la 105 USD. Inferența este transmisă mai departe fără adaos. Dacă îți aduci propria cheie, facturarea unificată nu se aplică, fiindcă o cerere care poartă autentificarea furnizorului sau o cheie stocată o ocolește.
Controlul costurilor făcut cum trebuie
Un gateway impune în mod fiabil trei lucruri: o rată a cererilor, o limită de buget în interiorul unei rute dinamice și dacă o cerere este servită din cache. Tot restul a ceea ce face ține de măsurare. Confundarea celor două categorii explică de ce echipele instalează unul, bifează fiecare căsuță și rămân totuși surprinse de factură.
Un plafon ferm de buget este o decizie de afaceri înainte să fie o configurare. Ceva trebuie să se întâmple când plafonul este atins, iar fiecare opțiune este rea în felul ei. Să lași cererea să eșueze înrăutățește produsul pentru cel care a cerut ultimul și arată ca un defect. Retragerea către un model mai ieftin înrăutățește calitatea în tăcere. Punerea la coadă transformă o problemă de cost într-una de latență. Alegerea dintre aceste opțiuni este munca propriu-zisă.
Economia care ajunge pe o factură vine de obicei din observabilitate, nu din impunere. Odată ce cheltuiala se grupează pe funcționalitate, lucrul scump este aproape mereu reparabil fără a schimba modelul: un prompt de sistem supradimensionat trimis la fiecare tură, un istoric complet al conversației retrimis acolo unde ar ajunge un rezumat glisant, o buclă de reîncercare care insistă pe o eroare ce nu avea cum să reușească. Un jurnal le găsește pe toate. Un limitator de rată nu găsește niciuna.
Latența pe care o adaugi
Un salt în plus nu este gratuit, iar a pretinde altceva este felul în care o decizie bună se ia dintr-un motiv prost. Cererea ta se termină acum într-un centru de date Cloudflare, este procesată acolo și trimisă mai departe către furnizor, ceea ce adaugă o strângere de mână TLS și un segment de rețea pe care înainte nu îl plăteai.
În cazul normal, asta este mic față de ceea ce învelește. O completare conversațională durează de la câteva sute de milisecunde la câteva secunde și este dominată de timpul de generare, iar gateway-ul stă în rețeaua edge a Cloudflare, deci primul segment se termină aproape de apelant. Față de o completare de două secunde, costul suplimentar este zgomot.
Unde încetează să fie zgomot este la apelurile scurte, ieftine și foarte numeroase. O cerere de embedding care se întoarce mult sub o zecime de secundă este un caz în care costul fix devine un procent vizibil. Streamingul este celălalt, fiindcă numărul pe care utilizatorii îl simt este timpul până la primul token, iar tot ce se adaugă înainte de acel token apasă pe metrica ce contează. Măsoară-l din durata pe care o jurnalizează gateway-ul, față de același apel făcut direct.
Strategia cu mai mulți furnizori și blocajul de care nu scapi
Argumentul de vânzare este că un gateway face furnizorii interschimbabili, iar la nivelul transportului asta este adevărat. Punctul final compatibil cu OpenAI îți dă o singură formă de cerere, rutarea dinamică îți dă comutare fără o desfășurare, iar schimbarea numelui unui model devine configurare, nu cod.
Nivelul transportului nu a fost niciodată partea scumpă. Schimbarea modelelor costă fiindcă modelele se comportă diferit. Un prompt de sistem șlefuit luni la rând pe un model produce alt rezultat pe altul. Formatele și fiabilitatea apelurilor de unelte diferă. Comportamentul de refuz diferă, deci conținut care trecea înainte este respins. Respectarea unei forme JSON cerute diferă, iar un parser scris după obiceiurile unui model se rupe la obiceiurile altuia. Ferestrele de context diferă.
Ce cumperi cu adevărat este ca o schimbare să devină o după-amiază de evaluare în loc de un sprint de instalații, și ca preluarea la pană să existe fără să o construiești tu. Merită avut, dar nu este portabilitate. O dependență de ordinul al doilea merită numită: gateway-ul stă acum pe traseul fiecărui apel de model, deci disponibilitatea lui devine disponibilitatea ta. Este același compromis pe care l-am analizat comparând Cloudflare Workers și AWS Lambda.
Jurnalizarea prompturilor înseamnă prelucrarea de date personale
Aceasta este secțiunea care se sare și cea care are expunere juridică atașată. Jurnalizarea este pornită implicit pentru fiecare gateway, iar o intrare conține integral promptul utilizatorului și răspunsul modelului. Dacă utilizatorii tăi scriu ceva despre ei, lipesc un document sau îi descriu asistentului tău o situație medicală ori financiară, acel conținut este dată personală într-un depozit de jurnale al unui terț, iar sub UK GDPR rămâi operatorul lui.
Anonimizează înainte să îți părăsească aplicația
Singurul loc de încredere în care poți scoate ceva este înainte de a fi trimis. Gateway-ul oferă cf-aig-collect-log-payload: false, ca să păstrezi metadatele renunțând la corpuri, și cf-aig-collect-log: false, ca să nu jurnalizezi nimic. Dar minimizarea datelor înseamnă să nu colectezi mai mult decât ai nevoie de la bun început, deci corecția durabilă stă mai sus: scoate numerele de cont, identificatorii și câmpurile de text liber de care modelul nu are nevoie înainte ca cererea să îți părăsească procesul.
Păstrarea este o decizie pe care trebuie să o iei
Ghidul ICO despre limitarea stocării nu fixează perioade. Cere să nu păstrezi datele personale mai mult decât ai nevoie, să poți justifica perioada aleasă, să ai o politică ce stabilește perioade standard și să revizuiești și apoi să ștergi sau să anonimizezi ce nu îți mai trebuie. Un depozit de jurnale cu un plafon dat de plan nu este o politică de păstrare, fiindcă un plafon este o limită de stocare și nu o perioadă justificată.
Alternativele, numite cinstit
Există trei alternative reale, iar alegerea ține mai ales de cine operează lucrul respectiv.
Un proxy LLM open source găzduit de tine îți dă același traseu al cererii, cu jurnalele pe infrastructură pe care o controlezi, ceea ce este potrivit când sensibilitatea prompturilor este ea însăși problema. Prețul este operarea unei componente pe traseul critic al fiecărui apel de model.
Un furnizor specializat în observabilitate pentru LLM merge mai adânc pe evaluare, versionarea prompturilor și inspecția urmelor. Dacă problema ta este că ieșirile sunt greșite, nu că sunt costurile opace, acela se potrivește mai bine, iar cele două nu se exclud.
Să îl construiești singur se justifică atunci când nevoia este îngustă. Un wrapper care scrie cererea, răspunsul, numărul de tokenuri și o etichetă de funcționalitate în stiva ta de observabilitate existentă înseamnă poate două zile de lucru și răspunde la întrebarea despre atribuire. Ce nu vei obține ieftin este cache-ul cu o cheie corectă și rezerva între furnizori.
Regula: dacă nimeni nu știe unde se duce cheltuiala, un gateway este cea mai rapidă corecție, iar planul gratuit o dovedește. Dacă prompturile nu au voie să îți părăsească infrastructura, găzduiește-l singur. Dacă ieșirile sunt greșite, niciun gateway nu ajută și îți trebuie unelte de evaluare.
Ce cere implementarea și ce întoarce
Pentru un singur serviciu care apelează deja un furnizor, o jumătate de zi. Creezi gateway-ul, schimbi URL-ul de bază în configurare, lansezi în spatele unui flag ca revenirea să fie o variabilă de mediu, nu o lansare nouă, privești jurnalele cum se umplu și confirmi că streamingul se poartă în continuare bine.
Pentru un produs adevărat, pune la socoteală între trei și cinci zile de inginer, iar cea mai mare parte nu este gateway-ul. Este stabilirea unei scheme de metadate, ca atribuirea să răspundă la întrebările pe care chiar le vei pune, verificarea fiecărui punct de apel, inclusiv a sarcinilor programate și a codului pe care nu l-a deschis nimeni de un an, aflarea punctelor finale care pot fi puse în cache în siguranță și scrierea pasului de anonimizare. Adaugă o zi pentru rutarea de rezervă, fiindcă o rezervă merită abia după ce ai testat că modelul de rezervă produce o ieșire acceptabilă.
Câștigul nu este spectaculos. Nu mai ești surprins de factură, ceea ce pentru majoritatea echipelor cântărește mai mult decât economia absolută. O pană a furnizorului devine un răspuns mai slab, nu un incident. Echipele care construiesc fluxuri de lucru cu agenți câștigă cel mai mult, fiindcă o acțiune a utilizatorului care se ramifică în zeci de apeluri de model este exact locul unde estimările se despart de realitate, un tipar pe care l-am tratat în cât costă agenții IA și unde eșuează.
Cum instalezi unul fără să strici producția
Secvența care funcționează este plictisitoare intenționat. Pune gateway-ul pe traseu cu jurnalizarea pornită și nimic altceva activat. Adună o săptămână de date. Citește atribuirea. Apoi activează exact funcțiile pe care datele le justifică și activează cache-ul ultimul, doar pe punctele finale unde poți explica de ce un răspuns repetat este un răspuns corect.
Mecanik construiește și operează acest strat ca parte a muncii noastre de integrare IA, iar serviciul nostru de integrare a API-ului OpenAI acoperă partea de furnizor. Colaborările încep aproape mereu la fel, cu o săptămână de jurnalizare și nicio altă modificare, fiindcă datele de atribuire reordonează de obicei lista de priorități.
Întrebări frecvente
Este Cloudflare AI Gateway gratuit? Funcțiile de bază sunt gratuite pe toate planurile, iar pagina de prețuri a Cloudflare le descrie drept analiza din tabloul de bord, cache și limitarea ratei, iar scanarea pentru prevenirea pierderii de date este și ea gratuită. Costurile apar pe margini: Logpush este o funcție a planului Paid, Guardrails se facturează drept inferență Workers AI pe tokenuri, iar spațiul pentru jurnale este plafonat în funcție de plan, nu tarifat pentru fiecare jurnal.
Adaugă un AI gateway latență la apelurile către model? Da, adaugă o strângere de mână TLS și un segment de rețea. Față de o completare conversațională care durează de la câteva sute de milisecunde la câteva secunde, acel cost suplimentar este de obicei neglijabil. Devine vizibil la apelurile scurte și foarte numeroase, precum embeddings sau clasificări mici, și la răspunsurile cu streaming, unde metrica simțită este timpul până la primul token, nu durata totală.
Când nu este sigur să pui în cache răspunsurile unui LLM? De fiecare dată când valoarea produsului depinde de variația dintre răspunsuri sau când corpul cererii nu deosebește un utilizator de altul. Cloudflare construiește cheia de cache din furnizor, punct final, model, antetul de autentificare și corpul complet, deci un hit înseamnă o cerere identică la nivel de octet. Cache-ul se potrivește clasificării, extragerii și embeddings, nu răspunsurilor conversaționale care ar trebui să difere de la un utilizator la altul.
Face un gateway ușoară schimbarea furnizorului de modele? La nivelul transportului, da. O singură formă de cerere, o singură schimbare de configurare și comutare fără o desfășurare. Partea scumpă a schimbării rămâne neatinsă: prompturile șlefuite pe un model se poartă altfel pe altul, formatele apelurilor de unelte și comportamentul de refuz diferă, respectarea formei JSON diferă, iar ferestrele de context diferă. Un gateway scoate instalațiile, nu munca de evaluare.
Ce a schimbat Cloudflare în august 2026? Pe 7 august 2026, la finalul Agents Week, Cloudflare a unificat Workers AI și AI Gateway într-un singur plan de control: un binding de IA care acoperă atât Workers AI, cât și furnizorii externi, rutare prin gateway pornită implicit pentru Workers AI și credite cheltuibile între furnizori dintr-un singur sold preplătit. Rutarea pornind de la model a fost anunțată ca pas următor, nu livrată.
Comentarii