Migrare a Kimi K3.1 Pro: risolvere i 400, fare attenzione al livello di ragionamento predefinito «max» e non sbagliare a digitare Highspeed

Kimi K3.1 Pro è disponibile in Kimi Code, nell’API di Moonshot con il nome kimi-k3.1-pro e su AIHubMix con lo stesso ID. Moonshot applica gli stessi vincoli sui parametri di Kimi K3, quindi il codice già funzionante con K3 dovrebbe passare al nuovo modello cambiando l’ID e avviando una nuova sessione. Il codice scritto per K2.x ha invece una scadenza sulla piattaforma di Moonshot: dal 31 ottobre 2026 Moonshot impedirà ai nuovi utenti registrati di usare la serie K2 e prevede di ritirarla entro la fine di dicembre. È anche il codice che ha più probabilità di rompersi, perché tende a inviare un valore di temperature o a disattivare il ragionamento, e con K3.1 Pro nessuna delle due cose è supportata. Inoltre, il codice che non imposta mai un livello di ragionamento viene eseguito al livello massimo, con un consumo di token superiore alle aspettative e, in Kimi Code, un consumo di quota maggiore rispetto a K3.

Questo articolo elenca gli errori più evidenti (i 400 e un 404), quelli che non si notano subito (la fattura, la cache, l’ID Highspeed) e come configurare Claude Code e Codex per K3.1 Pro tramite AIHubMix. Le regole di K3.1 Pro provengono dalla documentazione dei modelli Kimi Code e dal relativo riferimento ai parametri dei modelli di Moonshot, che assegna a entrambi gli ID di K3.1 Pro «gli stessi vincoli sui parametri di kimi-k3». Le regole indicate come relative a K3 provengono dalle guide di Moonshot su K3 e non sono state verificate di nuovo su K3.1 Pro. I testi degli errori sono citati dalla documentazione, da segnalazioni pubbliche, dal test di K3 di AIHubMix a luglio e dai controlli di AIHubMix su K3.1 Pro del 24 ottobre 2026. I controlli hanno riguardato gli ID principali e gli ID del canale di programmazione coding-kimi-k3.1-pro e coding-kimi-k3.1-pro-highspeed. Per ogni affermazione è indicata la fonte.

Quale percorso usi?

Nell’API di Moonshot e su AIHubMix, gli ID sono kimi-k3.1-pro e kimi-k3.1-pro-highspeed. In Kimi Code sono k3.1-pro e k3.1-pro-highspeed. Una configurazione client individuata il 21 ottobre associava k3 e kimi-for-coding a un modello k3.1, ma la documentazione di Kimi Code ora indica k3 come K3 e kimi-for-coding come K2.8 Preview: seleziona quindi esplicitamente K3.1 Pro. Conta anche il tuo piano: in Kimi Code, K3.1 Pro richiede Plus o un piano superiore (Pro per il contesto da 1M), mentre Highspeed richiede Pro o un piano superiore. Nei piani precedenti, serve Moderato o superiore, e Allegretto per il contesto da 1M e per Highspeed.

Le date relative a K2 provengono da Moonshot. Dal 31 ottobre 2026, i modelli della serie K2 non saranno più disponibili per i nuovi utenti registrati e il ritiro di tutti è previsto entro la fine di dicembre 2026. Moonshot non ha annunciato una data di ritiro per K3. Il 24 ottobre AIHubMix elencava ancora K2.6 e K2.7 Code, senza indicare una data di ritiro.

Gli errori più evidenti

Ragionamento disattivato: HTTP 400 oppure nessun ragionamento

Cosa vedrai: un errore HTTP 400 in Kimi Code. La documentazione di Kimi Code di Moonshot afferma che i modelli K3.1 Pro «supportano solo la modalità di ragionamento. Le richieste con il ragionamento disattivato vengono rifiutate». La documentazione non riporta il corpo dell’errore. Nell’API di Moonshot, K3.1 Pro adotta i vincoli di K3, che ragiona sempre. Tramite AIHubMix non si riceve un 400: il 24 ottobre, thinking: {"type": "disabled"} ha restituito 200 con entrambi gli ID principali, sia tramite Chat Completions sia tramite Messages, senza ragionamento nella risposta. In questo caso l’errore è silenzioso, quindi controlla che le risposte includano il ragionamento.

Da dove ha origine: dal codice K2.x che disattiva il ragionamento per ottenere risposte più rapide, per esempio con extra_body={"thinking": {"type": "disabled"}}, e dagli strumenti che inviano un livello di ragionamento off, none o disabled (vedi la sezione successiva).

Soluzione: rimuovi l’opzione. Per mantenere breve il ragionamento, invia invece reasoning_effort: "low".

Un blocco «enabled» rimasto nella configurazione è un caso diverso. Nel controllo del 24 ottobre, AIHubMix ha inviato a K3.1 Pro il parametro K2.x thinking: {"type": "enabled"} e ha ricevuto 200, sia con gli ID principali sia sul canale di programmazione. La documentazione di Moonshot definisce thinking «un parametro di richiesta esclusivo di K2.x» e una guida alla risoluzione dei problemi di terze parti indica la presenza di un blocco non rimosso come causa di errori 400 dopo il passaggio da K2.x a K3: eliminalo comunque.

Se mantieni K2.7 Code come opzione di ripiego fino al suo ritiro, lascia attivo il ragionamento. La guida di Moonshot per Claude Code documenta l’errore 400 invalid thinking: only type=enabled is allowed for this model per K2.7 Code quando il ragionamento è disattivato.

Valori del livello di ragionamento: off, none e valori sconosciuti restituiscono 400

Cosa vedrai: un errore HTTP 400 se il livello di ragionamento è off, none, disabled o un valore non riconosciuto da Kimi Code. K3.1 Pro prevede tre livelli: low, high e max. La documentazione di Kimi Code di Moonshot spiega come vengono associati a questi livelli i valori inviati dagli strumenti di terze parti:

Per K3.1 Pro, l’API di Moonshot documenta solo low, high e max, con max come valore predefinito, e non descrive alcuna mappatura. Su AIHubMix, il 24 ottobre low, medium, high, max e xhigh hanno restituito tutti 200 con tutti e quattro gli ID di K3.1 Pro. Con kimi-k3.1-pro, anche off e un valore sconosciuto hanno restituito 200, con ragionamento, mentre none ha restituito 200 senza alcun ragionamento. Su AIHubMix questi casi causano errori silenziosi, non un 400.

Il lato meno evidente: non esiste un livello medium. Uno strumento impostato su medium viene portato a high, mentre uno impostato su xhigh passa a max, il livello più costoso.

Soluzione: invia esplicitamente low, high o max e verifica cosa invia davvero il tuo strumento.

"temperatura non valida: per questo modello è consentito solo 1"

Cosa vedrai: 400 invalid temperature: only 1 is allowed for this model. Nel controllo del 24 ottobre, AIHubMix ha ricevuto esattamente questo errore da kimi-k3.1-pro e kimi-k3.1-pro-highspeed dopo aver inviato temperature: 0.2. Lo stesso messaggio era stato segnalato nell’API di Moonshot per K3 il 3 ottobre 2026 e nell’endpoint di Kimi Code per k3 il 21 ottobre.

Perché: il riferimento ai parametri di Moonshot assegna a K3.1 Pro i vincoli di K3: temperature fissata a 1.0, top_p a 0.95, n a 1 ed entrambi i parametri penalty a 0; gli altri valori restituiscono un errore. Anche K2.6 aveva un valore fisso, 0.6 con il ragionamento disattivato, quindi il codice che invia ancora 0.6 è il sospettato più probabile.

L’eccezione che nasconde il problema: nello stesso controllo, il canale di programmazione di AIHubMix ha accettato temperature: 0.2. Il codice testato soltanto su quel canale può comunque rompersi con gli ID principali o nell’API di Moonshot.

La trappola che lo nasconde ancora di più: molti framework riconoscono i modelli Kimi dal prefisso kimi- e rimuovono temperature per questi modelli. Gli ID di Kimi Code k3.1-pro e k3.1-pro-highspeed non hanno quel prefisso, e neppure gli ID del canale di programmazione di AIHubMix, che iniziano con coding-. Un problema di Hermes Agent ha individuato esattamente questo comportamento con K3. Il percorso principale della chat ometteva temperature, ma una chiamata ausiliaria a k3 continuava a inviarlo e riceveva ogni volta un errore 400.

Soluzione: non inviare affatto temperature, top_p, n, presence_penalty o frequency_penalty. Identifica la famiglia del modello, non il prefisso del nome.

Per verificare un endpoint, invia una richiesta con un valore di temperature:

curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer $AIHUBMIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "kimi-k3.1-pro", "temperature": 0.2, "messages": [{"role": "user", "content": "hi"}]}'

Il 24 ottobre questa richiesta ha restituito il 400 indicato sopra. Eseguila con ogni ID modello usato dal tuo codice: il canale di programmazione ha risposto 200 alla stessa richiesta.

Codex tramite AIHubMix: 404 sull’API Responses

Cosa vedrai: un errore HTTP 404 con The model kimi-k3.1-pro is not available on this endpoint. Nel controllo del 24 ottobre, AIHubMix lo ha ricevuto dall’API Responses con entrambi gli ID principali, mentre Chat Completions e Messages hanno risposto normalmente.

Soluzione: Codex supporta solo l’API Responses, quindi indirizzalo a coding-kimi-k3.1-pro, che nello stesso controllo ha risposto alle richieste Responses. AIHubMix definisce il canale di programmazione un’anteprima di valutazione non consigliata per la produzione; alcune richieste hanno restituito un 404 temporaneo, «The requested resource was not found», quindi riprova una volta prima di iniziare la diagnostica. Usa questo canale finché AIHubMix non aggiunge il supporto all’API Responses per gli ID principali. Claude Code usa Messages e funziona con gli ID principali.

Limiti di stop

Cosa vedrai: nel test di K3 di AIHubMix a luglio sono comparsi questi due messaggi:

• Invalid request: stop array too long. Expected an array with maximum length 5, but got an array with length 6 instead
• Invalid request: stop sequence must not be longer than 32, but got 33 instead

Perché: K3 accetta al massimo cinque sequenze stop, ciascuna fino a 32 byte, e l’API Messages applica gli stessi controlli a stop_sequences. Moonshot assegna a K3.1 Pro gli stessi vincoli sui parametri, quindi aspettati gli stessi limiti.

Soluzione: riduci l’elenco. Tieni presente che 32 byte corrispondono a meno di 32 caratteri in cinese o giapponese.

Codex nell’API di Moonshot: «web_search.search_context_size is not supported» (guida per K3)

Cosa vedrai: 400 web_search.search_context_size is not supported, citato dalla guida di Moonshot per Codex, scritta per K3. Il 24 ottobre, una richiesta Responses con quel campo tramite il canale di programmazione di AIHubMix ha restituito 200: quindi questo errore proviene dall’endpoint di Moonshot.

Soluzione: rimuovi search_context_size dalla configurazione di Codex o dalla definizione dello strumento. Codex non lo invia per impostazione predefinita.

Gli errori silenziosi

Questi casi non restituiscono errori. Te ne accorgi in seguito, dalla fattura, dalla quota del tuo piano o dalla qualità dell’output.

Livello di ragionamento e sessioni

• Il valore predefinito è max, e in Kimi Code questa è una novità. K3.1 Pro usa max per impostazione predefinita. In Kimi Code, K3 usava high come valore predefinito: di conseguenza, una sessione che non imposta mai un livello di ragionamento ora ragiona più a fondo, usa più token e consuma la quota più rapidamente. Nell’API di Moonshot, sia K3 sia K3.1 Pro hanno max come valore predefinito. Il ragionamento viene conteggiato come output: nel test di AIHubMix a luglio, in cui K3 ha creato un gioco partendo da un solo prompt, il 73% dei 74,994 token di completamento era costituito da ragionamento.
• Anche un livello di effort basso può comportare migliaia di token di ragionamento. In un controllo a campione di AIHubMix del 24 ottobre, un prompt che chiedeva una spiegazione di 600 parole ha portato K3.1 Pro a ragionare per 5,561–7,356 token con low prima di rispondere, e in un'esecuzione è stato raggiunto il limite di 8,192 token. Con lo stesso prompt, K3 ha ragionato per 3,013–7,051 token: quindi non è una novità di K3.1 Pro, ma low non è una modalità economica per nessuno dei due; imposta max_completion_tokens su un valore generoso. È stato usato un solo prompt con tre esecuzioni per modello sugli ID principali di AIHubMix: misura quindi le prestazioni sul tuo carico di lavoro.
• Passare a K3.1 Pro all'interno di una sessione esistente riduce la qualità. La documentazione di Kimi Code di Moonshot sconsiglia di passare ai nuovi modelli «all'interno di una sessione esistente della serie K3, K2.8 Preview o K2.7 Code Highspeed»: ciò riduce la qualità delle risposte e le cache hit. Avvia una nuova sessione.
• La modifica del modello o del livello di sforzo invalida la cache. La documentazione di Kimi Code di Moonshot lo specifica per entrambi, e quella di K3 affermava che cambiare il livello di sforzo «invalida i riscontri della cache dei prefissi». Scegli il modello e il livello all'inizio della sessione.

Highspeed

• Se digiti male l'ID Highspeed, otterrai un modello più lento. In Kimi Code, un ID Highspeed errato «passa silenziosamente a K2.8 Preview senza ragionamento: nessun aumento di velocità». Copia l'ID esattamente e controlla quale modello compare nei log.
• Highspeed accelera solo l'output del modello. Moonshot indica che K3.1 Pro Highspeed è circa 2–3× più veloce di K3.1 Pro, con funzionalità identiche. Nel controllo a campione di AIHubMix, la velocità di generazione era circa 1.6–1.8× quella di Pro. Le chiamate agli strumenti e gli script non diventano affatto più veloci: quindi, in un turno dominato dalla lettura di file e dall'esecuzione di test, il vantaggio è ridotto, mentre i piani Kimi Code consumano circa il doppio della quota.

Protocolli

• I proxy possono modificare il comportamento. La documentazione di Kimi Code di Moonshot avverte: «La traduzione del protocollo tramite strumenti proxy può causare variazioni nel comportamento del modello». Usa per ogni strumento il protocollo previsto: Messages per Claude Code, Responses per Codex. Il 24 ottobre, AIHubMix ha restituito il ragionamento, come reasoning_content e come blocchi thinking, per le richieste Chat Completions e Messages su tutti e quattro gli ID K3.1 Pro. Responses ha funzionato sul canale coding, con un elemento reasoning, e ha restituito il 404 menzionato sopra sugli ID principali.
• L'output strutturato nell'API Messages è migliorato. Nel test di luglio di AIHubMix su K3, /v1/messages ignorava uno schema e restituiva testo libero. Il 24 ottobre, una richiesta dello stesso tipo a K3.1 Pro, con uno schema JSON in output_config.format e un prompt che non chiedeva JSON, ha restituito {"city":"Paris"} su tutti e quattro gli ID. Lo schema ha un solo campo, quindi convalida l'output prima di riportare JSON su Messages. L'altra anomalia di Messages riscontrata a luglio, in cui il rilevamento di una sequenza di arresto veniva restituito come end_turn con stop_sequence: null, non è stata verificata di nuovo.

Richieste lunghe

• I timeout brevi fanno fallire anche richieste modeste. Nel controllo a campione, le risposte complete di K3.1 Pro con low hanno richiesto da 80 a 99 secondi. Un client non in streaming con un timeout di 60 secondi avrebbe fallito ogni esecuzione, e un nuovo tentativo avrebbe pagato di nuovo lo stesso ragionamento. Nell'API di Moonshot, il limite predefinito di output di K3.1 Pro è di 131,072 token, fino a 1,048,576, e la versione di luglio del gioco realizzata con K3 su AIHubMix ha richiesto 2,541 secondi in una singola richiesta. Usa lo streaming e imposta timeout di alcuni minuti.

Indicazioni ereditate dalle guide di K3

Queste indicazioni provengono dalle guide di K3:

• Eliminare reasoning_content riduce la qualità nelle conversazioni con più turni. L'intero messaggio dell'assistente, inclusi reasoning_content e tool_calls, deve essere reinviato senza modifiche. Il codice che conserva solo content continua a funzionare, ma Moonshot avverte che la qualità delle risposte può diventare instabile.
• Se elimini il messaggio che li contiene, gli strumenti dinamici scompaiono. K3 consente di caricare strumenti durante la conversazione tramite un messaggio di sistema senza contenuto. Il server non lo conserva, quindi va reinviato con ogni richiesta. Su AIHubMix funziona tramite Chat Completions: il 24 ottobre, kimi-k3.1-pro ha chiamato uno strumento inserito in questo modo. Nel test di luglio di AIHubMix su K3, l'API Messages aveva ignorato uno strumento inserito.

Regole di fatturazione facili da trascurare

I prezzi seguenti sono quelli di AIHubMix, riportati nelle pagine dei modelli, per milione di token:

Su AIHubMix, K3.1 Pro costa il 30% in meno di K3 per input e input memorizzato nella cache, e il 26% in meno per output. Highspeed costa il doppio di Pro per input e output, mentre la tariffa per la cache è la stessa. L'ID del canale coding ha un prezzo distinto: $0.88 per l'input, $3.23 per l'output e $0.132 per i token memorizzati nella cache.

Una tariffa più bassa non garantisce una fattura più contenuta. Considera la generazione di un gioco con un solo prompt, realizzata a luglio su K3 da AIHubMix: 74,994 token di output, ipotizzando 5,000 token di input. A parità di conteggio dei token, costa circa $1.08 su K3, circa $0.80 su K3.1 Pro (5,000 × $2.00 + 74,994 × $10.50, per milione) e circa $1.59 su Highspeed. Il conteggio dei token varia in base al prompt (nel controllo a campione, K3.1 Pro e K3 rientravano nello stesso intervallo con low), quindi misura prima di definire il budget.

La documentazione dell'API di Moonshot fattura le scritture in cache di K3.1 Pro in base al TTL, di 5 minuti o 1 ora, come per K3. Le tariffe pubblicate di K3, tratte dalla guida di Moonshot alla memorizzazione nella cache del contesto, mostrano il funzionamento di questa struttura:

Moonshot afferma che separare le scritture in cache non ha aumentato il costo totale di K3: il costo della scrittura era già incluso nel prezzo dell'input, quindi le richieste con il TTL predefinito di 5 minuti costano come prima.

Queste sono le tariffe dirette di Moonshot. Le pagine dei modelli di AIHubMix riportano solo i prezzi di input, output e input memorizzato nella cache, senza una tariffa distinta per le scritture in cache, e non specificano come viene fatturata una scrittura con TTL di 1 ora. AIHubMix trasferisce comunque il TTL: il 24 ottobre, una richiesta Messages con un TTL cache_control di primo livello pari a 1h ha indicato la scrittura come token di cache da 1 ora, mentre una richiesta Chat Completions con prompt_cache_options è stata accettata.

• La memorizzazione nella cache è automatica. Su K3, il TTL predefinito è di 5 minuti. Nei controlli di AIHubMix del 24 ottobre, un prompt ripetuto di 93 token è tornato completamente memorizzato nella cache sul canale coding, ma non sugli ID principali. Con un prompt di 7,658 token, la seconda chiamata a kimi-k3.1-pro è tornata con 7,424 token memorizzati nella cache, sia tramite Chat Completions sia tramite Messages.
• Il TTL di 1 ora, nell'API di Moonshot, costa $3.00 in più per milione di token da memorizzare in cache alle tariffe di K3. Ogni cache hit fa risparmiare $2.70, quindi, secondo i calcoli di Moonshot, conviene a partire dalla seconda cache hit.
• Il TTL viene fissato alla prima scrittura (K3). Non puoi estendere una voce da 5 minuti a un'ora: deve prima scadere.
• I dashboard dei costi hanno bisogno di un nuovo campo (K3). Le scritture in cache appaiono come prompt_tokens_details.cache_write_tokens in Chat Completions, input_tokens_details.cache_write_tokens in Responses e cache_creation_input_tokens in Messages.
• Il ragionamento è output. Su K3, i token di ragionamento sono fatturati alla tariffa di output a ogni livello di effort. AIHubMix non indica un prezzo distinto per il ragionamento di K3.1 Pro.

Passaggi per ridurre la fattura:

1. Imposta reasoning_effort in base al carico di lavoro, invece di ereditare max. Prova low per ricerche rapide e classificazione, e high per le attività di programmazione di routine.
2. Mantieni invariati modello e livello di effort per ogni sessione e avvia una nuova sessione quando cambi uno dei due.
3. Metti prima le parti stabili: prompt di sistema, definizioni degli strumenti, contesto del repository. Poi aggiungi il turno in corso.
4. Usa Highspeed quando il collo di bottiglia è l'attesa dell'output del modello, non nei cicli dominati dalle chiamate agli strumenti.
5. Controlla la quota di ragionamento sui token di completamento. Se resta sopra la metà nelle attività semplici, riduci il livello di effort.

Agenti con permessi reali

Il problema segnalato con Hermes Agent mostra come un bug di migrazione possa diventare un problema di sicurezza. Il suo classificatore di «approvazione intelligente» chiamava k3 con un parametro temperature e ogni chiamata restituiva un errore 400. Secondo chi ha segnalato il problema, il classificatore «aumenta il livello di autorizzazione (fail-open) a ogni chiamata»: il controllo di sicurezza smetteva di svolgere il proprio compito, senza che nella chat principale ci fosse nulla di anomalo.

K3.1 Pro mantiene quel rischio e ne aggiunge un altro. Le chiamate ai classificatori sono proprio quelle che i team cercano di rendere rapide ed economiche impostando una temperature bassa o disattivando il ragionamento, ma su K3.1 Pro nessuna delle due opzioni funziona: un parametro temperature può restituire un errore 400 a ogni chiamata e, su AIHubMix, una richiesta con il ragionamento disattivato è tornata senza ragionamento. Se un controllo di sicurezza gira su K3.1 Pro, usa reasoning_effort: "low" per la velocità, decidi come gestire gli errori dell'API e configura il sistema in modo che neghi l'accesso in caso di errore.

Ci sono altri aspetti da considerare per gli agenti che agiscono autonomamente:

• Le chiamate forzate agli strumenti funzionano. K3.1 Pro supporta tool_choice: "required", rifiutato da K2.x, quindi puoi eliminare la soluzione alternativa usata con K2.x per forzare una chiamata a uno strumento.
• La ricerca Web integrata non è pronta per la produzione (K3). La guida di Moonshot a K3 afferma che la ricerca Web «è in fase di aggiornamento e al momento non è consigliata per i flussi di lavoro di produzione». Per K3.1 Pro, considerala allo stesso modo finché Moonshot non comunica diversamente. Tramite AIHubMix, il 24 ottobre un ciclo di ricerca con K3.1 Pro non è andato a buon fine: il modello ha richiesto $web_search e l'invio del risultato ha restituito 400 Invalid request: tokenization failed.
• Le immagini in input richiedono il formato base64. K3 non recupera immagini da URL pubblici e, il 24 ottobre, kimi-k3.1-pro su AIHubMix ne ha rifiutata una con l'errore 400 Invalid request: unsupported image url: un agente che invia link a screenshot riceverà quindi un errore. L'altra opzione di Moonshot, un ID file ottenuto caricando il file sulla piattaforma, non è supportata da AIHubMix: un riferimento ms:// ha restituito 404. Un'immagine base64 ha funzionato. K3.1 Pro accetta anche input video in Kimi Code.

Strumenti di coding: Claude Code e Codex

Claude Code usa l'API Anthropic Messages, a cui gli ID principali di AIHubMix hanno risposto il 24 ottobre. Codex usa l'API Responses, a cui ha risposto solo il canale coding. Le guide evergreen di AIHubMix illustrano l'installazione e la configurazione di base. Di seguito sono riportate solo le modifiche necessarie per K3.1 Pro.

La colonna Codex usa l’ID del canale coding finché gli ID principali non risponderanno tramite la Responses API. Qualsiasi valore effort inviato da uno strumento diverso dai tre viene convertito come indicato nella tabella effort qui sopra.

Claude Code

Segui la guida alle impostazioni settings.json di Claude Code. Poi imposta ogni livello del modello, non solo quello principale:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://aihubmix.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-your-aihubmix-key",
    "ANTHROPIC_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "kimi-k3.1-pro",
    "CLAUDE_CODE_SUBAGENT_MODEL": "kimi-k3.1-pro"
  }
}

Problemi noti, riportati nella documentazione Kimi Code di Moonshot, nella sua guida a Claude Code (scritta per K3) e nei test di AIHubMix:

• Avvia una nuova sessione. Non passare da una sessione K3 in corso a K3.1 Pro. Aprine una nuova, così la cache e la qualità delle risposte ripartono da zero.
• I livelli non impostati falliscono senza avvisi. Claude Code usa livelli diversi per la chat principale, i riepiloghi e i sub-agenti. Moonshot avverte che, se ne configuri solo alcuni, gli altri «falliscono senza avvisi». Puoi impostare il livello Haiku su un modello più economico per le attività in background.
• Le impostazioni obsolete hanno la precedenza. I vecchi valori nel blocco env di ~/.claude/settings.json hanno la precedenza sulle variabili esportate nella shell.
• Contesto da 1M. La guida di Moonshot a K3 usa kimi-k3[1m] affinché Claude Code tratti la finestra come da 1M. Anche kimi-k3.1-pro[1m] funziona allo stesso modo tramite AIHubMix: Claude Code rimuove il suffisso prima dell'invio e AIHubMix ha risposto alla richiesta risultante, intestazione del contesto da 1M inclusa, il 24 ottobre. Solo Claude Code riconosce il suffisso. Se inviato come ID modello da qualsiasi altro client, kimi-k3.1-pro[1m] restituisce un errore 400.
• Effort. K3.1 Pro usa già max come valore predefinito, il livello che la guida di Moonshot a K3 consigliava con CLAUDE_CODE_EFFORT_LEVEL=max. Per le attività di routine, high consuma meno token. Qualunque livello invii Claude Code viene convertito come indicato nella tabella effort, e AIHubMix ha accettato tutti e cinque i valori testati.
• Livelli Highspeed. Se imposti un livello su kimi-k3.1-pro-highspeed, copia l'ID esattamente. In Kimi Code, un ID digitato male attiva un ripiego senza avvisi; su AIHubMix, un ID errato restituisce un errore 400.

Codex

Codex supporta solo la Responses API, quindi wire_api = "responses" è obbligatorio. La guida alla configurazione config.toml di Codex spiega il resto. Per K3.1 Pro:

# At launch (24 October 2026), the main ID kimi-k3.1-pro returned 404 on the Responses API.
# Use the coding-channel ID until AIHubMix adds it. AIHubMix labels the
# coding channel an evaluation preview, not for production.
model = "coding-kimi-k3.1-pro"
model_provider = "aihubmix"
model_context_window = 1048576
model_reasoning_effort = "high"

[model_providers.aihubmix]
name = "AIHubMix"
base_url = "https://aihubmix.com/v1"
env_key = "AIHUBMIX_API_KEY"
wire_api = "responses"

• Dichiara la finestra di contesto. Senza model_context_window, Codex ricorre ai metadati predefiniti di un modello che non conosce. La guida di Moonshot a Codex, scritta per K3, indica che l'avviso Model metadata for kimi-k3 not found che ne risulta è previsto e innocuo.
• Effort. I livelli di Codex includono medium e xhigh. Secondo la mappatura di Kimi Code, vengono eseguiti rispettivamente come high e max, ed entrambi sono stati accettati da AIHubMix il 24 ottobre. Imposta low, high o max per sapere quale livello paghi.
• I canali sono diversi. Il canale coding ha accettato una temperatura rifiutata dagli ID principali. Quando gli ID principali inizieranno a rispondere tramite Responses, ripeti il test rapido prima di passare.
• Niente search_context_size. Se la configurazione lo imposta, rimuovilo (vedi gli errori espliciti).
• Riavvia dopo le modifiche. Codex legge config.toml solo all'avvio. Se CC Switch gestisce la configurazione di Codex, potrebbe sovrascrivere le tue modifiche.

Un test rapido di 15 minuti

Eseguilo una volta per ogni strumento, in un repository piccolo con una suite di test:

1. Avvia una nuova sessione con K3.1 Pro. Non proseguire una sessione avviata con K3 o un altro modello.
2. Chiedi: «Aggiungi un test unitario per una funzione di questo repository, esegui i test e correggi eventuali errori.»
3. Il test è superato se: il modello legge i file ed esegue i test (le chiamate agli strumenti funzionano). Dopo aver visto i risultati, prosegue: questo dimostra che il ragionamento e i risultati degli strumenti vengono passati di nuovo al modello. Termina con tutti i test superati e senza errori 400 o 404 nella sessione.
4. Nel registro di utilizzo AIHubMix, verifica che l'ID modello sia quello impostato e che le richieste successive mostrino token di input memorizzati nella cache per il prefisso stabile. Se non accade mai, significa che qualcosa nel prefisso cambia a ogni turno.
5. Annota la durata del turno e i token di completamento. Ti serviranno come riferimento per scegliere un livello effort e valutare se Highspeed conviene.

Checklist per la migrazione

• Usa l'ID di K3.1 Pro: kimi-k3.1-pro sulle API di Moonshot e AIHubMix, k3.1-pro in Kimi Code; per Codex tramite AIHubMix, per ora coding-kimi-k3.1-pro.
• Migra il codice da K2.x prima che Moonshot ritiri la serie K2 alla fine di dicembre 2026; i nuovi account Moonshot perderanno l'accesso a K2 dal 31 ottobre.
• Avvia una nuova sessione per K3.1 Pro, invece di passare a questo modello da una sessione esistente.
• Rimuovi temperature, top_p, n ed entrambe le penalità da ogni percorso di chiamata, incluse le chiamate di supporto.
• Rimuovi ogni opzione per disattivare il thinking, compresi i valori effort off, none e disabled, ed elimina i blocchi thinking di K2.x rimasti.
• Imposta effort su low, high o max; medium viene eseguito come high e xhigh come max.
• Mantieni invariati il modello e il livello effort durante una sessione.
• Copia esattamente l'ID Highspeed e controlla il modello nel registro di utilizzo.
• Limita gli elenchi stop a cinque voci da 32 byte o meno.
• Rimanda l'intero messaggio dell'assistente, inclusi reasoning_content e tool_calls, e invia di nuovo i messaggi dinamici degli strumenti.
• Trasmetti in streaming le richieste lunghe e imposta timeout in minuti.
• Convalida l'output strutturato prima di riportare il JSON nella Messages API.
• Aggiorna il monitoraggio dei costi per il campo separato relativo alle scritture nella cache.
• In caso di errori API, configura i controlli di sicurezza in modo che falliscano in modo sicuro.
• Esegui il test rapido in ogni strumento di coding.

Domande frequenti

Perché K3.1 Pro restituisce un errore HTTP 400?
Le cause più comuni sono una temperatura diversa da 1, il thinking disattivato oppure un valore effort pari a off, none, disabled o non riconosciuto. Il primo problema dipende dalle regole di campionamento fisse di K3, mantenute da K3.1 Pro; gli altri sono documentati nella guida di Moonshot a Kimi Code. Sugli ID principali di AIHubMix, il 24 ottobre solo la temperatura ha restituito un errore 400; gli altri casi hanno restituito 200 e, con thinking disattivato o none, non è stato restituito alcun ragionamento.

Posso disattivare il thinking?
No. K3.1 Pro funziona solo in modalità thinking. Imposta reasoning_effort su low per mantenere breve il ragionamento.

La temperatura viene ancora rifiutata?
Sì, sull'API di Moonshot e sugli ID principali di AIHubMix, che il 24 ottobre 2026 hanno restituito «invalid temperature: only 1 is allowed for this model». Nello stesso test, il canale coding di AIHubMix ha accettato una temperatura di 0.2. Non specificare la temperatura su nessun percorso.

Quando verranno dismessi i modelli K2?
Dal 31 ottobre 2026, i nuovi utenti registrati su Moonshot non potranno usare i modelli della serie K2; Moonshot prevede di ritirarli tutti entro la fine di dicembre 2026. Il 24 ottobre AIHubMix elencava ancora K2.6 e K2.7 Code, senza indicare una data di ritiro.

Perché il mio credito di Kimi Code si esaurisce più in fretta?
K3.1 Pro usa max effort come valore predefinito, mentre in Kimi Code K3 usava high, e Highspeed consuma circa il doppio del credito rispetto al modello standard. Imposta un livello effort più basso per le attività di routine e mantienilo invariato durante la sessione.

Perché Highspeed non è più veloce?
Potresti aver digitato male l'ID: in Kimi Code questo attiva silenziosamente un ripiego su K2.8 Preview senza thinking. Oppure, la durata del turno dipende soprattutto dalle chiamate agli strumenti. Highspeed accelera solo la generazione del modello.

Quale ID modello AIHubMix dovrebbe usare Codex?
Per ora, coding-kimi-k3.1-pro tramite Responses API su aihubmix.com/v1, con wire_api impostato su responses. Il 24 ottobre, gli ID principali hanno restituito 404 tramite Responses API. AIHubMix contrassegna il canale coding come anteprima di valutazione, non adatta alla produzione.

Continua a leggere: la serie Kimi K3.1 Pro

• Prima di migrare, valuta se l'aggiornamento conviene davvero: scopri cosa è cambiato e quanto costa un'attività reale: Kimi K3.1 Pro vs K3: cosa è cambiato, quanto costa e chi dovrebbe passare
• Se durante la migrazione stai valutando delle alternative, ecco un confronto tra K3.1 Pro, Qwen 4 e Claude Fable 5.5, compreso il costo di una realizzazione front-end con ciascuno: Kimi K3.1 Pro vs Qwen 4 vs Claude Fable 5.5: qualità del front-end, costo per attività e verifica dell'entusiasmo
• Se il costo e il credito di Highspeed ti fanno chiedere se la variante veloce convenga, la questione del rapporto tra velocità e prezzo è approfondita in un articolo dedicato: Kimi K3.1 Pro vs K3.1 Pro Highspeed: 2–3× più velocità valgono il doppio del prezzo?

Fonti

• Kimi Code: configurazione del modello
• Moonshot AI: riferimento ai parametri del modello
• AIHubMix: pagina del modello Kimi K3.1 Pro
• AIHubMix: guida pratica a Kimi K3
• Segnalazione #142365 di Hermes Agent: discrepanza nel profilo dell'endpoint di Kimi Code