Prezzi API Qwen 3.8 Max: 16 token battono lo switch off

Qwen 3.8 Max costa $2 per milione di token in input e $6 per milione in output, ma la configurazione affidabile più economica non è quella che l’API sembra suggerire. Disattivando il thinking con reasoning_effort: "none", il nostro test aritmetico in due passaggi è sceso da 4/4 risposte corrette a 1/6. Impostando invece un budget rigido di soli 16 thinking token, il risultato è tornato a 6/6, con in media un quinto di token in output in meno rispetto al default. Nella settimana del lancio si sono sentite molte dichiarazioni sulle capacità del modello, ma c’era poco con cui verificarle: nessuna model card, nessuna tabella pubblica di benchmark ed eval solo interni, un problema subito segnalato su Hacker News. Il comportamento della fatturazione, invece, può essere misurato da chiunque abbia una API key. Il primo giorno abbiamo testato qwen3.8-max tramite il gateway Synthorai: tutti i controlli di thinking accettati dall’API, il costo del reasoning per ogni impostazione, la soglia minima e il ritardo di creazione della cache implicita, il contesto dichiarato da 1M e ciò che resta invariato rispetto a Qwen 3.7.

TL;DR

• I sette valori di reasoning_effort di qwen3.8-max producono quattro comportamenti misurabili: disattivato, limite di 4,096 token, limite di 16,384 token e nessun limite.
• thinking_budget è esatto: richiedendo 16 token, il contatore ne registra 16; il massimo è 262,144.
• Senza thinking, il test matematico in due passaggi è sceso a 1/6 risposte corrette; un budget di 16 token ha ottenuto 6/6 a un costo inferiore.
• La cache implicita viene creata in meno di 0.3 secondi e le letture costano $0.25/1M, ma sotto un prompt di circa 4,300 token non viene memorizzato nulla.
• I limiti di input sono esatti e gli errori sono espliciti: 991,808 senza thinking, 983,616 con thinking.

Cosa fanno davvero i controlli di thinking di Qwen 3.8 Max?

I parametri attivi sono tre, ma non sono i tre indicati nella documentazione. La documentazione di terze parti descrive reasoning_effort con tre valori: low, medium e xhigh, con xhigh come default. L’API che abbiamo misurato ne accetta sette: none, minimal, low, medium, high, xhigh e max. Un valore non valido viene rifiutato mostrando esattamente questa allowlist. Sono inoltre inoltrati al provider il parametro nativo thinking_budget, un intero positivo fino a 262,144, e enable_thinking, un booleano. La validazione avviene lato provider: un budget di 0 o 262,145 restituisce un errore 400 che cita il limite.

Nei task comuni, i livelli di effort non si distinguono. Su domande banali, calcoli in due passaggi e un problema combinatorio di media difficoltà, low, medium, high, xhigh e il default hanno consumato thinking token nella stessa fascia di variabilità. Nessun livello si è distinto dagli altri. Le differenze emergono solo con task che richiedono decine di migliaia di token di reasoning. In un problema di conteggio dei numeri primi, la cui esecuzione senza vincoli ha consumato 45,129 reasoning token, i limiti hanno finalmente iniziato ad attivarsi:

Il modello mentale che spiega tutte le osservazioni è questo: ogni livello di effort corrisponde a un limite predefinito del thinking budget, e i sette nomi si riducono a quattro comportamenti. Il primo è il thinking disattivato: none e enable_thinking: false si comportano allo stesso modo. Minimal e low condividono il limite di 4,096 token. Medium lo quadruplica a 16,384. High, xhigh, max e il default formano il quarto livello: in questo task nessuno ha raggiunto il limite, con un consumo compreso tra 35K e 45K token nelle varie esecuzioni, una normale variabilità a questa profondità. Se i tre livelli più alti differiscono, la separazione si trova oltre 45K thinking token, una profondità che gran parte del traffico di produzione non raggiunge mai. L’affermazione della documentazione secondo cui il default è xhigh è compatibile con tutte le nostre misure. La differenza è netta: tutte le esecuzioni limitate hanno risposto in modo errato, tutte quelle senza limite hanno risposto correttamente. Sotto il limite, i livelli si comportano allo stesso modo; per questo, nel traffico quotidiano, il selettore sembra non avere effetto. Sopra il limite, il thinking viene troncato a metà task. Per impostare una soglia precisa, conviene ignorare i preset e configurare direttamente thinking_budget; la prossima sezione analizza il parametro in dettaglio.

Come funziona davvero thinking_budget?

Il limite viene applicato al singolo token, funziona come soglia massima e non come quota, e un valore intermedio può far costare un task più di quanto costerebbe senza alcun limite. thinking_budget è il parametro intero nativo di DashScope, con valori da 1 a 262,144 e default documentato di 131,072, ereditato dalla famiglia open-weight Qwen3. Definisce il numero massimo di reasoning token per una chiamata. Le richieste con 0 o 262,145 vengono rifiutate con un errore 400 che riporta l’intervallo ammesso. Finché il limite non viene raggiunto, non cambia nulla: con un budget di 8,192, un task che normalmente richiede poche centinaia di token ne ha consumati 331 e 485, esattamente come senza budget. Quando il limite entra in gioco, l’applicazione è precisa al token: nelle nostre esecuzioni, budget di 16, 64 e 256 hanno sempre fermato il reasoning esattamente a 16, 64 e 256.

L’aspetto interessante è ciò che accade al raggiungimento del limite. Il modello non abbandona il lavoro: interrompe il reasoning e completa il task nella risposta visibile. In un problema combinatorio di media difficoltà, il conteggio delle tassellazioni con domino di una griglia 2x12, tutti i budget hanno prodotto la risposta corretta, ma i totali sono controintuitivi:

La curva non è monotona. Un budget di 256 token è costato 2.5x più del default: il modello ha usato il budget per iniziare una catena di reasoning, l’ha persa a metà ragionamento e ha ricalcolato la risposta passo dopo passo nel canale visibile. Il budget più ridotto ha fatto meglio di quelli intermedi perché 16 token non bastano nemmeno per avviare un ragionamento; il modello passa quindi subito a un’elaborazione visibile e compatta. Ne derivano tre regole. Primo, i budget minimi sono una leva concreta sui task semplici o di media difficoltà: nel nostro batch di calcoli in due passaggi, 16 token hanno ottenuto 6/6 con 98-161 token totali, contro i 126-207 del default. Secondo, non bisogna distribuire limiti intermedi su traffico di complessità ignota: finiscono nella zona morta in cui il limite interrompe un ragionamento reale e si paga due volte per lo stesso lavoro. Le righe del task complesso sopra, con 4,096 e 16,384, mostrano lo stesso problema su scala maggiore, e in quei casi anche la risposta era errata. Terzo, un budget che raggiunge il limite modifica la forma dell’output: le esecuzioni limitate mostrano il procedimento nella risposta, un dettaglio rilevante se un parser si aspetta solo il risultato.

Quanto regge alla prova dei fatti la documentazione del day one?

Circa la metà. Vale la pena pubblicare il confronto perché, al momento, nessun altro aspetto del lancio può essere verificato in modo indipendente. Tutti i dati seguenti provengono dai nostri contatori e test:

Lo schema favorisce il piano di fatturazione: tutto ciò che determina il costo è preciso e applicato correttamente, mentre la documentazione dei parametri è indietro rispetto al comportamento effettivo dell’API.

Disattivare il thinking fa risparmiare?

Riduce i token ma anche l’accuratezza, e c’è un compromesso migliore disponibile con due righe di configurazione. Nel nostro batch riproducibile di calcoli aritmetici in due passaggi, 1850 casse per 24 componenti, 75% spedito e 3,120 arrivati, la configurazione di default ha ottenuto 4/4 con 126-207 token di completamento per chiamata. reasoning_effort: "none" ha prodotto risposte da 4-5 token e ha ottenuto 1/6. Lo stesso prompt con thinking_budget: 16 ha raggiunto 6/6 con 98-161 token di completamento: per questa classe di task, è stato più economico del default e altrettanto accurato. I calcoli a passaggio singolo sono rimasti a 3/3 anche con none, quindi lo switch off è sicuro per lookup e trasformazioni a un solo passaggio; il crollo avviene nei task multi-step. Non è una regressione della versione 3.8: qwen3.7-max senza thinking ha ottenuto 3/6 sullo stesso batch.

Nei task difficili, la zona morta descritta nella sezione sul budget ha un costo preciso. Nel test complesso di conteggio dei numeri primi, il preset low ha consumato tutti i 4,096 thinking token, poi altri 13,882 token visibili per controllare i candidati, e ha comunque dato la risposta sbagliata: $0.11 per una risposta errata, contro $0.27 per quella corretta del default. Nei task difficili, lo switch off segue la stessa dinamica: con il thinking completamente disattivato, sia 3.8 sia 3.7 hanno riversato nella risposta visibile un’enumerazione da 13-15K token; in una singola esecuzione ciascuno, uno ha trovato il conteggio corretto e l’altro ha mancato un solo numero primo. Un budget che si esaurisce durante il reasoning può aumentare il costo totale e ridurre la qualità. Conviene limitare il thinking solo nei task che si sa essere semplici; i task complessi vanno lasciati ragionare.

La finestra di contesto da 1M token è reale?

Di fatto sì, con limiti esatti e trasparenti. L’API accetta fino a 991,808 token in input senza thinking e 983,616 con thinking. Entrambi i limiti producono errori espliciti: una richiesta sovradimensionata viene rifiutata con un errore 400 che indica il valore esatto, invece di troncare silenziosamente il documento. Il needle recall ha funzionato a tutte le dimensioni testate, 161K, 677K e 919K token, restituendo alla lettera il codice di override inserito nel testo in 11-63 secondi. Una richiesta da 919K token costa circa $1.84 al prezzo di listino: la finestra è reale, ma usarla per intero deve essere una scelta architetturale, non il default.

Cosa offre la cache implicita e qual è la soglia minima?

È la creazione di cache più rapida che abbiamo misurato, ma richiede una soglia insolitamente alta. Ripetendo un prompt con salt da 6,103 token, abbiamo ottenuto un hit già nella richiesta successiva, 0.3 secondi dopo. Non c’è una finestra di warm-up da gestire, a differenza dei tempi di creazione di decine di secondi di Gemini. Gli hit sono proseguiti dopo +5 e +15 minuti senza ripopolare la cache, mentre dopo +45 minuti l’entry non era più presente. La durata operativa è quindi compresa tra 15 e 45 minuti di inattività. Le letture costano $0.25 per milione, cioè 0.125x il prezzo dell’input, e non c’è alcun sovrapprezzo in scrittura. Lo sconto è apparso automaticamente nel campo cached_tokens e nel costo misurato.

Il limite è la soglia minima. Un prompt da 4,221 token non ha mai prodotto un hit; uno da 4,360 sì, e ogni primo hit era esattamente di 4,096 token. Sotto circa 4.3K token di prompt, la cache di fatto non è disponibile. È una netta differenza rispetto alla soglia minima di 1,024 token di Claude e al caching automatico di blocchi piccoli di Kimi K3. Sopra la soglia, gli hit sono quantizzati in blocchi da 128 token: abbiamo osservato 4,096, 8,320, 12,544 e 16,768. La copertura del prefisso inizializzato, però, variava dal 51% al 96%. Nelle stime conviene quindi applicare lo sconto alla maggior parte di un prefisso lungo, non alla sua totalità.

Output strutturato e tool call pagano il costo del reasoning?

Per default sì, ma sono anche i casi più sicuri in cui eliminarlo. L’output con json_schema strict funziona e applica realmente lo schema: la stessa estrazione senza schema è stata restituita racchiusa in fence Markdown. Con la configurazione di default, l’estrazione di quattro campi da una fattura ha consumato 252 reasoning token prima di produrre 57 token di JSON. Con reasoning_effort: "none" ha restituito un JSON valido e corretto in 54 token totali, un taglio di 5.7x; thinking_budget: 16 si è collocato a metà. La selezione dei tool ha mostrato lo stesso comportamento: senza thinking, il modello ha chiamato la funzione corretta usando un terzo dei token del default. Estrazione e routing a passaggio singolo sono esattamente i casi in cui lo switch off è sicuro, e con un output a $6/1M il risparmio si accumula.

Un’altra nota sulla fatturazione per chi sviluppa agent: l’API restituisce l’intera chain of thought in reasoning_content e la documentazione indica ai client multi-turn di reinviarla senza modifiche. Questa regola non viene applicata. Abbiamo riprodotto i turni includendo il reasoning, omettendolo e alterandolo deliberatamente: tutti e tre i casi sono stati accettati e l’accuratezza sulle catene brevi non è cambiata. Il reasoning reinviato viene fatturato come normali token in input. Ometterlo consente quindi un risparmio reale sul traffico multi-turn, finché non emergono problemi di qualità.

Cosa resta uguale rispetto a Qwen 3.7 e cosa è cambiato?

Il tokenizer non è cambiato e i budget di token possono essere trasferiti direttamente. Gli stessi corpus in inglese, cinese, giapponese e codice hanno prodotto conteggi identici su qwen3.8-max, qwen3.7-max, qwen3.7-plus, qwen3.6-flash e qwen3.5-flash. La pianificazione dei costi per lingua ricavata dal nostro studio dei tokenizer per lingua resta quindi invariata.

Due aspetti sono cambiati. Primo, 3.8-max aggiunge un overhead fisso al prompt che gli altri modelli della famiglia non hanno: lo stesso messaggio di un solo carattere contava 49 prompt token su 3.8-max, contro 11 su tutti gli altri Qwen testati, un costo fisso di +38 token per chiamata. È trascurabile sui prompt lunghi, ma rappresenta una percentuale misurabile su quelli brevi e ad alta frequenza. Secondo, il thinking è sempre disponibile invece di essere una modalità separata, con i sette livelli e il parametro di budget esatto descritti sopra; i controlli di 3.7 erano meno granulari. Serve anche un chiarimento sui prezzi, perché durante la preview circolavano due schemi: gli abbonamenti Token Plan, da $6 a $68 al mese e con forti sconti nelle ore di minor traffico, si applicano alle app di Alibaba, non all’API. Tramite API si paga il prezzo di listino di $2/$6, confermato dal contatore del nostro gateway fino alla quarta cifra decimale in ogni chiamata dello studio.

FAQ

È possibile disattivare il thinking su Qwen 3.8 Max?

Sì, completamente: reasoning_effort: "none" oppure enable_thinking: false eliminano del tutto i reasoning token. Va riservato ai task a passaggio singolo. Nel nostro batch di calcoli in due passaggi ha ottenuto 1/6, mentre thinking_budget impostato a 16 token ha raggiunto 6/6 con un numero di token simile o inferiore. Per il traffico multi-step, l’impostazione minima dovrebbe quindi essere un budget ridotto, non lo switch off.

Qual è la dimensione minima del prompt per la cache di Qwen 3.8 Max?

Nei nostri test, circa 4,300 token: un prompt da 4,221 token non ha mai prodotto un hit, mentre uno da 4,360 sì, e i primi hit sono sempre esattamente di 4,096 token. Sotto la soglia non viene applicato alcuno sconto. Sopra la soglia, le letture costano $0.25/1M senza sovrapprezzo in scrittura, e l’entry è disponibile 0.3 secondi dopo il popolamento.

Qwen 3.8 Max supporta reasoning_effort?

Sono accettati sette valori: none, minimal, low, medium, high, xhigh e max. I livelli si comportano però come limiti del thinking budget e differiscono solo quando un task li supera. Per un controllo deterministico conviene impostare direttamente thinking_budget: viene applicato con precisione al singolo token, rifiuta 0 e arriva fino a 262,144. I tool client al momento non concordano sui livelli disponibili; l’elenco sopra corrisponde a quelli accettati dall’API il primo giorno.

È necessario reinviare reasoning_content nelle conversazioni multi-turn?

La documentazione dice di sì, ma l’API non lo verifica. Nei nostri test, cronologie di reasoning omesse o persino alterate sono state accettate senza errori né perdita di accuratezza sulle catene brevi, mentre il reasoning reinviato viene fatturato come normale input. Evitare il reinvio è una leva legittima di risparmio finché i propri eval non mostrano un calo di qualità sulle catene lunghe.

Misurazioni effettuate il 2026-08-03 tramite il gateway Synthorai su qwen3.8-max, con confronti su qwen3.7-max, qwen3.7-plus, qwen3.6-flash e qwen3.5-flash: test dei valori accettati dal selettore, valori non validi e limiti di max_tokens; un task complesso con consumo naturale di 45K token per attivare i limiti di effort; un batch fisso e riproducibile per misurare il crollo di accuratezza (n=4-6 per configurazione, con salt); coppie di richieste con salt per la cache, distanziate di 2-3s e con intervalli progressivi; test di needle e overflow tra 161K e 919K token; conteggi del tokenizer sugli stessi quattro corpus. Gli importi in dollari provengono dal contatore del gateway ai prezzi di listino ($2/$6 per 1M). Sconti, tariffe e comportamenti del periodo di preview possono cambiare; verificare sui propri dati di utilizzo.

← Torna al blog