Meta Muse Glimmer porta un agente AI locale sui PC da gaming

Meta ha rilasciato Muse Glimmer 30B per l'uso locale, rendendo un modello incentrato sugli agenti accessibile ai PC da gaming con circa 24 GB di memoria grafica. È questo il nodo dietro la recente attenzione di Google News. Un modello può ora pianificare, richiamare strumenti, analizzare immagini e operare tramite un framework per agenti senza inviare ogni prompt a un provider cloud. Tuttavia, riuscire a far entrare il modello in memoria non equivale a eseguire un agente personale affidabile.

Il rilascio cambia il terreno della competizione tra agenti. Il più grande Muse Spark 1.1 di Meta funziona tramite Meta AI e la Meta Model API. Muse Glimmer porta parte di questa strategia agent-first sull'hardware che gli sviluppatori già possiedono. Le build quantizzate, che riducono la precisione del modello e l'uso della memoria, rendono i suoi 30 miliardi di parametri praticabili su alcuni sistemi consumer.

L'avversario immediato non è un altro singolo modello. È il percorso degli agenti cloud rappresentato dai sistemi ospitati di Meta, OpenAI, Anthropic e Google. I modelli cloud offrono maggiore capacità e infrastruttura gestita. Glimmer promette invece controllo locale, disponibilità prevedibile e dati che possono restare sulla macchina dell'utente. I primi test della community confermano alcuni aspetti di questa promessa, ma evidenziano anche comportamenti incoerenti nella programmazione, nella configurazione e nell'uso degli strumenti.

Cosa cambia davvero con il rilascio di Muse Glimmer

Muse Glimmer sposta la strategia di Meta per gli agenti da un'esperienza esclusivamente ospitata verso un modello che gli appassionati possono eseguire sul proprio hardware.

Il rilascio segnalato riguarda un modello multimodale da 30 miliardi di parametri. Multimodale significa che può elaborare più del testo, incluse le immagini quando abbinato al componente necessario di proiezione visiva. Il suo orientamento agli agenti è importante perché il modello è progettato per produrre chiamate strutturate agli strumenti, seguire istruzioni in più passaggi e continuare a lavorare dopo che uno strumento restituisce informazioni.

Queste capacità distinguono un modello per agenti da un convenzionale chatbot locale. Un chatbot genera principalmente una risposta. Un agente lavora attraverso un harness, ovvero il livello software che gli fornisce strumenti, memoria, file, accesso al browser e regole. Il modello decide quali strumenti richiamare, mentre l'harness esegue le azioni.

Il solo modello scaricabile non costituisce quindi un agente completo. Gli utenti hanno comunque bisogno di un motore di inferenza, di un framework per agenti, di un template di chat adatto e di autorizzazioni agli strumenti accuratamente limitate. Potrebbero inoltre servire componenti separati per la visione e la decodifica speculativa. La decodifica speculativa utilizza un sistema bozza più piccolo per proporre token che il modello principale verifica, con il potenziale di aumentare la velocità di generazione.

Il repository del modello è l'artefatto centrale per valutare il rilascio. Conta più del titolo perché file, metadati, licenza, template e revisioni determinano ciò che gli utenti possono riprodurre. Le conversioni della community possono migliorare la compatibilità hardware, ma potrebbero introdurre scelte di quantizzazione o presupposti di configurazione diversi.

La lunghezza di contesto nativa riportata per Glimmer è di 131.072 token. Una finestra di contesto è il testo di lavoro e la cronologia degli strumenti disponibili durante una singola interazione. Questa capacità è sufficiente per documenti corposi, codice e tracce degli agenti. Non crea memoria permanente, né garantisce un recupero accurato vicino al limite.

La tempistica si inserisce anche nel più ampio lancio di Muse da parte di Meta. Meta ha presentato Muse Spark nell'aprile 2026, seguito da Muse Image e Muse Spark 1.1 a luglio. L'azienda descrive Muse Spark 1.1 come un modello di ragionamento multimodale costruito attorno a strumenti, uso del computer, programmazione e orchestrazione multi-agente.

Glimmer porta questa direzione di prodotto in una forma più piccola e scaricabile. Non offre semplicemente un assistente cloud ridotto. Il suo appeal dipende dalla capacità degli utenti locali di collegare il modello a strumenti reali e ottenere un comportamento affidabile entro i limiti dell'hardware consumer.

Ecco perché la definizione di “agente AI completo” richiede una precisazione. Il modello fornisce la componente di ragionamento. Il software circostante fornisce esecuzione, memoria, controllo degli accessi, recupero e integrazioni. Un agente locale funzionante emerge dall'intero stack, non da un file di pesi da solo.

Perché l'attenzione di Google News arriva proprio ora

La storia si sta diffondendo perché sono confluiti tre sviluppi: modelli per agenti più piccoli, software di inferenza locale maturo e hardware consumer con memoria sufficiente per eseguirli.

Un modello denso da 30 miliardi di parametri richiederebbe normalmente ben più di 24 GB se memorizzato con una precisione numerica superiore. La quantizzazione comprime i pesi, spesso in quattro o cinque bit per valore. Le build della community attorno ai 16 GB-20 GB lasciano quantità variabili di memoria per la cache del contesto, il componente visivo e l'overhead di runtime.

Questa fascia coincide con schede da gaming di fascia alta e computer Apple che usano memoria unificata. La memoria unificata consente al processore e ai core grafici di condividere un unico pool, anche se la larghezza di banda e le riserve di sistema influenzano comunque le prestazioni. Il fatto che un modello entri in memoria non garantisce un'elaborazione rapida dei prompt né spazio sufficiente per un contesto lungo.

Anche il lato software è avanzato. Progetti come llama.cpp possono eseguire modelli quantizzati su sistemi Nvidia, AMD, Apple e basati su CPU. Endpoint locali compatibili con OpenAI consentono ai framework per agenti di sostituire un'API cloud con un server in esecuzione sulla stessa rete. Questo riduce il lavoro di integrazione personalizzata che un tempo era necessario per l'inferenza locale.

Un distinto esperimento su PC da gaming illustra il modello più ampio. Cybernews ha descritto l'esecuzione locale di Hermes Agent con un modello Qwen, incluse operazioni sui file, attività pianificate, ricerca sul web e accesso alla messaggistica. L'esperimento precedeva Glimmer, ma ha stabilito il caso d'uso che Glimmer ora mira più direttamente.

Muse Glimmer arriva anche dopo che Meta ha posizionato la più ampia famiglia Muse attorno all'azione anziché alla conversazione. Secondo quanto riportato, Spark 1.1 gestisce un contesto da un milione di token e coordina strumenti o subagenti nell'ambiente ospitato di Meta. Meta afferma che può scegliere tra azioni dell'interfaccia e script generati durante le attività di uso del computer.

Il modello locale non eredita l'infrastruttura del servizio cloud. Tuttavia, il comune posizionamento agent-first offre agli sviluppatori una ragione più chiara per testarlo. Non si limitano a chiedersi se Glimmer scriva risposte piacevoli. Stanno verificando se seleziona gli strumenti, conserva lo stato dell'attività, si riprende dagli errori e rispetta i vincoli.

Questo focus spiega la rapida comparsa di file quantizzati, template, patch di inferenza e benchmark degli utenti. Le community dei modelli locali possono ormai rendere operativo un rilascio nel giro di pochi giorni. Il loro lavoro trasforma un checkpoint del modello in qualcosa che funziona attraverso applicazioni desktop e framework per agenti.

Crea anche un ciclo informativo rumoroso. I risultati di ricerca mescolano materiali di Meta, conversioni di terze parti, benchmark personali, video di configurazione e affermazioni copiate tra community. Google News può far emergere rapidamente il rilascio, ma l'aggregazione non stabilisce quali dichiarazioni sulle prestazioni provengano da Meta e quali da singoli tester.

La distinzione è importante per i lettori che confrontano i requisiti hardware. Una persona potrebbe considerare soltanto il file di pesi compresso. Un'altra potrebbe includere la cache chiave-valore, il proiettore di immagini, il modello bozza, l'ambiente desktop e il processo dell'agente. Entrambe possono descrivere lo stesso modello come adatto a un PC da gaming, pur richiedendo sistemi sensibilmente diversi.

La conclusione credibile è più circoscritta del titolo. Glimmer porta un modello multimodale da 30B orientato agli strumenti nella fascia dell'hardware consumer. Il fatto che diventi un utile agente a tempo pieno dipende dalla capacità di memoria, dal software di inferenza, dalla progettazione del carico di lavoro e dalla tolleranza dell'operatore per la manutenzione.

Muse Glimmer locale contro il percorso degli agenti cloud

Il principale vantaggio di Glimmer è il controllo sull'esecuzione e sui dati, mentre gli agenti cloud mantengono il vantaggio in capacità gestita, integrazione e supporto.

Un'implementazione locale può mantenere prompt, documenti recuperati, screenshot e risultati degli strumenti all'interno dell'ambiente dell'utente. Questo conta quando un agente lavora con codice sorgente, archivi personali, documenti finanziari o corrispondenza privata. Consente inoltre agli sviluppatori di ispezionare i log e preservare una specifica versione del modello.

L'operatività locale può ridurre la dipendenza dai limiti di frequenza o dalla disponibilità di un servizio esterno. Una volta scaricato, il modello può continuare a funzionare senza che un provider di modelli accetti ogni richiesta. Gli strumenti dipendenti da Internet richiedono comunque connettività e le integrazioni di messaggistica possono usare servizi esterni, ma il ciclo centrale di inferenza resta locale.

Il compromesso è la responsabilità operativa. L'utente deve scegliere una quantizzazione, verificare i template, allocare memoria per il contesto, installare un motore di inferenza e aggiornare componenti compatibili. Un template errato può compromettere le chiamate agli strumenti anche quando il modello sottostante è capace. Un contesto lungo può esaurire la memoria prima che il modello inizi a generare.

Le piattaforme cloud nascondono gran parte di questi meccanismi. Forniscono serving del modello, scalabilità, autenticazione, aggiornamenti e API per gli strumenti. I loro modelli più grandi possono inoltre attingere a più capacità di calcolo per richiesta. Questo vantaggio diventa evidente durante programmazione complessa, ricerca ampia o attività lunghe che richiedono correzioni ripetute.

La stessa divisione di Meta tra Spark 1.1 e Glimmer rende concreto il confronto. Spark 1.1 è disponibile tramite prodotti Meta ospitati e un'anteprima pubblica dell'API. Meta afferma che il sistema supporta un contesto gestito da un milione di token e l'uso multimodale del computer. Il contesto locale e le prestazioni di Glimmer dipendono dalla macchina e dal runtime dell'utente.

La privacy non è automatica in nessuno dei due percorsi. Un modello locale può comunque trasmettere informazioni sensibili tramite ricerca, email, browser o strumenti di terze parti. I framework per agenti possono eseguire comandi che espongono file o credenziali. L'inferenza locale rimuove un destinatario dei dati, ma il flusso di lavoro completo necessita di una propria revisione della sicurezza.

Lo stesso vale per l'autonomia. Un agente cloud non è affidabile soltanto perché il suo modello è più grande. Un agente locale non è sicuro soltanto perché funziona offline. Entrambi richiedono confini di autorizzazione, azioni verificabili e conferma prima di operazioni con conseguenze rilevanti.

Per i flussi di lavoro ricchi di conoscenza, l'inferenza locale diventa più utile quando è abbinata a un recupero controllato. Un livello personale di knowledge blending può fornire contesto selezionato senza inserire un intero archivio in ogni prompt. L'agente necessita comunque di regole su quali materiali può leggere e quali azioni richiedono approvazione.

Anche i confronti dei costi dipendono dal carico di lavoro, persino senza discutere prezzi specifici. Un PC da gaming consuma elettricità e occupa hardware che potrebbe altrimenti servire per giochi o applicazioni creative. L'uso del cloud consuma calcolo remoto quando viene richiesto. Un utilizzo intenso e regolare favorisce un'economia diversa rispetto a un lavoro occasionale e complesso.

Il caso più forte per Glimmer non è quindi “il locale batte il cloud”. È la collocazione del carico di lavoro. L'elaborazione ripetitiva di documenti, il recupero privato, la categorizzazione in background o l'uso vincolato degli strumenti possono adattarsi all'operatività locale. Il ragionamento di frontiera, i grandi carichi di lavoro paralleli e le implementazioni a bassa manutenzione possono ancora favorire i modelli ospitati.

Questa divisione esercita maggiore pressione sui provider cloud di quanto farebbe una vittoria nei benchmark. Gli utenti ora hanno un'altra opzione credibile per instradare localmente il lavoro ordinario degli agenti, riservando i sistemi cloud ai passaggi difficili. I flussi di lavoro ibridi possono selezionare i modelli in base a sensibilità, complessità e latenza invece di affidare tutto a un unico provider.

I primi test mostrano promesse e contraddizioni

Le prime segnalazioni suggeriscono che Glimmer gestisca bene le routine degli agenti in rapporto alle sue dimensioni, ma non dimostrano una superiorità costante rispetto ai modelli locali concorrenti.

Un test della community molto discusso ha confrontato Glimmer con Qwen3.6 27B in OpenCode e in altri flussi di lavoro con agenti. Il tester ha affermato che entrambi i modelli completavano i compiti, mentre Glimmer raggiungeva i risultati in modo più efficiente. Lo stesso rapporto descriveva Glimmer come più debole in molte attività di programmazione.

Questa combinazione è plausibile. L'affidabilità degli agenti e la capacità grezza di programmazione sono correlate, ma distinte. Un modello può scrivere codice più debole e al tempo stesso seguire più coerentemente una regola di delega. Può scegliere lo strumento corretto, producendo però un'implementazione meno rifinita dopo il suo utilizzo.

Il primo resoconto di un utente ha anche riferito che una build quantizzata di Glimmer entrava in una GPU da 24 GB con un contesto di 131.072 token nella configurazione di quel tester. L'affermazione è utile come pista riproducibile, non come requisito universale.

La quantizzazione cambia il quadro. Una precisione inferiore riduce l'uso di memoria, ma può influenzare il ragionamento, il rispetto delle istruzioni o la stabilità dell'output. Quantizzatori diversi preservano parti diverse del modello. Due persone che affermano di aver testato “Muse Glimmer 30B” potrebbero in realtà provare file con comportamenti sostanzialmente differenti.

La configurazione del contesto aggiunge un'altra variabile. La cache chiave-valore memorizza le informazioni di attenzione generate durante una sessione. Il suo uso di memoria cresce con la lunghezza del contesto e dipende dalla precisione della cache. Un file di modello compatto può entrare comodamente in memoria finché l'utente non richiede un contesto ampio, carica il proiettore per la visione o avvia più sessioni di agenti.

Alcuni utenti hanno esteso Glimmer oltre il contesto di addestramento dichiarato mediante tecniche di scalatura. Un esperimento ha descritto test di recupero riusciti a lunghezze molto maggiori su due sistemi DGX Spark. Si tratta di un'interessante soluzione ingegneristica, ma non dimostra un ragionamento equivalente nell'intero contesto esteso.

Un modello che individua un fatto inserito appositamente non equivale a un agente capace di mantenere un piano coerente attraverso centinaia di chiamate agli strumenti. I test di recupero esaminano una capacità specifica. Gli agenti di lunga durata devono anche distinguere le informazioni correnti dai risultati obsoleti, recuperare dopo gli errori ed evitare di ripetere le azioni.

Altri rapporti della community evidenziano queste debolezze. Alcuni tester hanno trovato Glimmer più coerente durante attività con più fonti. Altri hanno descritto chiamate agli strumenti eccessive o cicli ripetitivi. Un confronto ha affermato che Qwen selezionava direttamente lo strumento corretto, mentre Glimmer riconsiderava le proprie scelte e si perdeva in passaggi aggiuntivi.

Tutti questi rapporti possono essere veri con template e harness diversi. Le prestazioni degli agenti dipendono fortemente dalle descrizioni degli strumenti, dai prompt di sistema, dalle condizioni di arresto e dal modo in cui vengono restituiti i risultati. Un modello ottimizzato per un formato previsto può funzionare male quando un'applicazione ne usa un altro.

Il template di chat merita particolare attenzione. Definisce come messaggi di sistema, richieste dell'utente, definizioni degli strumenti e risultati degli strumenti diventano input per il modello. Secondo alcune segnalazioni, un aggiornamento del template poco dopo il rilascio ha modificato il comportamento degli strumenti per alcuni utenti. Chiunque esegua benchmark tra revisioni dovrebbe registrare il template esatto e il commit del modello.

Anche i risultati hardware variano molto. Un tester con RTX 5090 ha riportato un throughput rilevante con speculative decoding ottimizzato. Un tester con laptop Apple ha rilevato che una configurazione draft rendeva la generazione più lenta. La speculazione aggiunge overhead, quindi aiuta solo quando il sistema draft propone token che vengono accettati in modo efficiente.

Non si tratta di dettagli implementativi secondari. Determinano se un agente sembra reattivo e se riesce a completare un compito prima che l'utente intervenga. Una configurazione che produce rapidamente token di chat può comunque faticare con l'elaborazione di prompt lunghi, l'elaborazione delle immagini o scambi ripetuti con gli strumenti.

Anche il confronto con Qwen resta irrisolto. I modelli Qwen dispongono di un ecosistema locale consolidato e di un ampio supporto per le conversioni. L'attrattiva iniziale di Glimmer deriva dal comportamento degli agenti, dalla multimodalità e dalla quantizzazione efficiente. Qwen potrebbe restare più forte in specifiche configurazioni di programmazione o ricerca.

Gemma è un altro riferimento rilevante. Gli utenti spesso elogiano i modelli Gemma più piccoli per la scrittura e il comportamento nel seguire le istruzioni, ma dimensione del modello, requisiti di memoria e supporto degli strumenti differiscono. Glimmer entra in un campo affollato anziché creare dal nulla gli agenti locali.

Le evidenze giustificano un entusiasmo prudente. Muse Glimmer sembra abbastanza capace da meritare test seri su hardware consumer. I rapporti disponibili non giustificano la dichiarazione che sia il miglior modello di agente locale per programmazione, ricerca, assistenza personale e lavoro multimodale.

Ciò che il titolo di Google News non mostra

Il problema più difficile non è caricare 30 miliardi di parametri. È consentire a un modello imperfetto di agire senza creare rischi inaccettabili.

Un agente locale può leggere file, eseguire script, navigare su siti web autenticati e inviare messaggi se il suo harness gli concede questi strumenti. Ogni capacità amplia il potenziale danno causato da un'istruzione errata, un comando allucinato o un documento malevolo.

La prompt injection è particolarmente rilevante. Una pagina web o un documento può contenere testo progettato per sovrascrivere la richiesta dell'utente. Il modello potrebbe trattare quel contenuto non attendibile come un'istruzione ed esporre dati tramite un altro strumento. L'inferenza locale non impedisce questo attacco, perché esso prende di mira il processo decisionale dell'agente.

Il rischio cresce quando gli utenti equiparano la privacy alla sicurezza. Mantenere l'inferenza su una singola macchina protegge da alcune esposizioni remote dei dati. Non protegge da comandi shell distruttivi, download compromessi, permessi eccessivi o da un agente che invia informazioni tramite una sessione browser autorizzata.

Un'implementazione sensata separa la lettura dalla scrittura. L'agente può cercare e riassumere all'interno di uno spazio di lavoro ristretto prima di ricevere il permesso di modificare i file. Email, acquisti, modifiche agli account e amministrazione di sistema dovrebbero richiedere una conferma esplicita.

La memoria a lungo termine richiede una prudenza simile. Un agente può salvare preferenze o cronologia delle attività per le sessioni future. Può anche trattenere conclusioni errate, informazioni sensibili o istruzioni incorporate in materiale non attendibile. La memoria dovrebbe registrare la provenienza e consentire revisione, correzione ed eliminazione.

L'affidabilità è il secondo problema nascosto. I benchmark sugli agenti spesso contano se un compito finale ha avuto successo. Gli utenti devono anche sapere quanti tentativi, chiamate agli strumenti e correzioni sono stati necessari. Un modello che ha successo dopo aver vagato può consumare tempo, energia e contesto, creando al contempo più opportunità per azioni non sicure.

Le prime segnalazioni su Glimmer restano troppo eterogenee per una stima solida dell'affidabilità. Usano hardware, quantizzazioni, prompt, runtime e set di strumenti diversi. Molte sono esperimenti personali senza valutazione in cieco né suite di attività pubblicate.

Anche la velocità riportata del modello richiede contesto. I token al secondo misurano il throughput di generazione. La latenza di un agente include caricamento, elaborazione del prompt, esecuzione degli strumenti, richieste di rete, codifica delle immagini e ragionamento ripetuto. Un decoder più veloce non garantisce un compito completato più rapidamente.

Gli utenti dovrebbero inoltre distinguere i file ufficiali dalle conversioni della community. Una conversione può essere legittima e utile, ma le sue impostazioni influenzano qualità e compatibilità. Prima dell'implementazione dovrebbero essere documentati licenza del modello, commit sorgente, hash dei file e revisione del template.

L'inquadramento originale di Google News è corretto nella direzione generale: un modello di agente serio può entrare in alcuni PC da gaming. “Completo” resta un'affermazione architetturale, non una garanzia di affidabilità. Il sistema completo include il modello, il server di inferenza, l'harness, gli strumenti, la memoria, i permessi e il monitoraggio.

I materiali ospitati di Muse di Meta includono affermazioni sulla sicurezza e controlli di implementazione per Spark 1.1. Questi risultati non dovrebbero essere trasferiti automaticamente a ogni quantizzazione di Glimmer e harness locale. Compressione, template, progettazione degli strumenti e prompt di sistema creano un ambiente di implementazione diverso.

La valutazione indipendente è quindi il livello mancante. I test dovrebbero confrontare i modelli con strumenti, dimensioni del contesto, prompt e regole di arresto identici. Dovrebbero misurare completamento riuscito, azioni non sicure, chiamate ripetute, latenza e interventi umani.

Finché questi risultati non esisteranno, Glimmer va considerato al meglio come un modello supervisionato da un operatore. Può compiere azioni utili in un ambiente delimitato. Non dovrebbe ricevere ampia autorità solo perché funziona localmente o completa alcune dimostrazioni impressionanti.

Tre segnali che decideranno il caso degli agenti locali di Muse Glimmer

Glimmer conterà oltre la settimana del lancio solo se convergeranno test indipendenti, supporto software stabile e utilizzo reale continuativo.

Il primo segnale è una valutazione standardizzata degli agenti. Cercate confronti con Qwen e Gemma che usino lo stesso harness, gli stessi strumenti, obiettivi di quantizzazione e classe hardware. Risultati solidi dovrebbero includere tassi di errore e conteggi degli interventi, non solo dimostrazioni riuscite. Successi ripetuti rafforzerebbero l'ipotesi che il comportamento da agente di Glimmer sopravviva al di fuori dei prompt curati.

Il secondo segnale è la stabilità del runtime. llama.cpp e le applicazioni correlate necessitano di un supporto affidabile per l'architettura di Glimmer, il componente di visione, il template di chat e il decoder speculativo. Osservate se le revisioni del template si stabilizzano e se i comuni strumenti desktop adottano impostazioni predefinite testate. Frequenti problemi di configurazione indebolirebbero l'affermazione che i normali proprietari di PC da gaming possano eseguire il modello in modo produttivo.

Il terzo segnale è un'adozione duratura da parte degli utenti. L'entusiasmo della community spesso raggiunge il picco attorno a un rilascio e passa al modello successivo nel giro di pochi giorni. L'uso continuativo in Hermes, OpenCode, automazione domestica, flussi di lavoro documentali e ricerca privata dimostrerebbe che Glimmer risolve problemi ricorrenti. L'abbandono dopo esperimenti di benchmark suggerirebbe invece che il titolo ha sopravvalutato il suo valore pratico.

Anche le scelte future di Meta contano, sebbene non costituiscano un segnale separato. Pesi aggiornati, valutazioni più chiare o varianti più piccole potrebbero ampliare la base hardware raggiungibile. Un successore esclusivamente ospitato rafforzerebbe invece l'idea che Glimmer fosse un esperimento accanto alla strategia cloud di Meta.

I lettori arrivati tramite Google News dovrebbero evitare di ridurre la storia a una cifra di memoria. Lo sviluppo importante è che i modelli orientati agli agenti stanno diventando implementabili in ambienti locali, cloud e ibridi. Questo offre agli sviluppatori maggiore controllo su dove si spostano i dati e dove avviene il calcolo.

Il prossimo passo utile è concreto. Scegliete un'attività delimitata, registrate le revisioni esatte del modello e del software e negate gli strumenti irreversibili. Misurate lavoro completato, interventi, latenza ed errori in esecuzioni ripetute. Poi confrontate quei risultati con un agente cloud e un altro modello locale.

Questo test risponderà alla domanda a cui il titolo non può rispondere: Muse Glimmer entra semplicemente nel vostro PC da gaming, oppure si guadagna un posto stabile al suo interno?