GLM 5.2: il reasoning effort è la leva sui costi

GLM 5.2 è ora su Synthorai a circa un sesto del prezzo per token dei modelli di frontiera, e il titolo “open-weight con benchmark da frontiera” è vero. Ma il prezzo per token è il numero sbagliato su cui ancorarsi. Quanto costa davvero un task di coding su GLM 5.2 varia di oltre un ordine di grandezza a seconda di una singola manopola, il reasoning effort, e il default la lascia nella posizione peggiore. Regolala bene e GLM 5.2 dà risposte corrette e costa meno dei modelli di frontiera sia sul lavoro facile che su quello difficile. Lasciala sul default e la stessa risposta costa venti volte di più e richiede minuti. L’abbiamo misurato.

TL;DR

• GLM 5.2 su Synthorai è listato a $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 semplice compito di programmazione, GLM 5.2 con thinking disattivato è costato $0.0008 in 5 secondi; il default senza limiti ha prodotto la stessa risposta per $0.0285 in 137 secondi.
• Su un compito difficile, reasoning_effort: high è stato corretto per $0.0031 in 13 secondi, circa 20 volte più economico e 30 volte più veloce del default senza limiti ($0.062, 405 secondi).
• L’effort low di GLM ha prodotto più token di reasoning rispetto a high in entrambi i compiti: i nomi degli effort non riflettono il conteggio dei token.

Cos’è GLM 5.2

GLM 5.2 è il modello open-weight di frontiera di Zhipu, rilasciato il 2026-06-13: una rete mixture-of-experts (~744B totali, ~40B attivi), un context da 1M token utilizzabile e una licenza MIT che puoi self-hostare. Punta su coding e lavoro agentico, con benchmark pubblicati solidi (SWE-bench Pro 62.1, Terminal-Bench 2.1 81.0, AIME 2026 99.2, GPQA Diamond 91.2). Su Synthorai è glm-5.2, con un prezzo di $1.40 per milione di token di input e $4.40 per milione di output.

Il dettaglio che determina tutto quello che segue: è un modello di reasoning, e quanto ragiona lo decidi tu.

Dove si colloca sul prezzo

Sul prezzo di listino per token, GLM 5.2 sta ben sotto la frontiera occidentale e tra i modelli cinesi più economici. Le tariffe di Synthorai per un set rappresentativo:

La sua tariffa di output di $4.40 è circa un settimo di gpt-5.5 e un sesto di claude-opus-4-8, anche se deepseek-v4-pro e kimi-k2.5 costano meno. Quindi GLM 5.2 offre capacità da frontiera a prezzi grosso modo da modello cinese, non il minimo assoluto. Non c’è un costo separato per la cache write: una cache write viene fatturata alla tariffa di input, e solo la cache read è scontata alla tariffa indicata sopra. Lo sconto varia da vendor a vendor: la cache read di GLM 5.2 è circa un quinto della sua tariffa di input, mentre i modelli di frontiera (gpt-5.5, claude-opus-4-8, gemini-3.1-pro) scontano le read a circa un decimo.

È anche un passo avanti rispetto ai suoi predecessori. La generazione GLM precedente era straordinariamente economica; la linea GLM 5 ha alzato i prezzi, e GLM 5.2 si attesta a circa 3x la tariffa di input di GLM-4.6 (tariffe ufficiali di Zhipu):

Questo ti dà il context da 1M e i benchmark da frontiera. Ma la tariffa per token è solo il titolo. Quello che paghi davvero per task lo decide il reasoning effort.

La manopola del reasoning effort

Il reasoning di GLM 5.2 è una manopola, non un interruttore. Puoi spegnerlo (enable_thinking: false), impostare reasoning_effort su low, medium o high, oppure lasciarlo sul default, che esegue il reasoning senza limiti. Questa impostazione cambia costo e latenza molto più di quanto faccia il prezzo. Abbiamo eseguito un task di coding facile e uno difficile su tutte le impostazioni, verificando ogni risposta contro un riferimento su centinaia di casi randomizzati.

Un compito facile: il ragionamento aggiunge solo costi

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

Saltano all’occhio due cose. Con il thinking off la risposta è corretta ed è la più economica di tutte, circa 8 volte meno dei modelli di frontiera, e ogni scatto verso l’alto della manopola aggiunge solo costi per la stessa risposta. E il conto segue il ragionamento, non la risposta: il codice che restituisce GLM è sempre di circa 150 token, mentre il ragionamento che lo precede cresce da zero fino a circa 6,300, fatturato allo stesso prezzo di $4.40/M in output. Il default senza limiti spende quel ragionamento per arrivare alla stessa risposta che il thinking off produce senza spenderne nemmeno uno, e quel divario è tutta la differenza di costo. Qui i modelli di frontiera rispondono con poco o nessun ragionamento riportato: gpt-5.5 spende 59 token di reasoning, e l’utilizzo di claude-opus-4-8 non ne riporta nessuno.

Un task difficile: qui il reasoning vale il suo costo, il default no

Wildcard string matching (? e *), il classico problema facile da sbagliare in modo subdolo. Qui il thinking off ha ceduto. 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)

Sembra corretta, e la memoizzazione suggerisce persino una certa attenzione. Ma il ramo * fa la ricorsione match(i + 1, j) senza porre un limite a i. Una volta consumata la stringa, se il pattern contiene ancora un *, i cresce all’infinito e lo stack va in overflow. Veloce, economica e sbagliata.

Alza la manopola e restituisce l’algoritmo iterativo corretto a due puntatori, che fa backtracking all’ultimo * invece di ricorrere:

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)

La manopola al completo su questo task:

Ogni livello di effort esplicito lo ha risolto. reasoning_effort: high ci è riuscito con $0.0031 in 13 secondi, circa venti volte più economico e trenta volte più veloce del default illimitato a parità di risposta, e sul costo batte i modelli di frontiera restando indietro di pochi secondi. Un dettaglio da tenere presente: il low di GLM ha prodotto più reasoning del high, in modo costante su entrambi i task, quindi i nomi non riflettono il numero di token. Medium e high sono state le impostazioni economiche e veloci.

Il default illimitato è l’unica impostazione da evitare. È il peggio di entrambi i mondi: compra reasoning di cui il task potrebbe non aver bisogno e ci mette minuti, per arrivare alla stessa risposta di reasoning_effort: high a venti volte il costo.

La regola di decisione

La leva è il reasoning effort, e l’impostazione giusta dipende dal task, non dal modello:

• Lavoro semplice o ad alto volume dove la correttezza è facile: thinking off (enable_thinking: false). Corretto e circa 8 volte sotto la frontiera.
• Problemi più difficili dove il thinking off fallisce: reasoning_effort: medium o high. Corretto, intorno a $0.003 a task, sotto la frontiera sul costo e più lento solo di qualche secondo.
• Mai il default illimitato. Lasciare il reasoning attivo senza un limite di effort è il modo per trasformare una risposta da $0.003 in una da $0.06 che richiede sette minuti.

Se non riesci a stabilire in anticipo se un task ha bisogno di reasoning, reasoning_effort: high è un default sicuro: è economico, ha risolto entrambi i task e non è mai andato fuori controllo.

Il caching aiuta l’input, non il reasoning

GLM 5.2 supporta il caching sul gateway, e aiuta dove ci si aspetta. Abbiamo inviato un prefisso condiviso di 1.494 token (un modulo di codice da revisionare) con diverse domande:

Una volta visto un prefisso grande, finisce in cache. I token di input in cache costano circa un quinto della tariffa normale, il che ha ridotto una richiesta per il resto identica da $0.0026 a $0.0009, circa il 64%. Una ripetizione esatta viene servita direttamente dalla cache semantica: stessa risposta allo stesso costo della chiamata in cache, ma restituita in circa un secondo invece di cinque.

Il problema è lo stesso che ci ha insegnato la manopola: il caching sconta l’input, ma nel momento in cui il reasoning è attivo, costo e latenza vivono nell’output del reasoning, che non è in cache. Quindi il caching è un vantaggio reale per il lavoro ad alto contesto con thinking off (lo stesso system prompt o codebase a ogni chiamata), e un vantaggio minimo quando il reasoning è attivo.

Usarlo su Synthorai

glm-5.2 è disponibile sul gateway. Tre note pratiche dai nostri test:

• Imposta il reasoning effort in modo esplicito. Usa enable_thinking: false per il lavoro semplice e reasoning_effort: medium o high per i problemi più difficili. L’unica cosa da evitare è lasciare il reasoning attivo senza un tetto all’effort (il default illimitato), che è la trappola da $0.06 e sette minuti.
• Usa lo streaming quando il reasoning è attivo. Le risposte con reasoning possono durare minuti, e una richiesta non-streaming resta su una connessione silenziosa abbastanza a lungo che il tuo client con ogni probabilità andrà in timeout prima che arrivi la risposta. Usa stream: true e ottieni output incrementale più il risultato completo.
• Riusa il contesto. Se invii lo stesso system prompt o codebase grande a ogni chiamata, il prefix caching riduce il costo dell’input, e abbinarlo al thinking off rende l’intera richiesta economica.

Il prezzo è $1.40 / $4.40 per milione di token, e il gateway restituisce un campo cost per ogni chiamata, così vedi esattamente quanto è costata ciascuna richiesta.

In sintesi

GLM 5.2 è un modello di coding davvero economico e capace, e configurato bene batte i prezzi di frontiera sia sul lavoro facile che su quello difficile. Il punto è la configurazione. Il suo reasoning è una manopola, e il default lo lascia illimitato: è così che un task che dovrebbe costare $0.003 diventa una chiamata da $0.06 e sette minuti. Imposta enable_thinking: false per il lavoro semplice e reasoning_effort: medium o high per il resto, e GLM 5.2 è economico e corretto su tutta la linea. Lascialo sul default del reasoning, ed è l’opzione più lenta e più cara che potevi scegliere.

Fonti

• VentureBeat: Z.ai’s open-weight GLM-5.2 beats GPT-5.5 on long-horizon coding for 1/6 the cost
• eigent.ai: GLM-5.2 specs and overview
• CloudPrice: GLM-5.2 pricing and specs
• Z.ai: official GLM API pricing (GLM-4.5 / 4.6 / 5 generations)

(I prezzi di listino Synthorai qui sopra sono le tariffe di questa piattaforma al 2026-06-24; le tariffe generazionali GLM sono il listino ufficiale di Zhipu.)

Costi misurati su Synthorai il 2026-06-24 (glm-5.2 a $1.40 / $4.40 per M token); verifica il prezzo attuale prima di farci affidamento.

← Torna al blog