GLM-5.3 får stort agentløft uten ny grunnmodell

GLM-5.3 viser hvor mye bedre en AI-agent kan bli uten at grunnmodellen trenes på nytt. Z.ai har beholdt den samme enorme modellen fra GLM-5.2, men skalert arbeidet etter grunntreningen med flere miljøer, større variasjon og lengre oppgaver. Resultatet er et uvanlig stort løft i komplekst kodearbeid og oppgaver som varer lenge.

Dette er mer enn litt finpuss på et nytt versjonsnummer. Leverandørens målinger peker i samme retning på tvers av lange kode- og agentoppgaver: Modellen fullfører mer arbeid og holder bedre fast ved målet gjennom lange forløp. Det er fortsatt Z.ai sine egne kjøringer, ikke en garanti for at modellen vil gjøre det samme i ditt prosjekt.

Jeg ville ikke gitt GLM-5.3 nøklene til produksjonsserveren på grunnlag av leverandørens egne tabeller. Likevel er selve treningsgrepet viktig. Z.ai sier at selskapet ikke har brukt mer pre-training for å presse fram forbedringene. I stedet har det lært den eksisterende grunnmodellen å arbeide bedre.

Hva er egentlig nytt i GLM-5.3?

GLM-5.3 er en ny post-trained utgave av samme grunnmodell som GLM-5.2. Ifølge Z.ai sin kunngjøring 14. august 2026 kommer alle forbedringene fra flere kjørbare treningsmiljøer, mer varierte oppgaver og mer regnekraft brukt på lengre treningsforløp.

Grunnmodellen har omtrent 744 milliarder parametere. Den ble etablert i GLM-5-familien sammen med blant annet sparse attention, støtte for lang kontekst og et asynkront opplegg for reinforcement learning. Jeg har tidligere skrevet om hva som gjorde GLM-5 interessant som åpen modell. I 5.3 er ikke poenget en større motor, men bedre kjøreopplæring.

Post-training er alt som skjer etter at grunnmodellen har lært språk, kode og generell kunnskap fra enorme datasett. Her trenes modellen til å følge instruksjoner, bruke verktøy, kontrollere eget arbeid og holde fast ved et mål gjennom mange steg. For en vanlig chatbot kan forskjellen virke beskjeden. For en agent som skal jobbe i terminalen i flere timer, blir hvert dårlig valg dyrere jo lenger oppgaven varer.

Z.ai har derfor bygget miljøer som ligner faktiske arbeidsoppgaver. En modell kan få tilgang til kodebaser, dokumentasjon, lagring, regneklynger og eksperimentresultater. Den må finne flaskehalser, endre systemet, kjøre nye forsøk og levere en målbar forbedring uten å ødelegge korrektheten underveis. Noen av oppgavene skal tilsvare flere dagers arbeid for en erfaren utvikler.

Hvor stort er løftet i komplekst kodearbeid?

Det tydeligste offentlige utslaget kommer i oppgaver der modellen må arbeide lenge, bruke terminalverktøy og rette egne feil. På Terminal-Bench 3.0 øker GLM-5.3 fra 4,6 til 28,3 prosent sammenlignet med GLM-5.2. Det er et stort sprang, men fortsatt en leverandørrapportert benchmark – ikke en ferdig dom over modellen.

Målingen er nyttig fordi oppgavene krever mer enn å fullføre en kodebit. Agenten arbeider i en isolert container, får mange forsøk på å bruke verktøy og må levere noe som kontrolleres av en separat verifier. Det ligger langt nærmere utholdenheten en coding agent trenger enn en kort oppgave med ett riktig svar.

Z.ai sin private Code Bench peker også mot bedre tokenøkonomi: GLM-5.3 fullfører mer enn forgjengeren samtidig som den bruker mindre output. I ett av selskapets oppsett gjør den det også bedre enn Claude Opus 4.8 med klart lavere tokenbruk, mens Claude Fable 5 fortsatt ligger foran. Private tester er nyttige som utviklingssignal, men de kan ikke etterprøves på samme måte som åpne målinger.

Det forbeholdet er viktig. Modellene er kjørt med bestemte oppsett valgt av Z.ai, og den private testen er nettopp privat. Jeg leser derfor ikke tabellen som et bevis på at GLM-5.3 er bedre enn Claude eller GPT i praksis. Jeg leser den som støtte for den smalere og mer troverdige påstanden: 5.3 ser ut til å bruke både steg og tokens bedre enn 5.2.

Det er akkurat der dette kan bli nyttig. En agent som spiser færre tokens, men fullfører flere lange oppgaver, kan bli billigere å kjøre og mindre krevende å følge opp. Jeg vil likevel se uavhengige tester og åpne vekter før jeg vet hvor godt løftet overlever utenfor Z.ai sitt eget oppsett.

Hvordan fikk Z.ai mer ut av samme modell?

Z.ai skalerte ikke bare antallet oppgaver. Selskapet laget en produksjonslinje for kjørbare miljøer med flerstegsavhengigheter, skjult tilstand og kontrollerbare sluttresultater. En research-agent samler mønstre fra reelt arbeid, en annen agent forsøker oppgaven, og egne kontrollmekanismer sjekker at miljøet faktisk kan løses uten snarveier.

Det høres tørt ut, men dette er selve problemet med reinforcement learning for agenter. Det holder ikke å belønne et svar som ser riktig ut. Treningssystemet må kunne kjøre resultatet, kontrollere at modellen ikke har jukset og avgjøre om tilstanden faktisk ble bedre. Dårlige kontrollmekanismer lærer modellen å lure testen. Gode miljøer lærer den å gjøre jobben.

Under ligger det åpne rammeverket slime, med Megatron på treningssiden og SGLang for utrullingene. Z.ai oppgir at systemforbedringer har økt gjennomstrømmingen i reinforcement learning for langvarige kodeoppgaver med mer enn 2,3 ganger. Det gjør det praktisk mulig å trene på lengre forløp og flere kompliserte miljøer uten å bygge hele treningssystemet på nytt.

GLM-5.3 arver også SAO-opplegget fra GLM-5.2. Det er laget for asynkron agenttrening der lange oppgaver fullføres i svært ulikt tempo. Sammen med komprimering av kontekst skal det hjelpe modellen å bevare nytten over lange forløp, ikke bare bli flinkere i de første minuttene.

Dette er den virkelige lærdommen fra lanseringen. Kapasiteten i en grunnmodell er ikke det samme som kapasiteten vi får ut av den. Bedre oppgaver, mer pålitelig verifisering og lengre treningsforløp kan være minst like viktige som enda flere parametere. Det er gode nyheter for hele markedet, også for mindre aktører som ikke kan trene en ny modellfamilie hver måned.

Hvorfor krever sikkerhetsløftet et ekstra forbehold?

GLM-5.3 har blitt mye bedre til å følge en sårbarhet videre gjennom en hel angrepskjede. Den går forbi de oppgitte konkurrentene på Z.ai sin CyberGym-kjøring, mer enn dobler resultatet på ExploitBench og fullfører langt flere ExploitGym-oppgaver enn GLM-5.2. Samtidig øker avstanden til de sterkeste lukkede modellene jo dypere inn i utnyttelseskjeden testen går.

Z.ai sier selv at denne kapasiteten vokste raskere enn forventet. Treningen inneholdt miljøer for å finne sårbarheter, så sikkerhetsløftet kom ikke ut av ingenting. Overraskelsen var at modellen ikke bare ble bedre til å peke på en feil. Den lærte i større grad å resonnere gjennom flere steg og sette sammen en fungerende utnyttelseskjede.

Her er det lett å rive resultatene ut av sammenheng. GLM-5.3 gjør det best i den delen som handler om å finne og validere sårbarheter, men ligger fortsatt langt bak de sterkeste lukkede modellene på dypere utnyttelsesoppgaver. Z.ai måler altså raskest framgang på den delen der modellen fortsatt har størst avstand opp til toppen.

Siden GLM-5.2 har Z.ai samarbeidet med sikkerhetsteam om å teste reelle kodebaser. Etter faglig gjennomgang og fjerning av duplikater oppgir selskapet 2 436 sårbarheter i 269 prosjekter. Den offentlige oversikten viser 107 kritiske og 990 alvorlige funn, men bare 53 av de 2 436 funnene var offentliggjort da siden ble lansert. Resten var fortsatt under koordinert varsling.

Dette er imponerende forsvarsarbeid når sårbarhetene blir rapportert og rettet. Den samme kapasiteten kan åpenbart misbrukes. Z.ai utsetter derfor vektslippet i omtrent to uker for flere sikkerhetstester og herding. Det er ingen magisk sikkerhetsgaranti, men i dette tilfellet er det en helt reell grunn til at «åpne vekter» ikke betyr «last ned i dag».

Hva må du endre når GLM-5.3-API-et åpner?

GLM-5.3 er tilgjengelig for alle brukere av GLM Coding Plan nå, men Z.ai sin offisielle modellside sier 14. august at standard-API-et kommer snart. Modellvektene er varslet om omtrent to uker. Når API-et åpner, er den viktigste endringen at tenking alltid må være aktivert. Modellen støtter nivåene low, high og max, og Z.ai anbefaler max til koding.

Når API-et blir tilgjengelig, vil forespørselen feile dersom integrasjonen fortsatt bruker thinking.type: "disabled". Den dokumenterte løsningen er å endre til thinking.type: "enabled" og sette reasoning_effort til minst low før modell-ID-en endres til glm-5.3. Dette er en liten konfigurasjonsendring, men akkurat den typen detalj som kan spise en unødvendig time når alt annet ser riktig ut.

Ved maksimal innsats ser den nødvendige delen av forespørselen slik ut:

{
  "model": "glm-5.3",
  "thinking": { "type": "enabled" },
  "reasoning_effort": "max"
}

Den offisielle kunngjøringen nevner ZCode, Claude Code og OpenCode som aktuelle klienter. Z.ai har lagt 5.3 inn i Coding Plan for alle abonnenter og bruker nå poengbasert kvote. Det er praktisk tilgang, men ikke det samme som et åpent standard-API eller lokal kontroll. Hvis planen holder, kommer vektene rundt 28. august. Først da kan miljøet rundt åpne modeller begynne å pakke, kvantisere og teste den ordentlig.

Er GLM-5.3 verdt å følge med på?

Ja. Ikke fordi én benchmark sier 28,3 i stedet for 4,6, men fordi flere ulike målinger peker i samme retning: Modellen holder bedre ut i lange oppgaver, fullfører mer kodearbeid og bruker færre tokens i Z.ai sin private test. Det er nettopp disse egenskapene som skiller en nyttig agent fra en chatbot med terminaltilgang.

Jeg ville fortsatt ventet på åpne vekter og uavhengige tester før jeg flyttet viktig arbeid. Leverandørmålinger er leverandørmålinger, og 744 milliarder parametere er heller ikke noe folk flest bare laster inn på gaming-PC-en. Mindre spesialiserte coding-modeller kan være mer praktiske selv når de ikke vinner den største tabellen.

Likevel liker jeg retningen. GLM-5.3 viser at kappløpet ikke bare handler om å bygge en enda større grunnmodell. Det handler om å gi modellen realistiske arbeidsmiljøer, la den feile gjennom lange forløp og kontrollere om den faktisk løste oppgaven. Det er mindre glamorøst enn en ny parameterrekord. Det kan også være langt viktigere.

Ofte stilte spørsmål