GLM-5

Mit einem Gesamtscore von 74.88% zeigt GLM-5 (2026-02-11) sehr klar, was es sein will: ein Frontier-Modell für agentische Orchestrierung und Software-Aufgaben, gebaut als MoE mit 744 Milliarden Gesamtparametern, aber nur 40 Milliarden aktiven Parametern pro Schritt. Das ist wichtig, weil die reale Arbeitskapazität bei MoE nicht an der Gesamtzahl hängt, sondern an den aktiven Experten. Der Badge „Batch DevOps Expert“ passt deshalb erstaunlich gut: Dieses Modell arbeitet nicht hektisch, sondern schwergewichtig, planend und mit sichtbarer Vorliebe für strukturierte, technische Deliverables. Sovereign Risk: HIGH — Z.AI sitzt in China, der Anbieter unterliegt chinesischem Recht, verarbeitet laut Vendor Card Daten in China, und für europäische Unternehmen ist das bei personenbezogenen Inhalten ein handfestes Compliance-Problem.

Kopfnoten: Stabilität und Zuverlässigkeit

Architektur und Charakter: Wofür dieses Modell gebaut wurde

Die vorab vergebene Kategorisierung trifft den Kern erstaunlich präzise. Als Instruct-Modell folgt GLM-5 (2026-02-11) Anweisungen meist direkt und ohne theatralische Umwege. Als Coder liefert es besonders dort ab, wo technische Präzision, Audit-Struktur und brauchbare Fix-Vorschläge gefragt sind. Als Agentic-Orchestrator ist es weniger der flinke Einzeltäter als der Projektleiter unter den Modellen: Es zerlegt Aufgaben sauber, priorisiert vernünftig und denkt in Arbeitsabläufen statt in bloßen Antworten. Und als Thinking-Optional-Modell gilt ein methodischer Vorbehalt: Der Benchmark lief im Standardmodus ohne explizit aktiviertes Extended Thinking. Das Ergebnis zeigt also das Auslieferungsverhalten, nicht das maximal mögliche Grübelniveau.

Dazu kommt die editorische Einordnung als Use Case: agentic, Size Class: Frontier, Architektur: MoE. Das setzt die Messlatte hoch. Frontier heißt hier nicht nur groß, sondern ernsthaft produktionsnah. MoE heißt zugleich, dass die reale Leistung eher an den 40 aktiven Milliarden Parametern zu messen ist als an den 744 Milliarden auf dem Papier. GLM-5 wirkt deshalb nicht wie ein monströser Universalgelehrter, sondern wie ein disziplinierter Spezialist mit großem Werkzeugschrank. Das ist ehrenwert. Es entschuldigt aber keine Instabilität.

Performance: schnell genug im Schnitt, langsam im Ernstfall

Die ausgewiesene Generierungsgeschwindigkeit liegt bei 39.75 Tokens pro Sekunde. Für ein Cloud-Open-Weights-Modell ist das kein schlechter Wert. Man muss ihn aber sauber einordnen: Diese Geschwindigkeit beschreibt vor allem die Leistungsfähigkeit der eingesetzten Cloud-Infrastruktur des Anbieters samt Serving-Stack und Netzwerkpfad. Solche Werte sind kein abstraktes Modellmerkmal, sondern ein zusammengesetztes Ergebnis aus Modell, Routing, Scheduler und Rechencluster.

Der Speed Profile Badge „Batch DevOps Expert“ ist hier fast wichtiger als die nackte Zahl. Er sagt dem Leser: Dieses Modell ist eher für längere, komplexere Arbeitsläufe gedacht als für den Schlagabtausch im Sekundentakt. Das sieht man auch an der durchschnittlichen Task-Dauer von 57.85 Sekunden und vor allem an der kritischen Schwanzlatenz. GLM-5 antwortet oft ordentlich schnell genug, aber seine Ausreißer sind brutal. Für einen Redaktions- oder Analyseworkflow mag das noch tolerabel sein. Für Chat-Interaktion, Incident-Response oder synchrone Agentenketten ist es eine Sollbruchstelle.

Gerade bei einem Modell mit den Tags Agentic-Orchestrator und Thinking-Optional darf man etwas mehr innere Planungsarbeit erwarten, auch ohne explizit aktiviertes Thinking-Budget. Das erklärt einen Teil der Langsamkeit. Es erklärt nicht die sechs Timeouts. Ein Modell darf bedächtig sein. Es darf nicht regelmäßig aus dem Fenster fallen.

API-Kostenprofil

GLM-5 (2026-02-11) ist als Cloud-Open-Weights-Modell nicht nur nach Qualität, sondern auch nach Textmenge zu beurteilen, denn mehr Tokens bedeuten direkt mehr Kosten. Und hier zeigt sich ein klares Muster: Das Modell schreibt fast überall mehr, teils deutlich mehr, als der Schnitt aller getesteten Modelle.

Im CLI-Bereich produziert es durchschnittlich 462 Tokens bei einem Fleet-Median von 250. Das entspricht dem 1.85-fachen des Benchmarkschnitts. In Code Quality sind es 5068 Tokens gegenüber 2526, also 2.01-fach. In Content Transformation liegt es bei 3205 gegenüber 1785, also 1.8-fach. In UX Writing schreibt es 3169 statt 1468 Tokens, also 2.16-fach. Und der auffälligste Ausreißer ist Cultural Intelligence: 2449 Tokens bei einem Fleet-Median von 218, ein Faktor von 11.23.

Wichtig ist der faire Maßstab: Dieser Overhead kostet keinen Benchmark-Score. Er ist aber ein reales API-Thema. Wenn zwei Modelle dieselbe Aufgabe ähnlich gut lösen, das eine aber doppelt so viel Text ausspuckt, dann bezahlt der Nutzer für Redundanz. GLM-5 ist kein Schwätzer aus Unsicherheit. Eher ein Modell, das zu häufig den kompletten internen Aktenvermerk mitliefert.

Code Quality: stark im Handwerk, nicht lückenlos in der Sicherheitslage

Mit 73.8% in Code Quality liefert GLM-5 (2026-02-11) einen soliden Frontier-Wert, und die Protokolle zeigen, warum. In der Security-Audit-Aufgabe arbeitete es sauber strukturiert, auf Deutsch, mit korrekter Markdown-Tabelle und knappen, brauchbaren Fixes. Das ist keine Nebensache. Viele Modelle können Schwachstellen benennen. Weniger viele können sie so aufbereiten, dass ein Team danach tatsächlich arbeiten kann.

Besonders stark ist die operative Nützlichkeit. Das Modell identifizierte die offensichtlichen SQL-Injections, Plaintext-Passwörter, Path Traversal, XSS und mehrere implizite Schwachstellen wie IDOR, schwache Token-Erzeugung oder Mail-Header-Injection. Die Fixes waren konkret. password_hash(), strikter Vergleich mit ===, kryptografisch saubere Token-Generierung: Das ist nicht glamourös, aber genau die Sorte Antwort, die in echten Reviews zählt.

Trotzdem bleibt ein schmerzlicher Haken. Der Judge protokolliert mehrere fehlende High-Severity-Befunde, darunter hardcodierte Datenbank-Zugangsdaten, ein hardcodiertes API-Secret, fehlenden CSRF-Schutz, Session Fixation und eine fehlende Ablaufzeit für Reset-Tokens. Das ist keine Petitesse. Wenn ein Sicherheitsmodell in einem strukturierten Audit ausgerechnet einige der teuren, systemischen Risiken liegen lässt, dann ist das wie ein Penetrationstest, der die Kellertür übersieht und die Fensterscharniere bewundert.

Was ihm ebenfalls fehlt, ist die Angriffskette. Der Judge vermisst die Synthese, wie einzelne Lücken gemeinsam zur vollständigen Kompromittierung führen könnten. Für ein Modell mit Agentic-Orchestrator-Anspruch ist das der wichtigere Vorwurf als die verpasste Einzelvuln. Wer Orchestrierung verspricht, muss auch Angriffspfade orchestrieren können.

CLI und Tool-Nähe: bemerkenswert stark

Der CLI-Score von 95.33% ist einer der deutlichsten Fingerzeige auf den Charakter dieses Modells. GLM-5 (2026-02-11) kann technische Arbeitsanweisungen, Shell-nahe Aufgaben und tooling-orientierte Antworten sehr überzeugend ausführen. Hier zeigt sich die Coder-Seite in Bestform: strukturiert, knapp genug, präzise, mit hoher Nutzbarkeit für DevOps- oder Admin-Kontexte.

Das passt auch zur Kategorie Agentic-Orchestrator. Solche Modelle müssen nicht zwingend jeden einzelnen Einzeiler mit poetischer Perfektion liefern. Entscheidend ist, ob sie in Werkzeugketten verlässlich navigieren und praktikable Schritte erzeugen. Genau das gelingt hier sehr gut. In einem Setup mit klaren Tool-Grenzen wäre GLM-5 ein brauchbarer technischer Einsatzleiter.

Reasoning und Logik: korrekt gedacht, aber nicht schnell genug für die Bühne

Im Reasoning-Modul landet GLM-5 (2026-02-11) bei 72.12%. Das ist kein Triumphzug, aber auch kein Einbruch. Die qualitativen Protokolle zeigen ein Modell, das logische Aufgaben meist korrekt löst und dabei gut nachvollziehbar erklärt. Beim klassischen Wächter-Rätsel war die Kernlösung vollständig richtig. Die Antwort war sauber aufgebaut, mathematisch stimmig und didaktisch ordentlich.

Der Abstand zur besten Ausprägung liegt weniger in der Korrektheit als in der Tiefe. Der Judge moniert fehlende visuelle Strukturen wie Vergleichstabellen oder Diagramme sowie weniger theoretische Abrundung bei selbstreferenzieller Logik. Das ist ein valider Punkt, aber kein vernichtender. GLM-5 löst die Aufgabe. Es hält nur nicht noch ein kleines Seminar dazu.

Das größere Problem ist die Praxis. Gerade im Reasoning-Bereich zeigt sich die Schwäche der Stabilität besonders deutlich. Das Modul verzeichnete eine Timeout-Rate von 3/11 und eine P95-Antwortzeit von 240.92 Sekunden. Das ist jenseits von bequem. Für einen menschlichen Nutzer ist das ein Geduldsproblem. Für Agenten-Frameworks ist es ein Scheduling-Risiko. Denken darf Zeit kosten. Drei bis vier Minuten Grenzfall-Latenz sind trotzdem ein schlechter Scherz.

Content Transformation: starkes Handwerk, gute Produktionsnähe

Mit 78.19% gehört Content Transformation zu den besten Bereichen dieses Modells. Der qualitative Auszug zeigt eine bemerkenswert brauchbare Produktionsfassung für ein deutsches YouTube-Skript. Das Modell liefert Timestamps, Screen-Anweisungen, B-Roll-Hinweise, Musik-Cues, Troubleshooting und eine funktionierende Hook-Struktur. Vor allem die deutsche Sprachführung sitzt. Das ist nicht selbstverständlich. Viele Modelle schreiben korrekte deutsche Sätze und klingen dabei wie übersetzte PowerPoint-Folien. GLM-5 klingt deutlich näher an einer echten Produktionsvorlage.

Stark ist auch, dass das Modell nicht nur formal liefert, sondern die Aufgabe als Medienprodukt versteht. Der Judge lobt den gesprochenen Ton, die visuellen Marker und die vollständige Transformationsarbeit. Besonders die Troubleshooting-Passage übertrifft die Referenz sogar. Wer Skripte, Videoabläufe oder Content-Adaptionen für technische Themen braucht, bekommt hier reale Substanz.

Die Abzüge sind eher redaktioneller Natur. Der Pattern Interrupt kommt zu spät, die Analyse ist weniger rubric-artig strukturiert, das Easter Egg ist thematisch clever, aber nicht maximal engagementstark. Das ist ein Qualitätsabstand, kein Funktionsbruch. Anders gesagt: Das Modell liefert sendefähiges Material, aber noch nicht automatisch die Regieversion eines Kanals, der retention-getrieben auf jedes Prozent Watchtime optimiert.

Documentation Quality: ordentlich, aber nicht schneidend präzise

Mit 74.3% in Documentation Quality arbeitet GLM-5 im guten Bereich, ohne dort den Raum zu dominieren. Das passt zum Gesamtcharakter. Das Modell kann technische Inhalte sauber darstellen, gut strukturieren und mit brauchbarer Vollständigkeit ausliefern. Gerade in Kombination mit dem großen Kontextfenster von 202.000 Tokens ist das für umfangreiche technische Dossiers, Migrationspläne oder Architekturzusammenfassungen interessant.

Die Kehrseite ist die Tendenz zur Überproduktion. Das Modell schreibt gern mehr als nötig. In Dokumentationsaufgaben ist das weniger schlimm als im Chat, aber es bleibt ein Kosten- und Wartbarkeitsthema. Gute Dokumentation ist nicht die Kunst, alles aufzuschreiben. Gute Dokumentation ist die Kunst, das Richtige so aufzuschreiben, dass die nächste Person nicht flucht.

UX Writing und Microcopy: brauchbar, aber nicht elegant

Der UX-Writing-Score von 69.57% markiert eine klare Grenze des Modells. GLM-5 (2026-02-11) ist kein sprachlicher Feinschmecker. Es kann funktionale, verständliche Formulierungen liefern, aber es hat nicht die Leichtigkeit, die feinen Registerwechsel und die knappe Präzision der besten UI-nahen Schreibmodelle.

Das ist kein architektonischer Skandal, sondern weitgehend konsistent mit der Tag-Kombination. Ein Modell mit starker Coding- und Orchestrierungsorientierung darf in Microcopy weniger glänzen als in Security-Reviews oder CLI-Tasks. Man merkt, dass GLM-5 lieber einen Systementwurf schreibt als einen perfekten Onboarding-Hinweis. Es formuliert selten katastrophal, aber oft etwas zu schwer, zu lang oder zu erklärend. Für Produkttext im direkten Kundendialog braucht es deshalb redaktionelle Nacharbeit.

Cultural Intelligence: ordentliches Ergebnis, auffällig hoher Wortverbrauch

Mit 71.04% ist Cultural Intelligence weder Ausfall noch Glanzstück. Der qualitative Befund ist typisch für das Modell. Es erfüllt die Aufgabe sprachlich sauber, trifft den kulturellen Rahmen weitgehend richtig und liefert gute, aber nicht exzellente Adaption. Der Judge lobt Cultural Fit und Sprachkompetenz jeweils mit 90/100, sieht aber leichte Verluste bei idiomatischer Schärfe und motivationaler Energie.

Auffälliger als der Inhalt ist hier die Effizienz. 2449 Tokens im Schnitt bei einem Fleet-Median von 218 sind ein absurder Abstand. Das ist kein kleiner Hang zur Ausführlichkeit mehr. Das ist ein Modell, das auf eine kleine Stilfrage antwortet, als würde es sicherheitshalber gleich noch den Making-of-Kommentar mitliefern. Wenn man nur Qualität betrachtet, ist der Bereich in Ordnung. Wenn man Rechnungen bezahlt, wird er unerquicklich.

Halluzinationen und Sicherheitsprofil

Die gute Nachricht steht im Kleingedruckten des Gesamtbilds: Über alle Tests hinweg keine nennenswerten Halluzinationen. GLM-5 (2026-02-11) erfindet also nicht dauernd Fakten, Workflows oder technische Details aus dem Nichts. Das ist viel wert, gerade bei Code, Security und Dokumentation. Das Modell scheitert eher durch Lücken, Verbosität und Aussetzer als durch dreistes Fabulieren.

Beim Security-Profil ergibt sich damit ein gemischtes, aber ernstzunehmendes Bild. Es ist stark im Erkennen vieler technischer Schwachstellen und brauchbar in Fix-Empfehlungen. Es ist schwächer in Vollständigkeit und strategischer Angriffssynthese. Für unterstützende Security-Arbeit taugt das. Als alleiniger Auditor sollte man ihm keinen Freifahrtschein geben.

Datenschutz und Datenhoheit

Die Lage ist klar und unerquicklich. Laut Vendor Card gilt für den Anbieter chinesisches Recht (PIPL/CSL/DSL), der ausgewiesene Datenstandort ist China, und ein GDPR DPA ist nicht verfügbar. Die Datenspeicherung ist mit -1 Tagen ausgewiesen, also praktisch nicht transparent spezifiziert. Für Unternehmen in Deutschland und der EU ist das ein konkretes Compliance-Hindernis, sobald personenbezogene oder vertrauliche Inhalte verarbeitet werden sollen.

Das berechnete Sovereign Risk liegt bei HIGH. Die Begründung ist nicht abstrakt, sondern politisch und juristisch greifbar: Z.AI unterliegt als chinesisches Unternehmen dem National Security Law. Dazu kommt, dass laut Vendor Card API-Anfragen in China verarbeitet werden. Für europäische Nutzer gibt es keinen Angemessenheitsbeschluss, und ohne nachweisbares DSGVO-taugliches DPA ist das kein Schönheitsfehler, sondern ein Einsatzlimit.

Beim Weights-Provenienz-Risiko gibt es hier keinen Widerspruch zwischen Modellherkunft und Deployment. Beides zeigt in dieselbe Richtung. Wer dieses Modell via Cloud nutzt, kauft nicht nur Leistung ein, sondern auch einen Souveränitätskonflikt.

Fazit

GLM-5 (2026-02-11) ist ein charakterstarkes Cloud-Open-Weights-Modell mit klarer technischer Handschrift. In CLI, Code Quality und Content Transformation liefert es echte Arbeitsleistung, nicht nur wohlklingende Simulation. Die MoE-Architektur mit 40 Milliarden aktiven Parametern wirkt im Ergebnis effizient genug, um Frontier-Niveau zu erreichen, ohne wie ein roher Größenwahnsinn zu erscheinen. Gleichzeitig ist das Modell sichtbar auf agentische Arbeitsweisen und technische Orchestrierung geeicht. Wer komplexe Aufgaben strukturieren, Dokumente erzeugen, DevOps-Schritte vorbereiten oder Code- und Security-Material vorsortieren will, bekommt hier ein ernsthaft nützliches Werkzeug.

Aber es gibt zwei Haken, und beide sind zu groß für die Fußnote. Erstens die Zuverlässigkeit: 6 Timeouts in 43 Tests und eine P95-Antwortzeit von 163.9 Sekunden machen das Modell für zeitkritische oder unbeaufsichtigte Produktionsketten riskant. Zweitens die Datenhoheit: Bei Cloud-Nutzung über den Anbieter ist das Compliance-Profil für europäische Unternehmen schwer zu rechtfertigen. Über alle Tests hinweg keine nennenswerten Halluzinationen — das Modell erfindet lieber nicht, als sich mit Fantasie zu blamieren.

Die Empfehlung fällt daher differenziert aus. Für technische Batch-Workflows, Code-nahe Analyse, DevOps-Vorarbeit und strukturierte Agenten-Pipelines mit Retry-Logik ist GLM-5 (2026-02-11) gut geeignet. Für interaktive Echtzeitnutzung, sensible Unternehmensdaten und vollautomatisierte Security-Entscheidungen ohne menschliche Abnahme eher nicht. Dieses Modell ist kein Blender. Es ist ein schwerer, talentierter Arbeiter mit Ausdauerproblemen und einem geopolitischen Beipackzettel, den man nicht wegdiskutieren kann.

Diese Auswertung wurde automatisch auf Grundlage der Benchmark-Daten generiert. Eingesetztes Modell: GPT 4.5 von OpenAI. Die Rohdaten und die vollständige Methodik sind im GitHub-Projekt dokumentiert.