Muse Wonder Full non è il modello dell'API

Meta ha lanciato Muse Wonder e Muse Wonder Full il 12 ottobre 2026, ma Full, il modello più capace, non è disponibile tramite la Meta Model API. Richiede un abbonamento Muse Code compatibile. Questo cambia come leggo il lancio: i risultati migliori di Full giustificano una prova di Full; un’integrazione API richiede dati sul modello Wonder che può effettivamente chiamare. [1] [2]

Si può usare Muse Wonder Full tramite API?

No. Meta Developers specifica che Full è disponibile solo con gli abbonamenti Muse Code e che scegliere max su Wonder non seleziona Full. Il modello dell’API è muse-wonder-1.0. Full è una variante più capace con un accesso diverso, non un altro nome per il livello massimo di ragionamento di Wonder. [2]

Questa distinzione conta prima di qualsiasi confronto tra benchmark. Se scelgo un modello per un agente API esistente, parto dalla colonna Wonder. Se cerco un agente da terminale e sono disposto a sottoscrivere un abbonamento, Full entra nel confronto insieme agli strumenti e ai limiti di Muse Code.

L’abbonamento è anche legato alla credenziale Muse Code creata durante la configurazione iniziale. La documentazione di Meta specifica che questa credenziale è riservata a Muse Code; le chiavi API aggiuntive sono fatturate separatamente a consumo. Pagare il piano non rende Full disponibile a un client API qualsiasi. [6]

Questa distinzione è più utile che considerare il lancio una ripetizione della confusione sui benchmark di Muse Spark 1.3. Qui Meta documenta chiaramente la separazione. Chi legge deve comunque associare ogni risultato al modello giusto.

Cosa mostrano davvero i benchmark di Muse Wonder?

La differenza fra Wonder e Full è piccola in un test di programmazione e maggiore in un altro. Meta Developers pubblica risultati quasi identici su DeepSWE 1.1, mentre Full supera Wonder di 4,4 punti percentuali su SWE-Marathon. Conviene quindi guardare le singole attività, anziché presumere che ogni risultato di Full descriva un grande miglioramento. [3]

Il vantaggio di Full è di 0,2 punti percentuali su DeepSWE e di 4,4 su SWE-Marathon. Senza stime dell’incertezza o esecuzioni ripetute, non userei il primo divario per sostenere un vantaggio significativo. Il secondo mi dà una ragione più concreta per provare Full su un progetto impegnativo che richiede molti passaggi.

La scheda del modello di Meta spiega perché le righe vanno lette separatamente. DeepSWE 1.1 comprende 113 attività in 91 repository, valutate tramite test funzionali e di regressione. Meta attribuisce i risultati di Wonder e Full a Datacurve. SWE-Marathon valuta invece progetti di ampia portata tramite i loro test eseguibili, e la scheda attribuisce quella riga ad Abundant AI. [4]

La stessa scheda dice che i risultati dei concorrenti su SWE-Marathon usano prodotti come Codex e Claude Code. L’intera riga, quindi, non è un confronto controllato con un harness comune. L’harness è il software attorno al modello: strumenti, istruzioni e ciclo di esecuzione. Questo non annulla i risultati, ma cambia la domanda a cui rispondono. Confrontano i sistemi valutati, senza isolare la qualità del modello. È lo stesso problema che spiego nell’analisi delle capacità pratiche diverse dietro punteggi di benchmark simili. [4]

Quanto costa l’API di Muse Wonder?

Meta Developers indica per Wonder 4 dollari per milione di token di input senza cache, 0,20 per milione di input in cache e 20 per milione di output. Wonder non ha uno sconto Contributor mode nell’API, e i prezzi pubblicati non prevedono un supplemento per contesti lunghi. Sono le tariffe di Wonder, non prezzi per token di Full. [5]

Una richiesta ipotetica con 100.000 token di input senza cache e 10.000 di output costa 0,60 dollari: 0,40 per l’input e 0,20 per l’output. Se tutto l’input fosse servito dalla cache, gli stessi volumi costerebbero 0,22 dollari. Gli esempi escludono strumenti fatturati separatamente e richieste successive. Meta addebita 2,50 dollari ogni 1.000 ricerche web, oltre ai token. [5]

Per un agente, il costo utile è quello dell’intero tentativo. Chiamate ripetute agli strumenti inviano più contesto, gli approcci falliti consumano token e una correzione può richiedere un’altra esecuzione. Un listino mi dice quanto costano i token. Non mi dice quanti ne serviranno a Wonder per consegnare una modifica che posso accettare.

Perciò non assocerei le tariffe API di Wonder al risultato migliore di Full per presentare il tutto come un affare. Unirei il risultato di un modello al prezzo di un altro. Non dividerei neppure il prezzo mensile di un abbonamento per un numero presunto di attività: il risultato dipenderebbe dall’uso effettivo e dai limiti del piano. La differenza fra prezzo per token e costo misurato per attività conta anche nel confronto di GPT-6.1 Sol.

Active Memory sostituisce la gestione del contesto?

Meta AI Research descrive Active Memory come la capacità di conservare informazioni rilevanti tra le conversazioni. Active Focus indica invece il proseguimento verso un obiettivo nonostante ostacoli e cambiamenti. Sono capacità utili da valutare, ma queste descrizioni da sole non dicono come un determinato agente API conserverà lo stato del progetto. [7]

L’integrazione deve ancora rispondere a una domanda pratica: quali informazioni riceverà il modello quando il lavoro riprenderà? Un modello capace di recuperare un requisito è utile solo se il sistema lo conserva e rende disponibili le informazioni giuste. Lo proverei con un requisito modificato e una vecchia nota in conflitto, poi controllerei quale dei due segue l’agente.

Per questo manterrei una gestione esplicita del contesto per gli agenti di programmazione mentre provo Wonder. Una finestra ampia e una funzione di memoria annunciata non rendono evidenti le istruzioni attuali del repository, le decisioni accettate o il lavoro incompleto. Il risultato utile è un agente che riprende con i vincoli giusti, non uno che ricorda soltanto una frase.

Quando Full varrebbe l’abbonamento?

Per me, Full si guadagnerebbe il suo posto completando lavori difficili con meno correzioni dell’alternativa disponibile tramite API. Il divario maggiore su SWE-Marathon mi dà una ragione per verificarlo su attività lunghe, ma misurerei risultati accettati e tempo trascorso prima di assegnargli un ruolo.

Partirei da una modifica nota del repository, con lo stesso commit iniziale e gli stessi test di accettazione, e registrerei sia i tentativi falliti sia quelli riusciti. Per Wonder tramite API conserverei gli addebiti per token e strumenti. Per Full in Muse Code annoterei consumo dell’abbonamento, attese e mie modifiche successive. Così manterrei distinta la scelta del modello che chiamo da quella del prodotto a cui mi abbono.

Prima di usare codice privato nella prova, controllerei anche Contributor mode. La documentazione degli abbonamenti Meta dice che è attivo per impostazione predefinita e permette l’addestramento sui contenuti inviati in cambio di maggiore utilizzo. Si può disattivare, e Full rimane disponibile nei piani compatibili in entrambe le modalità. La scelta fa parte della preparazione del test perché cambia le condizioni di trattamento del codice. [6]

La mia prima domanda davanti a un risultato notevole di Muse Wonder è quindi il nome esatto del modello. Chiarito questo, posso scegliere un test adatto all’accesso che ho davvero e capire quanto costa completare il mio lavoro.