Moonshot apre Kimi a Codex e Claude Code, ridefinendo il conflitto tra Anthropic e Moonshot
Moonshot AI ha aperto Kimi a due ambienti di coding rivali il 2 settembre, nonostante rimanga irrisolta una disputa tra Anthropic e Moonshot relativa all'addestramento e all'accesso ai modelli. L'API Kimi ora accetta richieste OpenAI Responses API da Codex e richieste Anthropic Messages API da Claude Code. Moonshot afferma che gli sviluppatori possono connettersi senza un convertitore di formato né un proxy locale.
Il cambiamento può sembrare un aggiornamento di compatibilità. È più rilevante perché gli agenti di coding dipendono da un comportamento dettagliato dei protocolli, non dalla semplice generazione di testo. Il client invia definizioni di strumenti, riceve chiamate strutturate, restituisce i risultati dell'esecuzione e ripete il ciclo fino al termine dell'attività.
Moonshot sta quindi cercando di separare l'interfaccia di coding dall'azienda che l'ha creata. Codex può restare il client dello sviluppatore mentre un modello Kimi sostituisce un modello OpenAI. Claude Code può mantenere il suo workflow familiare mentre le richieste viaggiano verso Moonshot anziché Anthropic.
La strategia sottopone OpenAI e Anthropic a un tipo diverso di pressione. Nessuna delle due perde il controllo del proprio client o protocollo. Tuttavia, entrambe devono ora confrontarsi con un altro provider che usa la compatibilità per competere all'interno dei workflow che hanno contribuito a creare.
Il supporto Codex dell'API Kimi rimuove una barriera pratica
Il cambiamento più importante di Moonshot è il supporto nativo dei protocolli, non una nuova interfaccia di coding.
L'annuncio di Moonshot del 2 settembre afferma che Kimi supporta il formato Responses API utilizzato da Codex. Supporta anche il formato Messages API associato ad Anthropic e Claude Code. L'azienda ha pubblicato guide di configurazione separate per ciascun percorso.
Per Codex, Moonshot documenta un provider personalizzato che utilizza il suo URL di base API e un formato wire Responses. Un provider personalizzato indica al client dove inviare le richieste al modello e quale protocollo utilizzare. Lo sviluppatore può quindi selezionare un modello Kimi continuando a lavorare in Codex.
Moonshot identifica kimi-k3, kimi-k2.7-code-highspeed, kimi-k2.7-code e kimi-k2.6 come opzioni compatibili. La disponibilità può comunque dipendere dall'account, dall'endpoint, dalla versione del client e dalla configurazione corrente della piattaforma.
La configurazione Codex è significativa perché elimina un livello di traduzione spesso richiesto dalle integrazioni precedenti. Un adattatore locale riceverebbe un formato di richiesta, lo riscriverebbe per un'altra API e tradurrebbe nuovamente la risposta in streaming.
Ogni adattatore diventa un ulteriore elemento mobile. Può gestire male le chiamate agli strumenti, omettere un tipo di evento, esporre una credenziale o cessare di corrispondere al client dopo un aggiornamento. Complica anche il debugging, perché un errore può originarsi nel client, nell'adattatore, nella rete o nel modello upstream.
Il supporto nativo di Responses riduce questa superficie di integrazione. Non garantisce un comportamento identico a quello di un modello ospitato da OpenAI. Significa che il server di Moonshot accetta il contratto wire previsto dal client.
Questa distinzione conta perché Codex fa più che inviare un prompt e stampare una risposta. La spiegazione di OpenAI sul ciclo dell'agente Codex descrive scambi ripetuti tra l'inferenza del modello e l'esecuzione degli strumenti. Il client trasporta messaggi, istruzioni, definizioni degli strumenti, elementi relativi al ragionamento e risultati degli strumenti attraverso questi scambi.
Un server compatibile deve preservare una quantità sufficiente di quella struttura affinché il ciclo possa continuare. La sola generazione di testo non è sufficiente. Eventi in streaming, identificatori delle chiamate agli strumenti, elementi di input e comportamento di terminazione influiscono tutti sull'affidabilità del funzionamento del client.
Il percorso Codex dell'API Kimi si rivolge quindi agli sviluppatori a cui piace già l'interfaccia Codex ma desiderano un altro backend di modelli. Offre inoltre ai team un modo per confrontare i modelli senza sostituire il proprio workflow nel terminale o ricostruire gli script circostanti.
La stessa logica si applica all'esperienza desktop quando sono disponibili provider personalizzati. Secondo la documentazione di Moonshot, un selettore di modelli può mostrare un'etichetta personalizzata generica anche quando il backend configurato è Kimi. Questa limitazione dell'interfaccia può rendere importante la verifica.
Gli sviluppatori dovrebbero confermare il provider attivo tramite configurazione, log delle richieste e test controllati. Una risposta riuscita non stabilisce di per sé quale backend abbia gestito la richiesta.
Moonshot afferma inoltre che la sua implementazione di Responses accetta input di testo e immagini, ma al momento non supporta input video. Questa limitazione restringe il significato del supporto nativo. La compatibilità del protocollo può essere abbastanza ampia per il lavoro di coding senza coprire ogni possibile input o funzionalità della piattaforma.
Il vantaggio immediato resta chiaro. Gli sviluppatori non devono più mantenere un bridge di protocollo locale per il percorso documentato. Questo riduce il lavoro di configurazione e offre a Moonshot un accesso più diretto a un workflow consolidato per gli agenti.
Il supporto Kimi per Claude Code trasforma un client in un canale di distribuzione
Il percorso API configurabile di Claude Code consente a Moonshot di competere per l'inferenza senza dover costruire un client altrettanto familiare.
La configurazione Kimi per Claude Code utilizza l'endpoint compatibile con Anthropic di Moonshot. Claude Code invia richieste Messages API, mentre il modello Kimi selezionato produce l'inferenza. Il client continua a gestire file, strumenti, autorizzazioni e il suo workflow interattivo.
La guida Claude Code di Moonshot descrive l'endpoint e le credenziali richiesti. Questo sostituisce il modello precedente di installare un relay locale esclusivamente per convertire il formato delle richieste.
La Messages API di Anthropic è un'interfaccia strutturata per conversazioni, blocchi di contenuto e utilizzo degli strumenti. Supportarne la struttura consente a un altro provider di ricevere richieste da software progettato attorno a quel contratto. Non trasforma un modello Kimi in Claude né trasferisce il comportamento dei modelli Anthropic.
Questa distinzione dovrebbe rimanere visibile. Claude Code è il client agente. Claude è la famiglia di modelli di Anthropic. Un utente può eseguire il client contro un endpoint esterno compatibile, ma l'output risultante proviene dal provider configurato.
La stessa documentazione sui gateway di Anthropic riconosce che i formati API supportati possono connettere Claude Code ai gateway. Dichiara inoltre che Anthropic non approva, non gestisce né verifica i prodotti gateway di terze parti. Più esplicitamente, Anthropic afferma di non supportare l'instradamento di Claude Code verso modelli non-Claude tramite un gateway.
Moonshot non sostiene che Anthropic supporti Kimi. Sta implementando il formato di richiesta previsto dal client. Questa differenza separa l'interoperabilità tecnica da una partnership commerciale.
La configurazione offre agli sviluppatori un caso d'uso concreto. Un team può mantenere un solo client di coding, indirizzare un ambiente di test a Kimi ed eseguire la stessa attività di repository contro un altro backend. Può confrontare la qualità delle patch, l'affidabilità degli strumenti, la latenza e il recupero dagli errori usando controlli familiari.
Il workflow riduce anche i costi di passaggio. In precedenza, valutare un altro modello poteva richiedere l'adozione del suo client dedicato o il mantenimento di un proxy. La compatibilità nativa trasforma la decisione in qualcosa di più simile a una modifica della configurazione.
Questo crea pressione sui provider di modelli perché la fedeltà degli utenti può legarsi alla shell dell'agente anziché al modello sottostante. Uno sviluppatore può preferire un'interfaccia scegliendo al contempo modelli diversi per la revisione del codice, l'esplorazione dei repository, il debugging assistito da immagini o modifiche di lunga durata.
Di conseguenza, i protocolli diventano canali di distribuzione. Una volta che un client accetta endpoint personalizzati, ogni provider sufficientemente compatibile può cercare di ottenere accesso ai suoi utenti. Il vendor originario mantiene il controllo sull'evoluzione del client, ma non controlla più ogni richiesta di inferenza.
Esistono dei limiti. Claude Code aggiunge funzionalità nel tempo e le implementazioni esterne devono tenere il passo con i campi di richiesta e risposta richiesti da tali funzionalità. Anthropic avverte che i gateway possono compromettere le capacità quando non inoltrano nuovi comportamenti.
Un endpoint diretto di terze parti affronta lo stesso onere di compatibilità. Se Claude Code introduce un altro schema per gli strumenti, header, blocco di contenuto o evento in streaming, Moonshot deve implementarlo correttamente. “Nativo” descrive l'attuale percorso di integrazione, non una parità di funzionalità permanente.
Anche l'autenticazione modifica il confine di fiducia. Le richieste inviate a Moonshot sono regolate dal servizio di Moonshot, dalla gestione dei dati, dalle regole di conservazione e dalla disponibilità regionale. Non vengono elaborate nell'ambito di un account Anthropic solo perché Claude Code resta sullo schermo.
I team dovrebbero trattare la selezione del provider come una decisione infrastrutturale. Codice sorgente, prompt, output degli strumenti e contesto del repository possono passare attraverso l'endpoint configurato. Le revisioni di sicurezza devono seguire il backend che riceve tale materiale.
Il percorso Kimi per Claude Code è quindi al tempo stesso più semplice e più rilevante di un normale plugin. Consente a Moonshot di entrare in un workflow identificato con un concorrente assumendosi al contempo la responsabilità del servizio di modelli sottostante.
Il conflitto tra Anthropic e Moonshot riguarda il controllo, non la compatibilità
La tensione centrale è che l'apertura tecnica può coesistere con la sfiducia commerciale.
La parola chiave principale, anthropic moonshot, rimanda a una relazione conflittuale anziché cooperativa. La compatibilità di Moonshot con Messages non dovrebbe essere scambiata per un accordo con Anthropic.
Il 23 febbraio 2026, Anthropic ha accusato pubblicamente Moonshot, DeepSeek e MiniMax di aver condotto quelle che ha definito campagne di distillazione su scala industriale. La distillazione addestra un modello utilizzando output generati da un altro modello, sebbene il metodo possa essere legittimo quando accesso e autorizzazioni lo consentono.
Anthropic ha affermato che le tre aziende hanno generato collettivamente oltre 16 milioni di scambi con Claude tramite circa 24.000 account fraudolenti. Ha attribuito a Moonshot oltre 3,4 milioni di scambi e ha dichiarato che l'attività prendeva di mira coding, utilizzo degli strumenti, ragionamento, analisi dei dati, uso del computer e visione.
Si tratta di accuse di Anthropic, non di conclusioni accertate in modo indipendente nel materiale esaminato per questo articolo. La nuova compatibilità API annunciata da Moonshot non le conferma né le risolve. Non si dovrebbe trarre alcuna inferenza sull'addestramento di Kimi basandosi esclusivamente sul suo supporto del formato di messaggio di Anthropic.
Ciononostante, il contesto storico cambia la lettura di questo lancio. Anthropic sostiene che gli output dei modelli e le restrizioni di accesso richiedano una protezione più rigorosa. Moonshot, nel frattempo, sta rendendo più semplice usare con un modello concorrente l'interfaccia associata ad Anthropic.
Il conflitto tra Anthropic e Moonshot opera quindi su due livelli. Uno riguarda chi può accedere alle capacità dei modelli e a quali condizioni. L'altro riguarda se un protocollo client possa funzionare come interfaccia ampiamente implementata.
Le accuse di distillazione di Anthropic sottolineano il primo livello. Il rilascio di compatibilità di Moonshot sottolinea il secondo. Entrambe le parti stanno contendendo il controllo, ma su componenti diversi dello stack tecnologico.
Il protocollo in sé non contiene l'intero comportamento del modello. Definisce il modo in cui richieste, contenuti, strumenti e risposte viaggiano tra client e server. Più provider possono implementare interfacce simili producendo al contempo risultati diversi.
Questa separazione è familiare in altri mercati informatici. Le applicazioni possono parlare un protocollo di database condiviso senza utilizzare lo stesso motore di database. I servizi cloud possono esporre interfacce compatibili con l'archiviazione di oggetti senza corrispondere a ogni dettaglio operativo.
Gli agenti AI rendono la separazione più difficile perché il comportamento del modello influenza il ciclo del client. Un agente di coding si aspetta che il modello selezioni gli strumenti, interpreti i risultati, produca modifiche valide e si riprenda dopo gli errori. La compatibilità formale delle API è necessaria, ma è la compatibilità comportamentale a determinare se l’esperienza resta utile.
Moonshot trae vantaggio se gli sviluppatori considerano Codex e Claude Code come interfacce neutre. OpenAI e Anthropic ne traggono vantaggio se gli utenti associano i loro client a modelli ottimizzati specificamente per tali client. La questione competitiva è quale delle due visioni diventerà dominante.
Se l’interfaccia diventa indipendente, instradare i modelli diventa più semplice. Le aziende possono negoziare l’accesso ai provider, applicare politiche regionali diverse o assegnare modelli a carichi di lavoro specifici. Gli sviluppatori possono mantenere le proprie abitudini mentre cambiano fornitori di inferenza.
Se prevale una profonda ottimizzazione modello-client, i rivali compatibili potrebbero restare secondari. Differenze sottili nelle chiamate agli strumenti, nella gestione del contesto, nella cache, nei controlli del ragionamento e nel recupero dagli errori possono superare la comodità di un endpoint condiviso.
Per questo il cambiamento del 2 settembre non è semplicemente un’altra casella da spuntare nelle API. Verifica se la distribuzione degli agenti di coding possa essere separata dalla proprietà del modello.
I formati nativi non garantiscono comunque prestazioni native
Una connessione avviata con successo può comunque fallire nelle parti più impegnative dell’esecuzione di un agente.
L’annuncio di Moonshot stabilisce un percorso documentato. Non fornisce prove indipendenti che ogni funzionalità di Codex o Claude Code si comporti in modo identico nei modelli Kimi elencati.
La prima incertezza riguarda la copertura del protocollo. Responses e Messages non sono singoli campi di testo. Comprendono streaming, contenuti multimodali, schemi degli strumenti, risultati degli strumenti, metadati, report di utilizzo e strutture degli errori.
Un provider può accettare la richiesta principale gestendo però i casi limite in modo diverso. Le chiamate parallele agli strumenti possono arrivare in un ordine differente. Uno stream può omettere un evento atteso dal client. L’annullamento può comportarsi diversamente durante un comando lungo.
La seconda incertezza riguarda l’adattamento comportamentale. I client di coding si affidano ai modelli affinché seguano istruzioni specializzate e usino gli strumenti con attenzione. Un modello che ottiene buoni risultati in un benchmark di coding può comunque avere difficoltà con i prompt di un client specifico o con il flusso di lavoro di un repository.
Una valutazione utile dovrebbe quindi misurare il completamento dei compiti anziché il successo della connessione. I team devono verificare se il modello modifica i file corretti, rispetta le istruzioni del progetto, interpreta l’output dei comandi e si ferma quando è richiesta un’approvazione.
La terza incertezza è l’evoluzione dei client. OpenAI e Anthropic possono modificare i loro client con l’arrivo di nuove capacità. I provider esterni devono seguire tali cambiamenti senza controllarne la tempistica.
La descrizione di Codex fornita da OpenAI mostra quanto sia diventato dettagliato il ciclo dell’agente. Gli output delle chiamate agli strumenti vengono aggiunti alle richieste successive e il contesto della conversazione si espande attraverso turni ripetuti. Le modifiche a questi oggetti possono influire sulla compatibilità anche quando l’endpoint rimane /responses.
Anthropic rivolge un avvertimento simile agli operatori di gateway. La sua documentazione afferma che le nuove capacità di Claude Code possono fallire quando un gateway non le inoltra. Un provider che implementa direttamente il formato affronta un rischio di manutenzione comparabile.
La quarta incertezza riguarda la governance dei dati. Sostituire il backend cambia il luogo in cui transitano codice e contesto. Le organizzazioni non possono presumere che i controlli associati a un account OpenAI o Anthropic seguano la richiesta fino a Moonshot.
Una revisione della sicurezza dovrebbe coprire archiviazione delle credenziali, conservazione, logging, elaborazione geografica, risposta agli incidenti e controllo degli accessi. I team dovrebbero anche identificare quali file del repository l’agente possa leggere prima di inviare un’attività reale di produzione.
La quinta incertezza è l’osservabilità. Un’etichetta generica del modello può rendere meno evidente il backend attivo. Le organizzazioni hanno bisogno di log che colleghino ogni richiesta a un provider, a un identificatore del modello, a uno sviluppatore, a un repository e a una policy.
È qui che una base di conoscenza ingegneristica interna può essere utile. I team possono registrare configurazioni approvate, risultati delle valutazioni, incompatibilità note e procedure di rollback senza affidarsi alla memoria individuale.
Nessuna di queste preoccupazioni invalida il rilascio. Definiscono cosa dovrebbe significare nella pratica il “supporto nativo”. Significa che il provider ha rimosso un componente di traduzione necessario, non che ogni funzionalità del client abbia raggiunto una parità permanente.
Una prova responsabile inizia con un repository rappresentativo e permessi limitati. Include attività che coinvolgono ricerca di file, modifiche a più file, esecuzione di test, fallimento di comandi, input di immagini e lunghe sequenze di strumenti.
I team dovrebbero confrontare la patch finale e il processo che l’ha prodotta. Un risultato corretto ottenuto tramite accessi non necessari ai file o comandi ripetutamente falliti segnala comunque un rischio operativo.
Le migliori prove arriveranno da un utilizzo prolungato attraverso gli aggiornamenti dei client. Moonshot ha reso l’adozione più semplice. Ora deve dimostrare che la compatibilità resti affidabile dopo il primo prompt riuscito.
Cosa dovrebbero osservare gli sviluppatori dopo il 2 settembre
Tre segnali determineranno se questo rilascio cambierà la competizione tra modelli o resterà una comoda opzione di integrazione.
Il primo segnale è la parità delle funzionalità attraverso gli aggiornamenti dei client. Gli sviluppatori dovrebbero osservare se le nuove capacità di Codex e Claude Code funzionano rapidamente tramite gli endpoint di Moonshot.
Ciò include nuovi tipi di contenuto, definizioni degli strumenti, eventi di streaming, controlli del ragionamento e comportamento dell’autenticazione. Un supporto rapido rafforzerebbe l’affermazione di Moonshot di poter operare come provider di prima classe. Problemi ricorrenti la indebolirebbero.
La documentazione pubblica offrirà un indicatore precoce. Matrici di compatibilità chiare, requisiti di versione, limitazioni note e aggiornamenti datati contano più di una generica dichiarazione di supporto.
Il secondo segnale è la prestazione verificata sui carichi di lavoro. I test indipendenti dovrebbero esaminare attività complete sui repository anziché singole domande di coding isolate. Misure utili includono patch riuscite, percentuali di test superati, chiamate agli strumenti non necessarie, latenza, recupero dopo errori dei comandi e tempo di correzione umana.
Il confronto rilevante non riguarda semplicemente Kimi contro Claude o un modello OpenAI in una finestra di chat. Riguarda Kimi all’interno dell’esatto ciclo del client che gli sviluppatori intendono utilizzare.
Modelli diversi possono prevalere su carichi di lavoro diversi. Un modello rapido può essere adatto alla ricerca nei repository e alle trasformazioni di routine. Un modello più riflessivo può offrire prestazioni migliori nelle modifiche architetturali o nel debugging complesso. La compatibilità nativa rende questi confronti più facili, ma non li decide.
Il terzo segnale è il modo in cui OpenAI e Anthropic rispondono alla portabilità tra provider. Possono approfondire l’ottimizzazione modello-client, restringere le politiche sui provider supportati, migliorare l’instradamento aziendale o rendere più attraenti le scelte cloud ufficiali.
Anthropic traccia già un confine tra i gateway che documenta e i modelli non-Claude che non supporta. La controversia irrisolta tra Anthropic e Moonshot offre un’altra ragione per osservare se quel confine diventerà più rigido.
OpenAI ha descritto esplicitamente l’endpoint Responses di Codex come configurabile. Questa scelta architetturale favorisce la portabilità, sebbene i dettagli di implementazione e le configurazioni supportate possano cambiare. Il rilascio di Moonshot mette alla prova fino a che punto gli sviluppatori utilizzeranno questa flessibilità.
Per gli sviluppatori individuali, l’azione immediata è semplice. Considerate Kimi come un altro backend da valutare, non come un sostituto identitario immediato. Iniziate con un branch usa e getta, confermate il modello attivo, limitate le credenziali e controllate ogni patch.
Per i responsabili dell’ingegneria, la questione più ampia riguarda la dipendenza. L’organizzazione desidera un unico fornitore integrato, oppure un livello client capace di instradare tra diversi provider? La compatibilità rende il secondo approccio più pratico, ma trasferisce anche al cliente il lavoro di test e governance.
Conservate un breve registro di valutazione in una base di conoscenza personale. Registrate la versione del client, il modello selezionato, il tipo di repository, l’attività, gli errori osservati e la revisione umana finale. Ripetere lo stesso test dopo gli aggiornamenti rivelerà se la compatibilità sta migliorando.
Moonshot ha rimosso una barriera visibile tra Kimi, Codex e Claude Code. La prossima è la fiducia conquistata attraverso esecuzioni ripetute degli agenti. Il supporto nativo del protocollo resterà affidabile quando i client cambieranno, le attività diventeranno più lunghe e il conflitto tra Anthropic e Moonshot manterrà in primo piano le questioni di accesso e controllo?
