Lo vedete questo uomo qui bellissimo in sovraimpressione? Bene, lui è il creatore di Chat CPT, si può dire, perché praticamente ha aiutato a trasformare l'algoritmo di GPT3 in effettivamente Chat GPT. Bene, da qualche giorno ha annunciato il rilascio ufficiale della sua startup che si chiama Typesafe AI e del suo nuovo modello di intelligenza artificiale che attenzione non è un LLM, si chiama Jeev o Ju, non so come si pronuncia, è praticamente un po' una svolta nell'ambito della dell'AI perché se noi siamo abituati ad usare l'LM lenti costosi che richiedono tanta capacità di elaborazione arriva questo nuovo modello che lavora tipo 400 volte più veloce e 200 volte più economico. modelli LLM di frontiera come Fable 5 e Astra, proprio perché non è un LLM, quindi funziona in modo diverso, ma è estremamente utile, specialmente per quanto riguarda le automazioni.

Perciò io, dato che ho accesso in anteprima questo modello, ho deciso di farci un video subito per mostrarvi in anticipo prima del rilascio ufficiale, cos'è, come funziona, come puoi utilizzarlo e come puoi implementarlo all'interno dei tuoi sistemi attuali per risparmiare una marea di euro. Se tutto andrà bene, alla fine di questo video tu avrai un quadro completo di questo modello, capirai effettivamente come puoi implementarlo nel tuo cloud code e nei sistemi che crei e che vendi ai tuoi clienti o che usi per te stesso e ti farò vedere con dei test live quanto si risparmia rispetto ad un normale LM come Gemini 3.8 flash.

Perciò riassunto finito, adesso andiamo al computer, ti faccio vedere la loro landing page, ti faccio vedere come descrivono il loro modello e poi passiamo subito ai test che ho fatto su diversi sistemi miei attuali. Quindi andiamo. I modelli AI sono stati superhuman per quanto riguarda le chat per anni, ma quindi dov'è tutta l'automazione? Con questa frase quelli di Typees AI iniziano la loro il loro manifesto, iniziano a parlare del loro nuovo modello e se scendiamo qui sotto vediamo che lo mettono a confronto con i normali LLM di frontiera.

Le principali differenze che possiamo vedere sono queste. Se gli LLM sono ottimizzati per scrivere risposte che gli umani vogliono leggere, questo nuovo modello opera secondo decisioni calibrate, ossia risponde con onestà in base alle probabilità che riesce ad estrarre dal contesto. Qui arriva invece la differenza forse principale, ossia che l'output dei normali ll è una stringa, un testo normale come quello che siamo abituati a leggere da Chat GPT, ad esempio.

Bene, al contrario Jeev, questo nuovo modello, risponde solamente secondo una struttura precisa preimpostata nell'input. Quindi, ad esempio, non va a scriverti un testo articolato, ma semplicemente ti risponde sì oppure no, dando un punteggio di probabilità a ciascuna delle risposte. Quindi, eh se tu gli chiedi il cielo è blu, lui ti risponde sì col 98% di probabilità, no, col 2% di probabilità, secondo il contesto su cui è stato trainato.

Ma tu all'interno di questa roba ci puoi mettere anche un contesto, quindi gli puoi dire il cielo è arancione e lui nella sua risposta quando gli chiederai il cielo è blu lui ti dirà sì con lo 2% di probabilità e no con il 98% di probabilità perché perché l'abbiamo istruito nella nella parte di contesto che il cielo è arancione. Questa roba adesso non ha alcun senso, ma vi prometto che negli esempi che vi faccio vedere tra poco tutto sarà chiaro e soprattutto capirete dove davvero ti torna utile questa roba.

Un'altra differenza abissale è il sampling, cioè gli LM scrivono in sequenza, un token dopo token, mentre questo nuovo modello scrive tutto in parallelo, quindi se deve dare una risposta o deve dare 10.000 risposte, lui ci mette lo stesso tempo. Se gli use case degli LLM sono humanask, ossia Chatbot Copilot Coding Agent, questo nuovo modello, al contrario, serve per gli AI powered workflows, quindi le automazioni potenziate da AI.

Perché? perché sono estremamente potenti nel categorizzare, analizzare, prendere decisioni e lo fanno in un modo così veloce che conviene al 100% utilizzarlo al posto dei normali LLM. Qui possiamo vedere la velocità a parità di domanda di Jeev e di un e di GPT 5.6 Terra. Vediamo che praticamente la risposta di Jeff è immediata, mentre GPT Terra la sta elaborando e pian piano adesso andrà a scrivere token per token. Da notare anche il costo e il tempo che per Jeff è di 0,0081, mentre per GPT Terra è di €0,01, cioè una differenza davvero abissale.

[musica] Se vediamo anche i benchmark possiamo notare che Jev è incredibilmente più economico di qualsiasi altro modello utilizzato fino ad ora, ma allo stesso tempo ha un'accura che è quasi pari a quella di GPT Terra. Ma adesso andiamo sulla dashboard così vi faccio vedere dall'interno come si può effettivamente utilizzare. Infatti se entro nella console a cui mi hanno dato accesso, possiamo vedere che ci sono delle limitazioni.

Not a generative chat model. Questa AI che si chiama Jev non puoi chattarci, puoi fargli delle domande e definire il formato della risposta in cui vuoi riceverle. Cioè, praticamente tu gli dai un input e gli dici "Voglio che tu mi dai una risposta che deve essere questa, questa, questa o quest'altra". Oppure "Voglio che mi rispondi con sì oppure no". È un livello di probabilità. So che forse al momento può non risultare molto chiaro allora use case dove possiamo effettivamente utilizzarla, ma proprio per questo vi faccio vedere un sistema che ho appena creato io e anzi prima andiamo in questa pagina qui perché hanno anche una sezione di playground nella quale appena facciamo accesso ci chiede proprio una domanda tipo un quiz, ci fa "Can you chat with Jeev type safe new model?" La risposta è no.

Infatti ci dice type safe risponde solo con decisioni strutturate e ci fa un esempio. Domanda: "Can you chat with Jeev?" Output 3% vero, 97% falso. Quindi col 97% di probabilità il modello ci ha risposto che non si può chattare con Jeev, con lui stesso. E diciamo che questo esempio già vi aiuta molto a capire il suo funzionamento. Adesso infatti andiamo qui sul playground e ci dà tre esempi. Il primo è la valutazione di quanto qualcosa è vero.

Il secondo è score e se andiamo sui doc [musica] nel dettaglio e ci dice quanto è grave il bug riportato in questa domanda e può rispondere con livello zero cosmetico, non ha alcun impatto. Numero uno, broken è rotto o degrada una feature, ma esiste un work around, esiste una soluzione. Oppure livello due, blocking issue. Non non esiste un work around ed è un problema che ti blocca. Come terzo formato c'è Choice, tu gli fai una domanda, gli dai un elenco di risposte e lui ti dà per ogni risposta la sua affidabilità e te leer ranca facendoti vedere quella più affidabile secondo le informazioni che gli hai dato.

Ad esempio, in quale linguaggio di programmazione è scritto il codice che stai leggendo e gli dai le opzioni Python, JavaScript, TypeScript, Goustri? E lui come risposta ti darà quello con la probabilità più alta di essere vero. Ma rendiamo tutto più chiaro andando nel playground e proviamo la prima opzione. Come input gli stiamo dando questo Jason. Come istruzione gli daremo una domanda che prevede come risposta un sì oppure un no.

Dopo di questo inseriremo nei criteri cosa definisce il true e cosa definisce il false. Andiamolo a vedere con un esempio di quelli che ci hanno già creato loro di base. Infatti se andiamo qui di nuovo in playground, clicchiamo qua su Sandwich, iniziamo e ci dice [musica] is hot dog a sandwich? E se noi la ranniamo così, senza definire niente, lui come risposta ci darà in base alle sue conoscenze. È al 60% vero. Quindi lui nelle conoscenze che ci sono all'interno del modello riesce a dirci che un hot dog è al 60% probabilmente un sandwich.

Però se andiamo qui sotto e aggiungiamo dei criteri gli possiamo dire true. Cos'è true? Un sandwich è un cibo dove il ripieno, come ad esempio carne, formaggio vegetables, sono inseriti all'interno di due pezzi di pane strutturati. Invece è falso quando il cibo non ha un pezzo di pane che richiude il ripieno oppure usa un solo slice of bread, quindi una sola fetta di pane, in quel caso non è un sandwich e gli dà anche degli esempi such as tortiglia, buffer or.

Quindi ragniamolo di nuovo e vediamo che da passare da 60% di probabilità adesso finisce a un 77% di probabilità. Considerate che ha senso questa risposta, perché un hot dog può essere considerato un sandwich, sì, ma non è effettivamente un sandwich, perché il pezzo di pane è unico dove all'interno contiene il wer, quindi è una domanda un po' tra virgolette trabocchetto e secondo me il il 77% di affermazione vera è probabile gli avessimo dato.

Infine qui sopra possiamo usare delle variabili, ad esempio, definiamo un cibo food. Il cibo in questione è un ice cream sandwich e gli diamo anche una definizione. Un ice cream sandwich è un frozen dessert con un layer di gelato all'interno di due cookies, waffer o piccoli pezzi di torta. Quindi ora non scriviamo più hot dog, ma mettiamo la variabile food che è stata definita qui sopra e se ranniamo ci dà che al 35% di probabilità. È vero.

Ma se ora noi andiamo qui e mettiamo ad esempio un avocado toast, ranniamo di nuovo, ci dà il 3% di probabilità perché effettivamente un avocado toast è un singolo slice of bread. Invece se qui gli diamo ad esempio un burger che effettivamente c'ha due fette di pane, facciamo run e ci dà che al 95% di probabilità è vero. Ora questi sono esempi stupidi col cibo, ma capite che noi possiamo definire un'enorme quantità di informazioni come noi vogliamo e possiamo ottenere una risposta basandosi sulle informazioni che gli abbiamo dato.

E questo diventa molto molto utile e ve lo faccio vedere tra poco sul mio cloud code. Prima vediamo velocemente le altre due possibilità proprio alla veloce perché mi sto già tirando troppo per le lunghe. Questo qui ci dice di che colore è il cielo. Ora qui non metteremo più noun come risposta, ma mettiamo choice. Di che colore è il cielo? E aggiungiamo sette opzioni. Quindi gli abbiamo dato delle possibilità indigo, electric blue, baby blue, grey, lavander, salmon e seaform green.

Quindi, se ora noi ranniamo così, senza definire nessuna di queste, otteniamo una risposta del genere. Il colore del cielo è all'82% baby blue, al 17% electric blue, quindi la probabilità che sia baby blue è quella più alta ed è probabilmente la risposta giusta. Infine c'è lo score e come esempio ci dice: "Possono le scimmie creare arte?". Noi lo apriamo, ci dà uno scenario e ci dà quattro domande. Ora, senza stare qui a leggere tutto, vi spiego brevemente cosa è appena successo.

Qui ha messo uno scenario, quindi una storiella. Qui sotto ha definito chi è il soggetto, chi è il soggetto all'interno di questa storiella, chi è l'umano e chi è cos'è il creative work, cosa rappresenta il creative work. Qui sotto invece abbiamo delle domande, quindi semplicemente il soggetto ha fatto l'azione che ha risultato in un creative work, poi l'umano ha fatto l'azione che è risultata nel creative work e così via.

E qui vediamo le risposte, ci dice proprio alla prima domanda, ossia se il soggetto ha fatto qualche lavoro creativo, c'è il 93% di verità. Questo perché nella storia che gli abbiamo dato chiaramente si vede il soggetto Naruto che ha fatto un lavoro creativo e di conseguenza in questo caso è vera. Stessa cosa fatta per l'umano, ma in questo caso l'umano nella storia non ha fatto alcun lavoro creativo e quindi c'è solo un 20% di possibilità che sia vera.

So che probabilmente arrivati a questo punto non vi è molto chiaro come effettivamente noi possiamo usare questa cosa e perché dovrebbe convenirci rispetto ad un classico ll. La risposta ve la faccio vedere qui. Io oggi ho usato Cloud Code, ho inserito la mia chiave di Typeesave AI e ho seguito dei test, un test lanciando Gemini e un test lanciando TypeS AI. E ora vi faccio vedere i risultati che ho ottenuto. Nel primo test io gli ho dato 200 titoli di articoli pubblicati in ambito tecnologia ed AI e gli ho posto una domanda semplice.

Questi articoli sono utili ad una persona che è interessata ad automazioni AI? E prima di vedere l'accuratezza, andiamo qui a vedere la velocità e la spesa. Jeev ha eseguito 200 titoli in parallelo e ha impiegato in totale 14,3 secondi, circa 668 misecondi per ogni risultato e il costo totale di tutta questa operazione è stato di 0,0029, ossia meno di 1/3 di un centimo. E infine ha aggiudicato rilevanti 102 su 200 titoli.

Ho fatto la stessa cosa con Gemini ed ecco cosa è successo. Invece di 14,3 secondi ci ha messo in tutto 123 secondi per un costo totale dient rispetto a 0,0029. Quindi il costo per giudicare 1 milione di titoli con Jeev sarebbe stato di $15, mentre con Gemini di $623. E ricordiamo che Gemini 3.8 flash, io sto usando un modello estremamente economico. Se invece di Gemini avessi usato Fable 5 oppure Opus, questo numero sarebbe stato 10-20 volte più grande.

E vediamo anche che ci sono dei risultati leggermente diversi. Gemini ha rilevato 91 titoli rilevanti, mentre Jeev un po' di più, 102. Quelli discordanti li possiamo vedere in questa bellissima pagina che mi ha creato Clud essendo 21 possiamo andare velocemente a giudicarli noi insieme per capire aveva ragione Gemini o aveva ragione Jeff. Il primo è creatività is the new mode. Tra l'altro Jeev ha dato una probabilità del 53%, quindi molto bassa.

Ciò significa che molto probabilmente in questo caso ha ragione Gemini che non è rilevante. Infatti io se ci pensate potrei implementare nel mio script per avere ehm un risultato più preciso il lo scarto automatico di tutti i messaggi che hanno una probabilità al di sotto del 70%. In questo caso questa roba me l'avrebbe esclusa a prescindere perché giustamente con solo il 3% in più di probabilità rispetto ad un no ha molto senso questo giudizio.

[musica] Invece andiamo a quello dopo. Ci dice che JEV ha detto di sì con una probabilità del 76%, quindi abbastanza alta. Ma siccome questo non mi sembrava un test abbastanza impattante, ho deciso di farne un altro dove l'ho messo a confronto con il Rex, quindi non direttamente con un LLM, ma con un sistema che aiuta a estrapolare dei concetti che ti servono da un testo. Il reject semplicemente è proprio un linguaggio che con una sua semantica precisa riesce ad andare a capire quando un testo contiene qualcosa che a te interessa.

E io lo uso spesso, ad esempio, per riconoscere se dei titoli possono essere interessanti a me che lavoro con l'AI e quindi salvarmeli in un database sul quale poi vado ad elaborarli. Il fatto è che grazie a Reex io non vado a spendere un sacco di token ogni volta lei per chiedergli di analizzare il titolo e dirmi se è efficace per me. No, io ho messo delle tra virgolette parole chiave che vado ad identificare in tutti questi titoli, quindi in automatico se il titolo contiene AI lo va a identificare e me lo salva.

Però, dato che ora è uscito questo Typescript, che è estremamente economico, ma ha i poteri, diciamo, dell'AI, ho deciso di metterlo a confronto per vedere su quanti titoli il Rejex non mi ha trovato un qualcosa che magari poteva interessarmi, mentre Typescript sì. E per fare ciò vi faccio vedere questa pagina qui. Praticamente siamo andati su Hacker News, abbiamo fatto scraping di tutti gli articoli nelle ultime 24 ore e vediamo che sono state lette 31 notizie, 2,8 secondi per giudicarle tutte e Jeev ne ha trovate 13 rilevanti, mentre Reex solo quattro.

Quelle che sono state trovate da entrambi sono queste qui e Rejex ha identificato la parola LLM, quen, open AI e di nuovo LLM. E vediamo che in tutte queste comunque Jev gli ha dato un punteggio abbastanza alto, quindi sono giuste. Quali sono però quelle che Jeev ha identificato come potenzialmente utili mentre il Rejex non è riuscito a prenderle? Ad esempio questa ll infiniti parametri. Questa a me sembra una roba molto interessante che si sarebbe dovuto salvare, ma il regex siccome l'ho impostato anch'io un po' male, dato che la parola lm c'era, ma dopo c'era una S, non è riuscita a identificarla e quindi me la son persa.

Mentre se avessi usato Jev all'interno del mio workflow me l'avrebbe salvata. Stessa cosa per tutti questi altri articoli e il fatto è questo, se consideriamo che io con RegeX pago zero, ma mi vado a perdere tante informazioni che invece sarebbero state utili, mi conviene in questo caso switchare a JEV, quindi far analizzare a un AI tutti questi titoli, in modo che possa trovarmi tutti gli articoli. E questo perché mi conviene?

Perché il costo sarebbe comunque di un decimo di un centeso, mentre se invece l'avessi fatto con Gemini sarebbe stato di 12-13 cent ogni volta e sinceramente non è una spesa che mi andrebbe di affrontare, dato che queste cose io le vedo ad alto volume ogni singolo giorno, non ha senso che io vada a spendere tutti questi soldi. Mi conveniva fino ad oggi usare Rejex a discapito di perdermene qualcuna, ma invece adesso io ho la possibilità di pagare comunque vicino allo zero e avere tanti più risultati di qualità.

Ecco un caso effettivamente utile nel quale usare questo nuovo modello AI, ma ci sono degli esempi ancora più belli e ve li faccio vedere adesso e vi faccio vedere anche la stima dei costi che è davvero incredibile. Praticamente gli ho detto di andare sul mio canale YouTube, di andare a fare scraping su tutti i miei video di tutti i commenti che ho ricevuto finora e gli ho detto di categorizzarmeli per capire chi ha commentato ed è un cliente potenziale, [musica] chi invece richiedeva solo una risposta e infine la sezione guarda tu dove Jeev praticamente non è sicuro e quindi devo ricontrollare a mano.

La cosa bella è che per 380 commenti e 10 domande fatte a JEV per ogni singolo commento, quindi ottenendo un totale di 3800 risposte, noi abbiamo speso solamente 24 secondi e 0,015, quindi meno di centali. qui sotto ci ha fatto una tabella dove ci dice, "Guarda, questo questa persona qui ha fatto una domanda tecnica riguarda Cloud e ha un intento positivo." Qui mi fa riferimento anche al video dove ho ricevuto questo commento, ma eh molto semplicemente è riuscito a categorizzare questa una domanda, come un una possibile conversione.

Quindi io a questa persona interessata ad una roba del genere posso proporre di entrare nella mia community oppure posso proporre di vendergli una consulenza o qualcosa del genere. Mentre invece un commento del genere, se possibile manda il link grazie, l'ha categorizzato come effettivamente un rispondi dove io devo andare a rispondere ma non è un possibile cliente, cioè non ha fatto una domanda specifica sulla quale potrei aiutarlo o qualcosa che potrei vendergli.

E questo test ho deciso di farlo sui miei commenti in italiano perché JEV, secondo la loro documentazione, è specifico per l'inglese, quindi non è stato testato su altre lingue, ma abbiamo visto che comunque anche sull'italiano, quindi anche a noi, può tornare utile nonostante non sia ancora ottimizzato. E sinceramente se avessi fatto fare questo stesso lavoro a Opus o a Gemini, altro che un centesimo, avrebbe speso forse più di €1, probabilmente sì, forse più di €1 non mi bastava e quindi sono andato a fare una sfida.

Abbiamo Jeev contro Gemini 3.8 flash, ricordiamolo, un modello comunque molto molto economico. Abbiamo fatto due test, quello di prima, il radar dei 200 titoli e quello dei commenti YouTube. Abbiamo utilizzato le stesse domande e gli stessi dati per entrambi i modelli e li abbiamo misurati oggi dall'Italia in data 18 settembre 2026. Come abbiamo visto prima, 0,015 per Jeev, quindi meno di contro 0,79 per Gemini. Gev è 52 volte meno caro per lo stesso risultato.

Ipotizziamo ora di dover fare la stessa cosa su 1 milione di commenti. Con Jeev andremo a spendere $40. Con Gemini senza ragionamento $845, mentre con Gemini più il ragionamento $2.084. Ricordiamo la cosa interessante, ossia che Jeev, questo modello, non ha un costo in output, quindi noi effettivamente paghiamo solo i token in input, ma il i token in output solitamente sono così pochi che non vengono conteggiati che quindi hanno costo zero.

In fatto a velocità vediamo che Jeev ci ha messo 0,62 secondi per 10 commenti, mentre Gemini 146 secondi e 252 secondi in base a senza o con ragionamento. Ma la cosa è che se noi a questi aggiungessimo delle domande, delle domande aggiuntive, come vedete il tempo occupato da Jeev rimarrebbe pressoché uguale. Cambia proprio la latenza di qualche millisecondo semplicemente per le chiamate al server, ma il costo di elaborare quelle informazioni, non importa se sono 10 domande o 10.000, e sempre di pochi millisecondi, mentre Gamini vediamo che pian piano aggiungendo domande aumenta, anche se di poco, sommandosi, ad esempio, 1 milione di domande alla fine il tempo diverrebbe davvero davvero alto.

Vediamo però l'output, quanto è bravo Jeev rispetto a Gemini. possiamo osservare un 89% di accuratezza di Jeev e un 96% di Gemini senza ragionamento, ma questo, ricordiamoci, è senza prendere in considerazione le volte che, ad esempio, si definisce sicuro al 53%, ossia quelle volte in cui dovremmo automaticamente scartarlo. Se invece prendiamo in considerazione solo le volte in cui Jev si dice sicuro, otteniamo quasi un ribaltamento della situazione con un 96% di accurasi contro un 98,5% di gemini.

Quindi in linea di massima dovreste aver capito quando potrebbe essere utile integrare Jev all'interno dei vostri workflow al posto di un LLM. Qui basandoci su questo test vediamo che torna molto utile quando devi smistare con un grosso volume, quindi devi smistare delle mail, dei ticket, dei nuovi lead, dei commenti, delle recensioni. Puoi usare Jev rispetto ad un llm per risparmiare una marea di soldi e avere un punteggio che è praticamente uguale di affidabilità.

Ci può inoltre tornare utile per filtrare notizie rilevanti, trovare spam, fare moderazione di commenti, contenuti o qualsiasi altra cosa, controllare altri sistemi, quindi verificare gli output e infine prendere decisioni in tempo reale. Attenzione, questo è molto utile quando, ad esempio, abbiamo un videogioco con un'interfaccia integrata nella quale vogliamo che le azioni corrispondano ad un ragionamento degli AI.

In questo caso possiamo utilizzare Jev per una velocità estrema e avere un output praticamente in tempo reale. Stessa cosa usando un LLM non funzionerebbe perché dovremmo aspettare magari un secondo, 2 secondi per avere la risposta e sappiamo che nei videogiochi veloci è impossibile. Tra l'altro guardate qua, l'hanno usato proprio per giocare a Doom, un videogioco nella quale ci vuole prontezza di riflessi estrema e Jeev, diciamo, che non se la cava affatto male.

Invece quando non possiamo usarlo, quando c'è bisogno di un output lungo di scrittura, un testo, un'analisi, un qualcosa di dettagliato, JEV è inutile perché appunto non scrive testo. Stessa cosa non possiamo dargli il compito di elaborare informazioni, elaborare calcoli, date o o numeri perché proprio è una limitazione, non può farlo, ma ci può aiutare a monte, quindi prima del calcolo, lui può magari capire la complessità di questo calcolo e far partire uno script rispetto che un altro, ecco a cosa ci può essere utile.

Quindi non fa i calcoli lui in prima persona, ma capisce il contesto, capisce l'output che la persona vuole ottenere. E se il nostro sistema ci sono due script che fanno due tipologie di calcoli diversi, lui sa indirizzare qual è lo script giusto per questa situazione e manda il programma a eseguirlo, così che l'utente riceva l'output finale corretto. Quindi, diciamo, è decisionale, serve a decidere qual è lo script migliore in questa situazione.

E riguardo questo vi faccio vedere l'ultimissimo test e forse il più interessante perché gli ho dato il permesso di scegliermi le skill all'interno di Cloud nel momento in cui devono essere usate. Vi spiego un po' come funziona. Di base il mio Cloud ha 181 skill e come sappiamo le skill di Cloud vengono evocate automaticamente da Cloud stesso nel momento in cui riconosce che ce n'è bisogno. Quindi se io ho una skrill che scrive riassunti e io sto chiedendo a Cloud in una chat per favore fammi il riassunto della Prima Guerra Mondiale, lui capisce che deve chiamare la skill riassunti e la esegue.

Bene, il problema è questo. Come fa Claude a capire quale skill eseguire? Semplicemente ogni singola skill c'ha un titolo e una descrizione. Cloud se le va a leggere, capisce quale tra le tante è la più probabile che che mi serva per fare un riassunto e quindi la evoca. Il fatto è che spesso se si hanno tante skill molto simili, le descrizioni non sempre sono espresse nel modo corretto e Cloud fa fatica a capire quale effettivamente è la migliore nel nostro ambito, quindi quale deve chiamare.

In questa situazione ci torna in aiuto Jeev perché perché Jeev è in grado non solo di analizzare il titolo e la descrizione ma anche tutta la skill completa. Ciò significa che noi invece di lasciar decidere a Cloud possiamo mettere un hook prima della chiamata di ogni skill dove Jeev in automatico a studiarsi tutte le skill, a leggersele tutte e come output dà le più probabili a Cloud, quindi le tre che potrebbero essere quelle giuste con il livello di probabilità.

La cosa è che Jeff, vivendo dentro il tuo codice ed essendo così veloce e così economico, tu lo puoi ficcare da qualsiasi parte nei tuoi script, nei tuoi sistemi, nelle tue automazioni per eseguire la sua il suo giudizio in modo velocissimo ed economico. Ciò significa che grazie a lui puoi tagliare i costi di qualsiasi sistema che hai creato in maniera abbastanza importante. Bene, io direi che ora con i test ne abbiamo abbastanza.

Spero abbiate capito l'uso che potete fare di questo nuovo modello AI. Io non posso dirvi in anticipo se sarà davvero utile, se i risultati sono buoni o altro. Semplicemente ora ci tocca testarlo in ambienti sicuri, vedere se l'output nel tempo è migliore rispetto a quello che avevamo prima e infine se funziona integrarlo o implementarlo nei sistemi che andiamo a vendere ai nostri clienti. A questo punto credo di avervi dato una panoramica abbastanza grande di come funziona, come utilizzarlo e perché è meglio rispetto agli LLM in determinati task.

Vi faccio solo vedere che nel momento in cui avrete anche voi accesso, ci sarà una pagina del genere con un quickst. Quindi voi copiando questo prompt, c'è anche una skill. MD, voi potete andare nel vostro cloud, incollarglielo e lui in automatico installerà il plugin all'interno del vostro Cloud Code e a quel punto dovrete andare a copiare, inserire l'ipi key [musica] che vi fa generare da questa pagina e una volta messa dentro al vostro sistema potrete iniziare a integrarlo ovunque per vedere come funziona, se vi dà buoni risultati e così via.

La cosa è che voi non dovete conoscere tutte queste come strutturare questi Jason studiandovi la documentazione, no, perché in automatico sarà in grado di farlo cloud. Lui si leggerà questa documentazione, farà le chiamate usando Typeesave AI, ossia JEV, senza che voi dobbiate, ecco, studiarvi nel dettaglio come funziona la sua architettura e come chiamarlo. Questo è quanto. Ci sarà una pagina di usage. Oggi abbiamo usato 9.000 token con 18 richieste abbiamo speso meno di 0.01ent. davvero davvero incredibile.

Ricordiamoci che questo può essere tranquillamente l'inizio di una nuova era perché nel momento in cui molte persone inizieranno a implementare JEV all'interno dei loro workflow, si scopriranno sempre di più dei modi migliori per utilizzarlo, dei modi per rendere determinate azioni più efficienti e anche di ridurre tantissimo i costi che, come stiamo vedendo negli ultimi mesi, stanno aumentando davvero tanto. Io, ad esempio, con l'abbonamento da €100 di Cloud Code non riesco più a stare dentro, cioè vado sempre incontro al limite delle 5 ore e al limite settimanale.

Probabilmente aggiungendo nel mio framework di mezzo Jeev per alcune operazioni, io posso riuscire a diminuire questo costo e quindi rimanere all'interno dei miei limiti. Ma soprattutto se io ho un sistema, una piattaforma che usa le chiamate API di Antropic, di Open AI o di Gemini, io posso iniziare da oggi a implementare Jev, fare le chiamate prima che le facciano i miei LLM di fiducia, così da ridurre il contesto di quello che loro dovranno gestire.

Voglio solo farvi vedere questa cosa interessante che un LM di frontiera tra virgolette costa da 20 cent a $10 per milione di token in input, mentre JEV costa 0,042 ogni milione di token, ossia $42 per 1 miliardo di token in input. [musica] In output, invece, solitamente negli LM classici sono 5 dell'input, quindi se ad esempio eh Fable ha €10 in input, c'avrà €50 in output. Bene, invece Jeev ha un costo di output che è completamente gratuito, quindi noi stiamo solo pagando l'inputa, che comunque è molto più basso degli input di qualsiasi altro modello LLM.

Io concludo qui. Ti invito a cliccare nella community se vuoi imparare a creare sistemi con le AI e rivenderli ad aziende. Ci sentiamo al prossimo video e ci vediamo. Чау.