Zero modifiche al modello base. Tutto il lavoro su GLM-5.3 è post-training puro. E i risultati? Beh, diciamo che hanno scoperto vulnerabilità vecchie di 40 anni nei codebase open source. Alcune risalgono al 1981. Sì, quella cifra.
Partiamo dal contesto. Con GLM-5.2, il team di Z.ai aveva costruito lo stack: IndexShare per il long-context, SAO per il reinforcement learning su task complessi, slime per il training asincrono su larga scala. Poi hanno fatto una cosa semplicissima: hanno scalato. Più ambienti, più task, più compute. Un mese di iterazioni continue.
Coding potenziato e cyber capabilities inaspettate
Il risultato è GLM-5.3, che usa lo stesso modello base di GLM-5.2 ma performa in modo radicalmente diverso. Miglioramento del 50% sul benchmark interno Z.ai Code Bench. Open-source SOTA su Terminal Bench 3.0 e Agents’ Last Exam. Il che lo rende il modello open-weights più capace sul coding in circolazione, almeno stando ai numeri.
Ma la cosa che ha sorpreso anche il team è un’altra: le cyber capabilities. Durante il post-training hanno inserito dati e ambienti per la vulnerability discovery. Si aspettavano miglioramenti graduali nell’identificazione di falle. Invece il modello ha cominciato a ragionare attraverso intere exploitation chain. Non trova solo bug isolati — costruisce piani d’attacco completi, concatenando più stadi.
Su CyberGym, che parte da codice white-box e verifica se il modello riesce a identificare e triggerare vulnerabilità, GLM-5.3 ottiene 84.5%. Meglio di Mythos 5 (83.8%) e GPT-5.6 Sol (83.6%). Su ExploitBench, dove serve ragionamento più profondo, arriva a 54.4% — più del doppio del 24.4% di GLM-5.2. Su ExploitGym, completa 105 task in due ore e 130 in sei ore, contro i 29 e 39 della versione precedente.
2.436 vulnerabilità in codebase reali
Poi è arrivato il test sul campo. Dal rilascio di GLM-5.2, Z.ai lavora con diversi security team cinesi per far girare i modelli su codebase reali. Dopo review, screening e deduplicazione: 2.436 vulnerabilità identificate su 269 progetti. Di cui 1.097 di severità medio-alta. La più vecchia risale a circa 40 anni fa. La media? 26.6 anni prima della scoperta.
Il pattern è chiaro: più si sale nella exploitation chain, più il gap rispetto a GLM-5.2 si allarga. E anche il gap verso i modelli closed di frontiera. La capability cresce più velocemente proprio dove sono più indietro. Non è lineare.
Per tracciare tutto questo hanno costruito il Z.ai Security Disclosure Ledger, un registro pubblico aggiornato continuamente. Delle 2.436 vulnerabilità trovate, 53 sono già pubblicamente disclosure, 2.383 ancora sotto embargo. Include severità, CVE quando disponibile, progetto affetto, e quanto tempo quella falla è rimasta nel codice prima di essere scoperta.
Ambienti sintetici e scaling del post-training
Come ci sono arrivati? Scaling degli ambienti. Per GLM-5.3 hanno spinto gli environment verso task che sembrano meno esercizi di programmazione e più unità reali di lavoro esperto. Alcuni rappresentano diversi giorni di lavoro per un engineer esperto.
Esempio: task di ML infrastructure. Il modello riceve lo stesso ambiente di lavoro di un ingegnere — accesso a cluster di compute, storage, documentazione interna, codebase, risultati di esperimenti. Deve diagnosticare bottleneck attraverso il training stack, implementare ottimizzazioni, far girare esperimenti, e produrre uno speedup end-to-end misurabile preservando la correttezza. Il tutto in autonomia, senza che l’utente debba decomporre il problema step-by-step.
Il problema, a questo livello di capability, si sposta dal modello all’ambiente. Un task environment utile deve essere eseguibile, verificabile, e vicino al lavoro professionale reale. E ne servono tanti, non una manciata costruiti a mano. Per questo hanno costruito pipeline che sintetizzano ambienti end-to-end — e per alcuni task, anche il segnale di reward per il RL.
Agent di ricerca raccolgono pattern da lavoro reale e li trasformano in ambienti long-horizon eseguibili, con dipendenze multi-step e stato nascosto. Un judge agent poi tenta ogni task per verificare che sia effettivamente risolvibile. I verifier vengono sintetizzati senza accesso alla soluzione di riferimento, mentre le traiettorie del solver vengono usate per scoprire e chiudere reward shortcuts. Un verifier che passa oracle, no-op e unsolved-state checks produce un reward binario abbastanza affidabile per il training diretto.
Z.ai Code Bench: il benchmark privato
Oltre ai benchmark pubblici, hanno introdotto Z.ai Code Bench, un benchmark interno per valutare coding agent in scenari utente realistici. Copre categorie di task diverse e piazza gli agent in ambienti di sviluppo locali complessi. A diversi livelli di effort, valuta su due dimensioni: task completion rate end-to-end e checklist accuracy granulare.
Essendo privato, riduce il rischio di contaminazione da test set pubblici e offre una misura più fedele dell’esperienza utente reale. I numeri: GLM-5.3 raggiunge 34.5% a Max effort con circa 75K token di output per task, contro il 23.4% a 96K di GLM-5.2. A High effort, 31.4% con 50K token, superando Claude Opus 4.8 (29.5% con 120K token). Claude Fable 5 resta avanti, con 39.5% a Max effort.
slime: il framework che regge tutto
Dietro tutto questo c’è slime, il framework open-source di Z.ai per il post-training RL scaling. Megatron per il training, SGLang per il rollout. Il design tiene training, rollout e data buffer su un singolo dataflow — il che significa che math, code, sandbox, verifier e ambienti agentici long-horizon si pluggano come generazione di dati, non come modifiche al training loop.
Per GLM-5.3 hanno continuato a svilupparlo su due fronti. Lato algoritmico: top-p mask, top-k e full-vocabulary OPD, configurazioni che migliorano la consistenza training–rollout (setup in stile R3, allineamento numerico completo tra training e rollout path). Controllano la differenza media in log probabilities a livello 1e-7 — riduzione di oltre il 99.99% rispetto ai setup precedenti.
Lato efficienza: local storage come layer di caching aggiuntivo, che tiene model state e dati in modo gerarchico invece che in host memory. Fondamentale per multi-teacher OPD, con dynamic teacher switching e prefetching sul lato training. Diversi teacher utilizzabili senza dover alzare un servizio di inference dedicato per ognuno. Overhead limitato, consumo di risorse drasticamente ridotto.
Per workload agentici asincroni, hanno migliorato scheduling congiunto e load balancing tra router e slime. Le richieste di rollout con lunghezze e tempi di completamento molto variabili usano meglio le risorse di inference. Euristiche workload-aware derivano configurazioni orientate al throughput — ratio risorse prefill/decode, concurrency settings, parametri critici per il throughput — dalle caratteristiche di ogni rollout environment.
Risultato: per task di coding RL long-horizon, queste ottimizzazioni system-level hanno migliorato il throughput end-to-end del training RL di oltre 2.3×. Il che rende pratico continuare a scalare RL su traiettorie più lunghe e ambienti più complessi, con efficienza sostanzialmente più alta.
Accesso e release
GLM-5.3 è disponibile via API adesso, con tre livelli di thinking effort: low, high, max. Disabilitare il thinking non è più supportato — se la vostra app usa thinking.type: 'disabled', va cambiato in enabled e impostato reasoning_effort su low prima di aggiornare a glm-5.3. Altrimenti la richiesta fallisce.
I pesi del modello saranno rilasciati open-source tra due settimane, una volta completati safety evaluation e hardening. Nel frattempo, GLM-5.3 è già attivo per tutti gli utenti del GLM Coding Plan, che ora usa un sistema di quote basato su punti. L’uso di punti è calcolato separatamente per input token, cached input token e output token. Le chiamate fuori dalle peak hours consumano il 50% dei punti standard. Peak hours: 14:00–18:00 (UTC+8), da lunedì a venerdì. Tutto il resto, weekend inclusi, tasso off-peak.
ZCode, il coding agent di Z.ai, sfrutta GLM-5.3 con cache hit rate superiore al 98% — il contesto ripetuto viene fatturato a tariffa cached ridotta, circa il 30% di token effettivi in più. Quota boost temporaneo di 1.5× fino al 31 agosto, accumulabile con i risparmi della cache per arrivare fino al 180% della quota standard. Goal mode pianifica, codifica, testa e verifica fino al raggiungimento dell’obiettivo. Remote Control monitora e controlla task long-running dal telefono via WeChat o Feishu.
Il quadro che emerge da GLM-5.3 non è quello di un modello che migliora linearmente su benchmark. È quello di un modello che, scalando il post-training su ambienti realistici e complessi, sviluppa capability emergenti più velocemente del previsto — specialmente nelle aree dove parte da più lontano. Le cyber capabilities non erano l’obiettivo iniziale del training. Sono emerse. E ora identificano vulnerabilità che sono rimaste nascoste per decenni in codice production.
