Was ist GLM 5.2? Open-Weight-Coding zum Sechstel des Preises

Die Ein-Satz-Version

GLM 5.2 ist das Open-Weight-Flaggschiff-Sprachmodell von Z.ai. Es wurde am 13. Juni 2026 veröffentlicht und speziell für Coding, Schlussfolgerungen und toolgestützte „agentische“ Arbeit entwickelt – also für mehrstufige Aufgaben, bei denen ein Modell plant, Tools aufruft, Ergebnisse liest und sich über eine lange Sitzung hinweg korrigiert.

Z.ai ist die internationale Marke von Zhipu AI, einem Forschungsunternehmen aus Peking, das 2019 aus der Knowledge Engineering Group der Tsinghua-Universität hervorgegangen ist. „Open-Weight“ ist dabei der entscheidende Begriff: Die tatsächlichen Parameter des Modells werden auf Hugging Face (unter zai-org/GLM-5.2) sowie auf ModelScope und Ollama veröffentlicht – unter einer MIT-Lizenz und ohne regionale Einschränkungen. Du kannst es selbst hosten, feinabstimmen und in einem kommerziellen Produkt einsetzen, ohne jemanden fragen zu müssen.

Warum ein Open-Weight-Coding-Modell mehr bedeutet als seine Benchmarks

Bevor wir zum technischen Aufbau kommen, geht es um die Motivation. Der Grund, warum diese Veröffentlichung Aufmerksamkeit bekam, ist nicht, dass es das intelligenteste Modell der Welt wäre – das ist es nicht. Entscheidend ist, dass es den Abstand zur geschlossenen Frontier weitgehend schließt und gleichzeitig kostenlos heruntergeladen und günstig genutzt werden kann. Für Entwickler verändert das die Kalkulation bei zwei Entscheidungen, die früher meist feststanden.

Die erste ist die Abhängigkeit vom Anbieter. Wenn dein Coding-Agent auf einer geschlossenen API läuft, kannst du ihn nicht offline ausführen, nicht inspizieren, und der Preis richtet sich nach dem, was der Anbieter im nächsten Quartal entscheidet. Offene Gewichte beseitigen alle drei Einschränkungen gleichzeitig. Die zweite ist der Preis. Die gemeldeten API-Preise für GLM 5.2 liegen bei 1,40 $ pro Million Eingabe-Token und 4,40 $ pro Million Ausgabe-Token. Z.ai positioniert das Modell damit bei ungefähr einem Sechstel der Kosten vergleichbarer Frontier-Modelle. Für einen Workload, der viele Token verbraucht – und agentisches Coding verbraucht sehr viele – ist dieses Verhältnis die ganze Geschichte.

Der Haken – und es gibt immer einen Haken: Die offenen Gewichte kannst du sicher selbst hosten. Wenn du deine Daten jedoch über die Cloud-API von Z.ai leitest, laufen sie durch eine Infrastruktur, die dem chinesischen Gesetz zur nationalen Nachrichtendiensttätigkeit unterliegt. Das US-Heimatschutzministerium hat gewarnt, dass dieses Gesetz chinesische Unternehmen dazu verpflichten könnte, Daten über US-Personen herauszugeben. Beide Fakten bestehen nebeneinander: kostenlose, überprüfbare Gewichte, die du überall ausführen kannst, und eine gehostete API mit einer echten Frage zur Datenhoheit. Welcher Aspekt für dich gilt, hängt vollständig davon ab, ob du selbst hostest oder die Cloud aufrufst. Darauf komme ich noch zurück.

Wie es funktioniert – ohne Ausflüchte

GLM 5.2 ist ein Mixture-of-Experts-Modell (MoE). Die gemeldete Größe liegt bei etwa 744 bis 753 Milliarden Gesamtparametern – die Quellen weichen leicht voneinander ab, was selbst ein Zeichen dafür ist, dass sich die genaue Zahl noch einpendelt. Für jedes einzelne Token sind jedoch nur ungefähr 40 Milliarden Parameter aktiv.

Diese Aufteilung ist der zentrale Trick, daher lohnt sich ein Vergleich. Ein dichtes Modell ist wie ein einzelner Generalist, der bei jeder Frage über alles nachdenken muss. Ein MoE-Modell ähnelt eher einem großen Unternehmen: Es verfügt über das Wissen einer sehr großen Organisation, aktiviert für eine bestimmte Aufgabe aber nur die wenigen relevanten Spezialisten. Du erhältst die Kapazität eines Modells mit 744 Milliarden Parametern zu ungefähr den Bereitstellungskosten eines Modells mit 40 Milliarden Parametern. Im Vergleich zu seinem Vorgänger GLM 4.5 – insgesamt 355B, davon 32B aktiv – hat GLM 5 das Unternehmen vergrößert (auf 744B / 40B) und mit mehr Daten trainiert (28,5 Billionen Token statt 23 Billionen).

Drei weitere Komponenten sind wichtig. Jede davon löst ein konkretes Problem, statt nur eine Feature-Liste aufzublähen.

Die erste ist ein Sparse-Attention-Design, das Z.ai IndexShare nennt. Es löst folgendes Problem: Die Kosten der Attention steigen schmerzhaft, wenn das Kontextfenster länger wird – und das Kontextfenster von GLM 5.2 ist sehr lang (dazu später mehr). Normalerweise berechnet ein Modell in jeder Schicht neu, auf welche früheren Token es achten soll. IndexShare berechnet diesen Index nur in der ersten von jeweils vier Attention-Schichten und verwendet ihn für die folgenden drei wieder. Z.ai zufolge reduziert dies die Kosten der Dot-Product-Indizierung in den wiederverwendeten Schichten um 75 % und die Berechnung pro Token bei der vollständigen Kontextlänge von einer Million Token um etwa das 2,9-Fache. Einfach gesagt: Dadurch wird ein Kontext von einer Million Token überhaupt erst bezahlbar ausführbar.

Die zweite Komponente sind duale Reasoning-Modi – zwei auswählbare Einstellungen für den Denkaufwand namens High und Max. Max ist für schwieriges, mehrstufiges Coding gedacht, bei dem das Modell Raum zum Planen und Überarbeiten benötigt; bei einer einzelnen Aufgabe kann es fast 85.000 Ausgabe-Token verbrauchen. High büßt nur wenige Leistungspunkte ein, halbiert die Token-Ausgabe aber ungefähr. Das ist die Einstellung, die du wählst, wenn Latenz und Kosten wichtiger sind als der letzte Prozentpunkt. Die Zusammenfassung in einem Satz: Max, wenn Korrektheit alles ist; High für die tägliche Arbeit.

Die dritte Komponente ist Multi-Token-Prediction. Damit kann das Modell mehrere Token in einem Forward-Pass statt nacheinander vorhersagen – für schnellere Inferenz und nebenbei bessere Kohärenz über längere Abschnitte.

Zusammengenommen ergibt sich als praktische Kernaussage das Kontextfenster: bis zu 1.000.000 Eingabe-Token (über die Kennung glm-5.2[1m]), bei bis zu 131.072 Ausgabe-Token. Das ist ungefähr fünfmal so viel wie das Limit von GLM 5.1 mit rund 200.000 Token. Eine Million Token reicht aus, um eine mittelgroße Codebasis auf einmal im Kontext zu halten – genau auf diesen Anwendungsfall zielt das gesamte Design ab.

Wie gut ist es wirklich?

Hier ist es wichtig, zwischen verschiedenen Vertrauensstufen zu unterscheiden. Deshalb sage ich ausdrücklich, was eine Tatsache und was eine gemeldete Zahl ist.

Die Tatsache: Z.ai hat GLM 5.2 ohne offizielle Benchmark-Suite veröffentlicht. Jede Zahl, die du im Umlauf gesehen hast, stammt entweder nachträglich vom Anbieter oder aus frühen unabhängigen Evaluierungen; bisher wurde keine davon umfassend reproduziert. Betrachte die konkreten Dezimalzahlen als Richtungsangaben, nicht als unumstößliche Wahrheit.

Unter diesem Vorbehalt stimmen die gemeldeten Zahlen aus verschiedenen Quellen überein und weisen in dieselbe Richtung. Bei Terminal-Bench 2.1 (autonomes Coding im Terminal) soll GLM 5.2 einen Wert von 81,0 erreichen – ein großer Sprung gegenüber den 62,0 von GLM 5.1 und nur etwa vier Punkte hinter den 85,0 von Claude Opus 4.8. Bei SWE-bench Pro (der Lösung echter Softwareentwicklungsprobleme) soll es 62,1 erreichen – vor GPT-5.5 mit 58,6 und dem eigenen Vorgänger mit 58,4, aber hinter Claude Opus 4.8 mit 69,2. Im Intelligence Index von Artificial Analysis soll es 51 Punkte erreicht haben – den höchsten Wert aller Open-Weight-Modelle.

Was diesen Zahlen mehr Gewicht verleiht als der üblichen Tabelle eines Anbieters, ist die unabhängige Bestätigung, die schwerer zu manipulieren ist. In Arena.ais Code Arena – einer Elo-Rangliste auf Basis blinder paarweiser Abstimmungen durch Menschen – soll GLM 5.2 insgesamt den zweiten Platz belegt haben. In der gemeinschaftlich erstellten Design Arena soll es mit einer Elo-Wertung von 1360 sogar den ersten Platz erreicht haben, noch vor Claude Fable 5. Blinde menschliche Präferenzabstimmungen lassen sich deutlich schwerer manipulieren als eine selbst gemeldete Erfolgsquote. Daher würde ich diesen beiden Ergebnissen am meisten vertrauen.

Meine Einschätzung, ausdrücklich als Urteil und nicht als Tatsache: GLM 5.2 ist derzeit das stärkste verfügbare Open-Weight-Coding-Modell, schlägt GPT-5.5 bei mehreren Coding-Aufgaben und liegt bei den schwierigsten Aufgaben mit langem Planungshorizont je nach Aufgabe zwischen einem und ungefähr dreizehn Punkten hinter Claude Opus 4.8. Nah dran, aber nicht vorn – zu einem Bruchteil des Preises.

GLM 5.2 vs. Claude Opus 4.8 vs. GPT-5.5

Für alle, die zwischen den drei Modellen wählen, lassen sich die Kompromisse klar ordnen. Die Tabelle enthält gemeldete Coding-Benchmark-Werte sowie unveränderliche Fakten wie Preis, Kontext und Lizenzierung:

Die ehrliche Zusammenfassung: Claude Opus 4.8 ist bei den schwierigsten agentischen Coding-Aufgaben weiterhin das leistungsfähigste der drei Modelle und die sichere Standardwahl, wenn du für Korrektheit bei langen, autonomen Durchläufen bezahlst. GPT-5.5 liegt bei diesen speziellen Coding-Benchmarks dazwischen. Das Argument für GLM 5.2 lautet nicht „Es ist das beste“, sondern: „Es liegt nur wenige Punkte hinter dem besten Modell, ist offen verfügbar und kostet einen Bruchteil.“ Wenn du kostenbewusst bist, selbst hosten oder feinabstimmen möchtest, ist das ein starkes Argument. Wenn du unternehmenskritische Agenten mit langem Planungshorizont betreibst, bei denen sich ein paar Zuverlässigkeitspunkte bezahlt machen, ist Claude Opus 4.8 die konservativere Wahl. Die Preise für Claude werden von Anthropic veröffentlicht; die GLM-Zahlen sind die gemeldeten Tarife von Z.ai.

Wenn du die beiden geschlossenen Konkurrenten anhand deiner eigenen Prompts per A/B-Test vergleichen möchtest, kannst du beide über eine einzige API bei GPT Proto aufrufen – Claude Opus 4.8 (thinking) und GPT-5.5 – jeweils zum Festpreis von 4 $ pro Million Token. (Dieser Festpreis stammt von GPT Proto; die Aufteilung von 5,00 $ / 25,00 $ für Eingabe und Ausgabe in der obigen Tabelle ist der offizielle Listenpreis von Anthropic für Opus 4.8 – dasselbe Modell, zwei unterschiedliche Preisstrukturen.) Alle drei Modellfamilien hinter einem einzigen Schlüssel zu bündeln, ist die günstigste Möglichkeit, den Vergleich selbst durchzuführen.

GLM 5.2 im Vergleich zu den heute verfügbaren GLM-Modellen

GLM 5.2 wird selbst als offene Gewichte ausgeliefert, die du herunterladen und hosten kannst – die gehostete API von Z.ai ist die einzige Möglichkeit aus erster Hand, es aufzurufen, und wie oben beschrieben bringt das eine Frage zur Datenhoheit mit sich. Die GLM-Reihe begann jedoch nicht mit 5.2. Der Sprung gegenüber den vorherigen Versionen zeigt am deutlichsten, was sich tatsächlich verändert hat.

Der nützlichste Vergleich ist der mit GLM 5.1, dem direkten Vorgänger. Zwei Unterschiede stechen hervor. Das Kontextfenster wuchs von ungefähr 200.000 Token auf volle 1.000.000 – ein Fünffachsprung und das wichtigste Upgrade. Auch beim Coding sind die gemeldeten Verbesserungen groß: Terminal-Bench 2.1 stieg von 62,0 auf 81,0 und SWE-bench Pro von 58,4 auf 62,1. Anders gesagt: Der größte Teil der Platzierung von GLM 5.2 in den Ranglisten ist eine Verbesserung gegenüber der eigenen letzten Veröffentlichung und keine kleine Optimierung.

Wenn du heute lieber ein gehostetes GLM über eine einzige OpenAI-kompatible API aufrufen möchtest, statt die offenen Gewichte selbst bereitzustellen, führt GPT Proto derzeit die GLM-Modelle, die in der Entwicklungslinie direkt hinter 5.2 liegen:

GLM-5.1 ist das Modell, das 5.2 hier am nächsten kommt – dieselbe Familie, eine Generation älter, mit einem Kontext von etwa 200.000 statt 1 Million Token. Bei vielen Coding-Aufgaben wirst du den Unterschied nicht bemerken. Bei Aufgaben auf Repository-Ebene, die die gesamte Codebasis gleichzeitig im Kontext benötigen, ist es jedoch genau die Lücke, die 5.2 schließt. Die vollständigen Tokenpreise für jedes Modell findest du auf der Modellseite.

GLM 5.2 in Claude Code verwenden – mit einem ausführbaren Beispiel

Ein Detail macht die GLM-Reihe ungewöhnlich einfach in bestehende Workflows integrierbar: GLM 5.2 bietet einen Anthropic-kompatiblen Endpunkt. Tools, die für die Kommunikation mit Claude entwickelt wurden – Claude Code, Cline, OpenCode – können direkt darauf zeigen. So lässt sich das Modell hinter einem Coding-Agent austauschen, ohne die Integration neu zu schreiben. Deshalb ist „GLM 5.2 in Claude Coding“ ein echtes Muster und nicht nur eine Suchphrase: Das Agenten-Framework bleibt gleich, nur das darunterliegende Modell ändert sich. (Bei 5.2 bedeutet das konkret den eigenen Endpunkt von Z.ai oder eine selbst gehostete Bereitstellung, da die offenen Gewichte der Weg aus erster Hand sind.)

Wenn du keine Bereitstellung verwalten möchtest, besteht der praktische Schritt heute darin, ein gehostetes GLM über die OpenAI-kompatible API von GPT Proto aufzurufen. Hier ist ein Beispiel mit GLM 5.1 – dem verfügbaren Geschwistermodell, das 5.2 am nächsten kommt. Es eignet sich als gute Grundlage, bevor du entscheidest, ob sich der zusätzliche Kontext von 5.2 für das Selbsthosting lohnt:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_GPTPROTO_API_KEY",
    base_url="https://api.gptproto.com/v1",
)

resp = client.chat.completions.create(
    model="glm-5.1",
    messages=[
        {
            "role": "user",
            "content": (
                "Refactor this function for readability and explain the change:\n\n"
                "def f(x):\n"
                "    return [i for i in x if i % 2 == 0]"
            ),
        }
    ],
)

print(resp.choices[0].message.content)

Dieselbe Anfrage mit cURL:

curl https://api.gptproto.com/v1/chat/completions \
  -H "Authorization: Bearer $GPTPROTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.1",
    "messages": [
      {"role": "user", "content": "Write a Python function that returns the nth Fibonacci number, iteratively."}
    ]
  }'

Ersetze glm-5.1 durch glm-5 oder glm-5-turbo, um Qualität gegen Kosten abzuwägen, oder durch claude-opus-4-8-thinking / gpt-5.5, um den exakten Vergleich aus der obigen Tabelle durchzuführen – alles über denselben Schlüssel.

Diesen Schlüssel brauchst du zuerst: Erstelle ihn im GPT Proto-Dashboard, füge ihn in YOUR_GPTPROTO_API_KEY ein, und der obige Aufruf funktioniert unverändert. Die Tokenpreise für jedes Modell findest du auf der Modellseite, wenn du die Kosten vorab kalkulieren möchtest.

Wo es stark ist – und wo nicht

Die Stärken sind konkret: Es ist das führende Open-Weight-Coding-Modell in den vorhandenen Ranglisten, wird unter einer tatsächlich großzügigen MIT-Lizenz veröffentlicht, sein Kontext von einer Million Token ist dank IndexShare real und bezahlbar ausführbar, und sein Verhältnis von Kosten zu Leistung ist in seiner Klasse das beste.

Die Schwächen sind ebenso konkret und sollten offen benannt werden, statt sie zu verschleiern. Bei den schwierigsten Coding-Aufgaben mit langem Planungshorizont liegt es hinter Claude Opus 4.8 – der Abstand ist klein, aber konstant. Z.ai hat keine offiziellen Benchmarks veröffentlicht, daher steht hinter den Zahlen ein Sternchen, bis weitere unabhängige Labore sie reproduzieren. Und die Frage zur Datenhoheit bei der Cloud-API ist real: Wenn deine Daten eine bestimmte Grenze aus rechtlichen oder vertraglichen Gründen nicht verlassen dürfen, ist die gehostete Z.ai-API der falsche Weg. Hoste stattdessen die offenen Gewichte selbst – genau dafür sind sie offen.

Wer sollte es nutzen – und wer nicht?

Nutze GLM 5.2, wenn du als Entwickler Coding-Fähigkeiten nahe der Frontier ohne Frontier-Preise möchtest, selbst hosten oder feinabstimmen musst oder ein kostenbewusstes agentisches Produkt entwickelst, bei dem der Tokenverbrauch den größten Kostenfaktor darstellt. Es passt besonders gut, wenn du bereits ein Claude-kompatibles Agenten-Framework hast und dahinter eine günstigere Engine einsetzen möchtest.

Greife stattdessen zu Claude Opus 4.8, wenn du unternehmenskritische, autonome Agenten mit langem Planungshorizont betreibst, bei denen sich die letzten Zuverlässigkeitspunkte den Aufpreis lohnen, oder wenn deine Arbeit an Regeln zur Datenresidenz gebunden ist, die die gehostete GLM-API nicht erfüllen kann und du nicht selbst hosten kannst.