Controlli di ragionamento LLM: test su 13 modelli

Lo stesso parametro di controllo del ragionamento significa tre cose diverse a seconda del modello a cui lo invii: thinking_budget: 16 consuma esattamente 16 token di ragionamento su Qwen 3.8 Max, GLM 5.2 ed entrambe le build di DeepSeek V4, viene ignorato silenziosamente su Kimi K3 e MiniMax M3, e viene rifiutato con un 400 da GPT-5.6. Abbiamo testato 13 modelli di nove fornitori con ogni ortografia di controllo accettata dalla superficie compatibile con OpenAI, quindi abbiamo misurato quanto costa ogni posizione del selettore in token di ragionamento e cosa compromette in termini di accuratezza, sugli stessi quattro task con salt, tre esecuzioni per cella.

TL;DR

• thinking: {"type": "disabled"} azzera il ragionamento su 11 dei 13 modelli; le due eccezioni (Gemini pro, GPT-5.6) lo rifiutano.
• Qwen, GLM e DeepSeek consumano thinking_budget: 16 esattamente come 16; Kimi e MiniMax accettano il campo e non cambiano nulla: Kimi ha consumato 8-97 rispetto a quel limite, mai 16.
• Con il ragionamento disattivato l’aritmetica a 5 passaggi è scesa da 3/3 a 0-1/3 su otto modelli; DeepSeek V4 Pro e Claude hanno mantenuto 3/3 scrivendo i passaggi nella risposta visibile.
• L’estrazione JSON ha ottenuto 3/3 con il ragionamento disattivato su tutti i 12 modelli che supportano la disattivazione.

Quali controlli di ragionamento accetta ogni API?

Sulle interfacce OpenAI-compatible circolano tre famiglie di controlli, ma nessun modello le rispetta tutte. reasoning_effort accetta un enum (da none a max), thinking_budget un numero di token, mentre thinking: {"type": "disabled"} e la variante enable_thinking: false richiedono la disattivazione completa. Questa è la matrice di compatibilità misurata con una semplice domanda dotata di salt per ogni cella:

Due righe meritano una segnalazione. Google divide la propria linea: il livello flash si disattiva in modo pulito mentre il livello pro rifiuta ogni variante di disattivazione con un 400, in linea con la posizione di Google secondo cui il ragionamento di classe pro non può essere disabilitato. E le due celle claude-fable-5 contrassegnate come “accepted” differiscono dal contratto pubblicato da Anthropic per quel modello, che specifica che il ragionamento non può essere disabilitato; considerate quelle celle come in evoluzione.

”Accettato” significa anche “applicato”?

No, e la differenza viene fatturata. Una risposta 200 indica che il parametro è stato interpretato, non che sia arrivato al modello. Per distinguere i due casi basta inviare un budget di 16 e controllare il contatore.

Qwen, GLM ed entrambe le build di DeepSeek hanno consumato esattamente 16. Kimi ne ha consumati 8, 19, 79 e 97 rispetto allo stesso limite in quattro esecuzioni, mai 16, e MiniMax si è comportato allo stesso modo a 18-44, fatturato come al solito, senza nulla nella risposta che suggerisse che il limite fosse stato ignorato. Gemini traduce i budget nel suo controllo nativo con granularità grossolana: su flash, limiti da 0 a 64 si comportavano come una disattivazione completa mentre 1.024 consentiva il ragionamento (mediana 141 nel nostro compito a 5 passaggi); il livello pro riduceva il suo consumo sotto un limite ma si assestava intorno a 200 rispetto a un valore richiesto di 64 e non può raggiungere lo zero. GPT-5.6 e Claude si collocano all’estremità onesta dello spettro: i budget numerici vengono rifiutati con un 400 e sai subito a che punto sei.

La regola pratica è semplice: dopo aver impostato un controllo del ragionamento, leggi completion_tokens_details.reasoning_tokens nella risposta successiva e verifica che il valore sia cambiato. Un controllo che fallisce esplicitamente costa un retry; uno che fallisce senza segnalarlo addebita a ogni chiamata il ragionamento che credevi di aver limitato.

Esiste un interruttore universale?

thinking: {"type": "disabled"} è quanto di più vicino si possa ottenere: ha azzerato il ragionamento su 11 dei 13 modelli, comprendendo Kimi, Qwen, entrambi i DeepSeek, GLM, Gemini flash, MiniMax, la linea Seed di ByteDance e tutti e tre i modelli Claude. Il suo sosia enable_thinking: false corrisponde quasi ovunque, con una silenziosa eccezione: MiniMax lo accetta e mantiene il ragionamento (31 token di ragionamento nel nostro test).

Le due eccezioni falliscono in modo evidente anziché silenzioso: Gemini pro restituisce un 400 per ogni errore di ortografia (il tier non può disabilitare il ragionamento), e anche GPT-5.6 rifiuta il campo. GPT-5.6 non necessita di un interruttore di spegnimento nello stesso senso: gpt-5.6-luna consuma zero token di ragionamento sulle ricerche ed estrazioni semplici per impostazione predefinita (lo schema a due leve di quella famiglia), e reasoning_effort: "none" fissa quel comportamento anche per gli input di tipo matematico.

Quanto peggiora l’accuratezza senza ragionamento?

In una catena aritmetica di 5 passaggi, drasticamente: otto modelli sono passati da 3/3 a 0/3 o 1/3 appena disattivato il ragionamento. In un problema testuale a 2 hop, l’impatto è stato molto più contenuto: quasi tutti i modelli hanno mantenuto 3/3 senza ragionamento. Solo Kimi e MiniMax sono scesi a 0/3, mostrando la stessa fragilità nello stato off rilevata nello studio sulla versione di lancio di K3. Il crollo avviene quando il numero di passaggi supera quelli che il modello riesce a gestire in un’unica risposta visibile.

I tre modelli che hanno mantenuto l’accuratezza usano lo stesso espediente: quando il ragionamento è disattivato, scrivono i passaggi intermedi nella risposta visibile. La risposta mediana di DeepSeek V4 Pro è passata da 115 a 142 token, quella di Sonnet 5 da 70 a 139. Si smette di pagare il ragionamento nascosto e si inizia a pagare quello visibile, che nella maggior parte dei listini ha la stessa tariffa dell’output. L’interruttore “off” cambia più l’etichetta del costo che il costo stesso. I modelli che, senza ragionamento, rispondono diligentemente in 1-4 token sono quelli la cui accuratezza crolla.

Quando si verifica il crollo, basta un budget ridotto per recuperare l’accuratezza: thinking_budget: 256 ha ripristinato 3/3 su Qwen e su entrambe le versioni di DeepSeek, con una mediana di 77-128 reasoning token. È lo stesso comportamento di recupero con un budget minimo che abbiamo misurato sul retraining di DeepSeek e sui limiti nascosti di Qwen 3.8.

Una cella della matrice non ha prodotto alcun numero: claude-fable-5 ha restituito stop_reason: "refusal" (categoria cyber) per la formulazione esatta del nostro calcolo aritmetico in 12 esecuzioni su 12, con ogni impostazione di effort. Una riformulazione semanticamente identica è invece riuscita in 12 casi su 12. Anthropic documenta il rifiuto come uno stop reason di prima classe, con un meccanismo di fallback opt-in. Se nella rotazione usi modelli della classe fable, gestisci questo stop reason prima che si presenti in produzione.

Che cosa offrono davvero i livelli di effort?

La curva cambia per ogni vendor e solo quella di Google cresce con regolarità. Abbiamo eseguito lo stesso task in 5 passaggi usando tutti i valori dell’enum accettati da ogni modello, con tre esecuzioni per posizione, quindi abbiamo tracciato le mediane su un’unica scala:

Le linee hanno quattro andamenti. Throttle reali: entrambi i Gemini crescono in modo monotono, da 137 a 390 reasoning token su flash e da 180 a 387 su pro, dove la curva si satura a high. Low ha mantenuto un’accuratezza di 3/3 consumando tra un terzo e la metà dei token delle posizioni più alte, quindi è l’impostazione predefinita più sensata per le pipeline Gemini. Linee piatte: DeepSeek passa da 78 a low a 54 a max, con una lieve discesa; Kimi da 94 a minimal a 67 a max; MiniMax oscilla tra 61 e 93 senza alcun ordine. Espongono tutti un controllo con più posizioni che non produce differenze. La model card di DeepSeek riporta benchmark eseguiti con “max reasoning effort”, un’impostazione che avevamo già riscontrato indistinguibile da quella predefinita. Limiti che non entrano in gioco: i livelli di Qwen sono tetti di budget e non si notano in un task di queste dimensioni (85-156 senza alcun andamento); diventano reali solo nei task complessi, come rilevato nei test dedicati. Andamento non monotono: high su GLM ha consumato 116 token contro 184 di low e 345 di max. Finché questa mappatura non si stabilizza, conviene considerare le posizioni intermedie come prive di un ordine. I due modelli adattivi non hanno quasi bisogno del controllo: gpt-5.6-luna varia da 32 a 41 token su tutto l’enum, mentre output_config.effort di Opus 5 ha spostato l’output visibile solo entro il margine di rumore (54-63 token; Sonnet 5 mostra lo stesso comportamento tra 71 e 92). La decisione effettiva viene presa dal ragionamento adattivo.

La regola operativa deriva direttamente da questi andamenti: su Gemini bisogna scegliere il livello in modo esplicito, perché ogni passaggio incide davvero sui costi. Su Qwen, GLM e DeepSeek conviene controllare il comportamento con thinking_budget, applicato esattamente, e con l’interruttore off, non con l’enum. Sugli altri modelli, l’enum è solo un elemento decorativo tra off e default. L’unico modo per distinguere i vari casi è eseguire il test a livelli descritto sopra: stesso task, tutte le posizioni, lettura del contatore.

Il risultato legato alla forma del task vale anche in generale: nella nostra estrazione JSON a singolo passaggio, il ragionamento attivo ha prodotto i consumi più alti dell’intera matrice (377 reasoning token su GLM, 332 su Gemini flash) senza alcun vantaggio. Tutti i 12 modelli che consentono di disattivare il ragionamento hanno ottenuto 3/3 sullo stesso task con il ragionamento disattivato. L’estrazione strutturata paga l’imposta inutile sul ragionamento più alta, pur essendo proprio il workload in cui l’interruttore off non comporta rischi.

Puoi vedere che cosa hai pagato?

Il contatore di fatturazione è sempre disponibile, ma il ragionamento no. Sei modelli appartenenti a famiglie open-weight restituiscono il testo del ragionamento in reasoning_content: GLM 5.2 e DeepSeek V4 Pro hanno fornito quella che sembra la catena completa, rispettivamente 508 e 312 caratteri per 167 e 100 reasoning token. Kimi, Qwen, DeepSeek Flash, MiniMax e Seed hanno restituito trace più brevi, grossomodo proporzionate al consumo ridotto. GPT-5.6 ed entrambi i Gemini non restituiscono nulla: i reasoning token vengono fatturati ma restano invisibili. Claude restituisce blocchi thinking il cui contenuto viene omesso per impostazione predefinita sull’interfaccia testata. Si vede che il ragionamento è avvenuto, ma non il suo contenuto.

Questa differenza di visibilità conta quando si analizza il comportamento dei budget: sui modelli che non restituiscono nulla, reasoning_tokens nei dettagli di utilizzo è l’unico strumento disponibile. La regola resta la stessa: fidati del contatore, non della risposta 200.

FAQ

Come si disattiva il ragionamento su un’API OpenAI-compatible?

Invia thinking: {"type": "disabled"}; nella nostra matrice di 13 modelli ha azzerato il ragionamento su 11 (Kimi, Qwen, DeepSeek x2, GLM, Gemini flash, MiniMax, Seed e la famiglia Claude). Gemini pro non può essere disattivato e restituisce un 400; GPT-5.6 rifiuta il campo ma di default pensa a malapena nei compiti semplici. Verifica leggendo reasoning_tokens nella risposta successiva.

thinking_budget: 0 disattiva il ragionamento?

Dipende dal modello. Su Gemini flash e ByteDance Seed, 0 si comporta come uno spegnimento netto; Qwen e DeepSeek rifiutano 0 con un 400; Kimi e MiniMax accettano qualsiasi budget e lo ignorano. Dove i budget vengono applicati al token (Qwen, GLM, DeepSeek), il valore minimo utile è un piccolo numero positivo: 256 ha retto 3/3 su Qwen ed entrambe le build DeepSeek nel nostro task a 5 passaggi, mentre GLM ha oscillato a 2/3 con la stessa impostazione.

È sicuro disattivare il ragionamento per l’estrazione JSON?

Nei nostri test sì: l’estrazione a singolo passaggio ha ottenuto 3/3 senza ragionamento su ogni modello che ne consente la disattivazione, mentre con il ragionamento attivo ha consumato fino a 377 reasoning token per lo stesso output. Il confine dipende dal numero di passaggi, non dal formato dell’output: senza ragionamento, i task multi-step sono crollati su 8 modelli su 11. C’è un’eccezione emersa dal nostro studio su DeepSeek: sul retraining 0731, il ragionamento attivo alterava i valori nei JSON strict, quindi in quel caso disattivarlo corregge anche l’output.

Quali modelli applicano esattamente i budget di ragionamento?

Qwen 3.8 Max, GLM 5.2 ed entrambe le build di DeepSeek V4: richiedi 16, il contatore segna 16. Kimi K3 e MiniMax accettano lo stesso campo e lo ignorano; Gemini lo traduce in modo grossolano (valori piccoli agiscono come off su flash, pro imposta un minimo alto); GPT-5.6 e i modelli della generazione Claude 5 rifiutano del tutto i budget numerici (il budget_tokens di Claude restituisce un 400 che rimanda al pensiero adattivo).

Misurato il 2026-08-11/12 attraverso il gateway Synthorai: sonde di accettazione per reasoning_effort (7 valori), thinking_budget (0/16/1024), enable_thinking e thinking:{"type":"disabled"} su 13 modelli, ri-verificate poche ore prima della pubblicazione; poi una matrice fiscale di 552 chiamate (quattro forme di task salate x 3 esecuzioni per braccio, bracci limitati ai controlli verificati funzionanti di ciascun modello), una scala full-enum di 183 chiamate sul task a 5 passi (i dati del grafico), celle di completamento e una sonda di visibilità del ragionamento per modello. Accuratezza valutata dalle risposte grezze; mediane dei token di n=3; token di ragionamento letti da completion_tokens_details.reasoning_tokens (i modelli Claude riportano solo i token di output). Prompt salati per ogni chiamata. La semantica dei dial e gli enum sono la superficie che abbiamo misurato in questa data e potrebbero cambiare; ri-sondare prima di fare affidamento su una singola cella.

← Torna al blog