Reasoning effort di GLM 5.2: l'impostazione che riduce i costi di 20 volte (dati misurati)

GLM 5.2 è ora disponibile su Synthorai a un costo per token pari a circa un sesto rispetto ai modelli frontier. Le prestazioni da modello frontier con pesi open sono confermate. Ma il prezzo per token non è il dato su cui basare le valutazioni. Il costo effettivo di un task di coding su GLM 5.2 può variare di oltre un ordine di grandezza in base a un solo parametro, il reasoning effort, che nell’impostazione predefinita si trova nella posizione peggiore. Configurandolo bene, GLM 5.2 risponde correttamente e costa meno dei modelli frontier sia sui task semplici sia su quelli difficili. Lasciandolo al valore predefinito, la stessa risposta costa venti volte di più e richiede minuti. Lo abbiamo misurato.

TL;DR

• Su Synthorai, GLM 5.2 costa $1.40/M in input e $4.40/M in output, circa un sesto della tariffa di output di claude-opus-4-8.
• Su un task di coding semplice, GLM 5.2 con il reasoning disattivato è costato $0.0008 e ha impiegato 5 secondi; il valore predefinito senza limiti ha prodotto la stessa risposta per $0.0285 in 137 secondi.
• Su un task difficile, reasoning_effort: high ha dato la risposta corretta per $0.0031 in 13 secondi: circa 20 volte meno e 30 volte più velocemente rispetto al valore predefinito senza limiti ($0.062, 405 secondi).
• In entrambi i task, l’effort low di GLM ha prodotto più token di reasoning rispetto a high: i nomi dei livelli non corrispondono al numero di token.

Che cos’è GLM 5.2

GLM 5.2 è il modello frontier con pesi open di Zhipu, rilasciato il 2026-06-13: una rete mixture-of-experts (~744B parametri totali, ~40B attivi), un contesto effettivamente utilizzabile da 1M token e una licenza MIT che ne consente il self-hosting. È pensato per il coding e i workflow agentici, con risultati pubblicati solidi (SWE-bench Pro 62.1, Terminal-Bench 2.1 81.0, AIME 2026 99.2, GPQA Diamond 91.2). Su Synthorai è disponibile come glm-5.2, al prezzo di $1.40 per milione di token in input e $4.40 per milione in output.

Il punto da cui dipende tutto il resto è semplice: GLM 5.2 è un modello di reasoning e la quantità di reasoning è configurabile.

Posizionamento sul prezzo

Guardando i prezzi di listino per token, GLM 5.2 costa molto meno dei modelli frontier occidentali e si colloca tra i modelli cinesi più economici. Queste sono le tariffe Synthorai per un insieme rappresentativo di modelli:

La tariffa di output di $4.40 è circa un settimo di quella di gpt-5.5 e un sesto di quella di claude-opus-4-8, anche se deepseek-v4-pro e kimi-k2.5 costano meno. GLM 5.2 offre quindi capacità da modello frontier a prezzi vicini a quelli dei modelli cinesi, ma non è l’opzione più economica in assoluto. Non esiste una tariffa separata per la scrittura in cache: le scritture vengono fatturate alla tariffa di input, mentre solo le letture beneficiano dello sconto indicato sopra. Lo sconto varia in base al vendor. Per GLM 5.2, una lettura dalla cache costa circa un quinto rispetto all’input normale; per i modelli frontier (gpt-5.5, claude-opus-4-8, gemini-3.1-pro) costa all’incirca un decimo.

È anche un passo avanti rispetto ai suoi predecessori. La generazione precedente di GLM era estremamente economica; con la serie GLM 5 i prezzi sono aumentati e GLM 5.2 arriva a circa 3 volte la tariffa di input di GLM-4.6, in base ai prezzi ufficiali di Zhipu:

In cambio si ottengono il contesto da 1M e i risultati da modello frontier nei benchmark. Ma il prezzo per token è solo il dato di listino. Il costo effettivo di ogni task dipende dal reasoning effort.

Il parametro reasoning effort

Il reasoning di GLM 5.2 si regola con un parametro, non con un semplice interruttore. È possibile disattivarlo (enable_thinking: false), impostare reasoning_effort su low, medium o high, oppure mantenere il valore predefinito, che lascia il reasoning senza limiti. Questa impostazione incide su costo e latenza molto più del prezzo per token. Abbiamo eseguito un task di coding semplice e uno difficile con tutte le configurazioni, verificando ogni risposta rispetto a un’implementazione di riferimento su centinaia di casi casuali.

Un task semplice: il reasoning aumenta soltanto il costo

Weighted interval scheduling, un problema di programmazione dinamica di difficoltà media:

Emergono due dati. Con il reasoning disattivato, la risposta è corretta e il costo è il più basso della tabella, circa 8 volte inferiore ai modelli frontier. Ogni aumento del livello aggiunge solo costi per ottenere la stessa risposta. Inoltre, la fattura dipende dal reasoning, non dalla risposta: il codice restituito da GLM rimane intorno ai 150 token, mentre il reasoning che lo precede passa da zero a circa 6,300 token, fatturati alla stessa tariffa di output di $4.40/M. Il valore predefinito senza limiti usa tutti quei token di reasoning per arrivare alla stessa soluzione prodotta senza reasoning; l’intera differenza di costo viene da lì. In questo task, i modelli frontier rispondono con una quantità minima o nulla di reasoning dichiarato: gpt-5.5 usa 59 token di reasoning, mentre l’utilizzo riportato da claude-opus-4-8 non ne mostra alcuno.

Un task difficile: il reasoning serve, il valore predefinito no

Wildcard string matching (? e *), un problema classico in cui è facile introdurre errori poco evidenti. Con il reasoning disattivato, la soluzione non funzionava. Il modello ha restituito una ricorsione con memoizzazione:

def is_match(s, p):
    memo = {}
    def match(i, j):
        if (i, j) in memo:
            return memo[(i, j)]
        if j == len(p):
            result = i == len(s)
        elif i < len(s) and p[j] in (s[i], '?'):
            result = match(i + 1, j + 1)
        elif p[j] == '*':
            result = match(i + 1, j) or match(i, j + 1)
        else:
            result = False
        memo[(i, j)] = result
        return result
    return match(0, 0)

A prima vista sembra corretta e la presenza della memoizzazione fa pensare a una certa attenzione. Ma il ramo * richiama match(i + 1, j) senza porre un limite a i. Quando la stringa è terminata e nel pattern resta ancora un *, i continua ad aumentare all’infinito fino a causare uno stack overflow. Veloce, economica e sbagliata.

Aumentando il livello, il modello restituisce il corretto algoritmo iterativo a due puntatori, che esegue il backtracking fino all’ultimo * invece di usare la ricorsione:

def is_match(s, p):
    s_idx, p_idx, star_idx, match_idx = 0, 0, -1, 0
    while s_idx < len(s):
        if p_idx < len(p) and (p[p_idx] == '?' or p[p_idx] == s[s_idx]):
            s_idx += 1
            p_idx += 1
        elif p_idx < len(p) and p[p_idx] == '*':
            star_idx = p_idx
            match_idx = s_idx
            p_idx += 1
        elif star_idx != -1:
            p_idx = star_idx + 1
            match_idx += 1
            s_idx = match_idx
        else:
            return False
    while p_idx < len(p) and p[p_idx] == '*':
        p_idx += 1
    return p_idx == len(p)

Ecco i risultati completi per ogni livello su questo task:

Tutti i livelli di effort espliciti hanno risolto il problema. Con reasoning_effort: high, la risposta corretta è costata $0.0031 e ha richiesto 13 secondi: circa venti volte meno e trenta volte più velocemente rispetto al valore predefinito senza limiti, a parità di risposta. Costa anche meno dei modelli frontier, pur essendo più lento di pochi secondi. C’è un comportamento anomalo da conoscere: l’impostazione low di GLM ha prodotto più reasoning rispetto a high in entrambi i task. I nomi dei livelli, quindi, non corrispondono al numero di token. Medium e high sono risultate le configurazioni più economiche e veloci.

Il valore predefinito senza limiti è l’unica impostazione da evitare. Somma gli svantaggi: paga per un reasoning che il task potrebbe non richiedere e impiega minuti, arrivando alla stessa risposta ottenuta con reasoning_effort: high a un ventesimo del costo.

La regola decisionale

Il parametro decisivo è il reasoning effort e va scelto in base al task, non al modello:

• Task semplici o ad alto volume in cui verificare la correttezza è facile: reasoning disattivato (enable_thinking: false). La risposta è corretta e costa circa 8 volte meno dei modelli frontier.
• Problemi più difficili in cui il reasoning disattivato non basta: reasoning_effort: medium o high. La risposta è corretta, costa circa $0.003 per task ed è più economica dei modelli frontier, con solo pochi secondi di latenza in più.
• Mai usare il valore predefinito senza limiti. Lasciare attivo il reasoning senza un limite di effort trasforma una risposta da $0.003 in una chiamata da $0.06 e sette minuti.

Se non è possibile stabilire in anticipo se un task richieda reasoning, reasoning_effort: high è un valore predefinito sicuro: è risultato economico, ha risolto entrambi i task e non ha mai generato consumi incontrollati.

La cache riduce il costo dell’input, non del reasoning

GLM 5.2 supporta la cache sul gateway e offre il vantaggio previsto. Abbiamo inviato un prefisso condiviso da 1,494 token, un modulo di codice da revisionare, insieme a diverse domande:

Quando un prefisso di grandi dimensioni è già stato elaborato, viene memorizzato in cache. I token di input in cache costano circa un quinto della tariffa normale di input. Per una richiesta altrimenti identica, il costo è sceso da $0.0026 a $0.0009, circa il 64% in meno. Una ripetizione identica viene servita direttamente dalla cache semantica: stessa risposta e stesso costo della chiamata con prefisso in cache, ma in circa un secondo anziché cinque.

Il limite è lo stesso emerso con il reasoning effort: la cache sconta l’input. Appena si attiva il reasoning, costo e latenza dipendono dall’output di reasoning, che non viene memorizzato in cache. La cache offre quindi un vantaggio concreto per task con reasoning disattivato e molto contesto, come lo stesso system prompt o codebase inviato a ogni chiamata. Con il reasoning attivo, il beneficio è limitato.

Utilizzo su Synthorai

glm-5.2 è disponibile sul gateway. Dai nostri test emergono tre indicazioni pratiche:

• Impostare sempre il reasoning effort in modo esplicito. Usare enable_thinking: false per i task semplici e reasoning_effort: medium o high per quelli più difficili. Va evitato il reasoning attivo senza un limite di effort, cioè il valore predefinito senza limiti: è la configurazione che porta a chiamate da $0.06 e sette minuti.
• Usare lo streaming quando il reasoning è attivo. Le risposte con reasoning possono richiedere minuti. Con una richiesta non in streaming, la connessione resta inattiva abbastanza a lungo da causare probabilmente un timeout del client prima dell’arrivo della risposta. Con stream: true si riceve l’output progressivamente e si ottiene il risultato completo.
• Riutilizzare il contesto. Se ogni chiamata include lo stesso system prompt di grandi dimensioni o la stessa codebase, la prefix cache riduce il costo dell’input. Abbinandola al reasoning disattivato, l’intera richiesta diventa economica.

Il prezzo è di $1.40 / $4.40 per milione di token e il gateway restituisce un campo cost per ogni chiamata, così da mostrare il costo esatto di ciascuna richiesta.

In sintesi

GLM 5.2 è un modello di coding davvero economico e capace. Con la configurazione corretta, costa meno dei modelli frontier sia sui task semplici sia su quelli difficili. Il punto critico è proprio la configurazione. Il reasoning si regola con un parametro, ma il valore predefinito non pone alcun limite: così un task che dovrebbe costare $0.003 diventa una chiamata da $0.06 e sette minuti. Per i task semplici conviene usare enable_thinking: false; per tutti gli altri, reasoning_effort: medium o high. In questo modo GLM 5.2 rimane economico e corretto in ogni scenario. Con il reasoning al valore predefinito, invece, diventa l’opzione più lenta e costosa tra quelle disponibili.

Fonti

• VentureBeat: GLM-5.2 con pesi open di Z.ai supera GPT-5.5 nel coding a lungo orizzonte a un sesto del costo
• eigent.ai: specifiche e panoramica di GLM-5.2
• CloudPrice: prezzi e specifiche di GLM-5.2
• Z.ai: prezzi ufficiali delle API GLM (generazioni GLM-4.5 / 4.6 / 5)

Altre guide di questa serie basate su costi misurati: costo della trascrizione audio con sette modelli ASR e costo della generazione di immagini.

(I prezzi di listino Synthorai riportati sopra sono quelli applicati dalla piattaforma al 2026-06-24; i prezzi delle generazioni GLM provengono dal listino ufficiale di Zhipu.)

Costi misurati su Synthorai il 2026-06-24 (glm-5.2 a $1.40 / $4.40 per M token); verificare i prezzi correnti prima di farvi affidamento.

← Torna al blog