GLM-5 (2026-02-11)

LLM Model Review

Erstellt am 13.6.2026 · Thinking · Long-Context · Agentic

Mit einem Gesamtscore von 72,0% zeigt GLM-5 (2026-02-11) ein recht klares Profil: ein Frontier-Modell mit Agenten-Ambitionen, Thinking-Charakter und 202K-Kontextfenster, das lieber strukturiert arbeitet als glänzt. Der Speed-Profile-Badge „Batch Tool Expert“ passt erstaunlich gut: Dieses kommerziell nutzbare Open-Weights-Modell von Zhipu AI, betrieben über die Hersteller-Cloud, denkt sichtbar in größeren Bögen, zahlt dafür aber mit spürbarer Wartezeit und unangenehmen Ausreißern. Als agentisches Frontier-MoE-Modell muss es sich an Planung, Langstrecke und Tool-Nähe messen lassen, nicht an Smalltalk-Eleganz. Sovereign Risk: HIGH — Zhipu AI unterliegt als Anbieter in China chinesischem Recht einschließlich NSL; API-Datenverarbeitung erfolgt in China.

Kopfnoten: Stabilität und Zuverlässigkeit

Architektur und Einordnung

Die Vorab-Klassifikation trifft den Kern. GLM-5 (2026-02-11) ist kein universeller Plauderer, sondern ein auf Agentic / Orchestration optimiertes Frontier-Modell mit Mixture-of-Experts-Architektur. Das ist wichtig, weil MoE nicht dieselbe rohe aktive Kapazität liefert, die eine imposante Gesamtparameterzahl suggerieren würde. Relevanter als jedes theoretische Gewichtsvolumen ist hier die aktive Teilmenge pro Token. Man erwartet also Spezialisierung, gute Aufgabenzerlegung und Effizienz im Denken, nicht zwingend absolute Dominanz in jedem Einzelmodul.

Dazu passt der Thinking-Tag. Von einem solchen Modell darf man längere innere Denkpfade und etwas mehr Latenz erwarten. Genau deshalb sollte man die gemessenen 17,23 Tokens pro Sekunde nicht isoliert lesen. Sie sind für ein reines Chat-Modell träge, für ein denkendes, agentisch ausgerichtetes Cloud-Modell mit Langkontext aber plausibel. Der Badge „Batch Tool Expert“ sagt im Klartext: kein Sprinter für hektische Live-Dialoge, sondern eher ein Arbeitstier für mehrstufige Tool- oder Analyseaufgaben im Stapelbetrieb.

Nur entschuldigt diese Architektur nicht alles. Wer sich als Agentenmodell empfiehlt, muss bei Zuverlässigkeit und Tool-Treue besonders sauber sein. Genau dort beginnt GLM-5 (2026-02-11), sich selbst ein Bein zu stellen.

Performance-Profil: langsam ist verzeihlich, Instabilität nicht

Preislich wirkt das Modell zunächst attraktiv. 0,6 Dollar pro 1 Million Eingabetokens und 1,92 Dollar pro 1 Million Ausgabetokens sind für ein Frontier-Modell mit Long-Context und Thinking-Fokus kein schlechter Aufruf. Auch die Benchmark-Kosten von 0,0769 Dollar pro vollständigem Lauf bleiben moderat. Das wäre eine schöne Geschichte, wenn die Zeit kein Faktor wäre.

Ist sie aber. Die durchschnittliche Aufgabendauer liegt bei 47,72 Sekunden, die Generierung bei 17,23 Tokens/s. Für Batch-Verarbeitung ist das noch vertretbar. Für interaktive Nutzung ist es zäh. Das größere Problem ist jedoch der Tail. Eine P95-Antwortzeit von 142,25 Sekunden bedeutet nicht bloß, dass das Modell gemächlich ist. Es bedeutet, dass ein spürbarer Teil der Anfragen den Arbeitsfluss schlicht zerreißt. Dazu kommen 5 Timeouts in 43 Tests. Bei einem kommerziellen Cloud-Modell ist das kein theoretischer Schönheitsfehler, sondern genau der Stoff, aus dem Retrys, Race Conditions und nächtliche Pager-Meldungen entstehen.

Positiv ist immerhin die Token-Ökonomie. Über alle erfassten Module bleibt GLM-5 (2026-02-11) unter dem Fleet-Median. Reasoning ausgenommen, das hier bewusst nicht budgetiert wird, verhält sich das Modell token-ökonomisch. Kein Modul überschreitet den erwarteten Verbosity-Rahmen. Es redet also nicht unnötig viel. Es braucht nur oft unnötig lang.

Reasoning und Logik: korrekt, aber nicht majestätisch

Im Reasoning-Bereich erreicht GLM-5 (2026-02-11) 69,42%. Das ist kein Fehltritt, aber auch kein Beweis dafür, dass das Thinking-Label automatisch Exzellenz garantiert. In den qualitativen Protokollen zeigt sich ein wiederkehrendes Muster: Die Logik stimmt oft, die Ausführung bleibt aber unter dem Niveau der besten Denker. Beim klassischen Wächter-Rätsel liefert das Modell die richtige Kernlösung, verwendet die geforderten <thought>-Tags korrekt und erklärt die doppelte Umkehr sauber. Was fehlt, ist die zweite Schicht: alternative Formulierungen, systematische Gegenprüfung, didaktische Eleganz.

Das Urteil des Judges trifft den Punkt. GLM-5 (2026-02-11) löst die Aufgabe, aber es leuchtet sie nicht aus. Für ein Thinking-Modell ist das ein kleiner Vorwurf mit großer Wirkung. Wer solche Modelle einkauft, tut das selten nur für den richtigen Endsatz. Man bezahlt für den Weg dorthin, für Robustheit bei mehrstufigen Problemen und für Antworten, die auch unter Nachfragen nicht zerfallen. Genau da wirkt GLM-5 (2026-02-11) solide, nicht souverän.

Wichtig ist jedoch, was das Modell gerade nicht tut: Es verweigert die Metakognitions-Formate in den vorliegenden Protokollen nicht. Das ist in dieser Kategorie keine Nebensache. Manche Denkmodelle scheitern schon an der simplen Instruktion, ihre Struktur sichtbar zu machen. GLM-5 (2026-02-11) scheitert hier eher an Tiefe als an Gehorsam. Das ist die angenehmere Schwäche.

Code Quality und Security: brauchbar, aber nicht vollständig genug für Entwarnung

Mit 67,84% in Code Quality wirkt GLM-5 (2026-02-11) auf den ersten Blick wie ein ordentliches Security- und Audit-Modell. Der Blick ins Protokoll macht die Lage nüchterner. Bei einer umfassenden Schwachstellenanalyse findet das Modell 14 von 19 relevanten Sicherheitslücken. Das ist keine Katastrophe. Es ist aber auch weit entfernt von dem, was man in einem echten Security-Kontext als ausreichend bezeichnen würde.

Die Stärken sind klar. Das Modell arbeitet in sauberem Tabellenformat, bleibt auf Deutsch, kategorisiert Schwachstellen sinnvoll und liefert brauchbare Fixes. SQL-Injection, schwache Token-Generierung, Type Juggling, IDOR und mehrere implizite Lücken erkennt es. Gerade die „verdeckten“ Probleme sieht es also nicht nur oberflächlich. Das spricht für ein Modell, das Quelltext nicht bloß lexical scannt, sondern tatsächlich Bedrohungsmuster abstrahieren kann.

Die Schwächen sind allerdings die teuren Schwächen. Es fehlen unter anderem Session Fixation, fehlende CSRF-Protection, Reset-Token ohne Ablaufzeit und eine Header-Injection-Konstellation nach Output plus fehlendem exit;. Auch die Tiefe bleibt begrenzt. Attack Chains, also konkrete Ketten aus mehreren Schwachstellen bis zur vollständigen Kompromittierung, zeichnet GLM-5 (2026-02-11) nicht sauber nach. Genau das trennt „guter Audit-Assistent“ von „echter Sicherheitsdenker“.

Für Security-Arbeit heißt das: Das Modell ist ein brauchbarer Erstscanner, kein Abschlussgutachter. Es findet genug, um nützlich zu sein. Es übersieht genug, um gefährlich zu werden, wenn man ihm zu sehr vertraut.

CLI und agentisches Arbeiten: stark im Prinzip, mit Makel in der Praxis

Der CLI-Score von 86,67% ist hoch und passt zur agentischen Ausrichtung. GLM-5 (2026-02-11) versteht strukturierte, operative Aufgaben und bewegt sich in toolnahen Szenarien deutlich sicherer als viele reine Schreibmodelle. Das ist kein Zufall. Agentische Modelle sind dafür gebaut, Schritte zu planen, Zustände zu verwalten und Aufgaben in handhabbare Unterteile zu zerlegen.

Auch der ToolUse-Score von 74,46% ist ordentlich. Doch ausgerechnet hier sitzt ein qualitativ schwerer Fehler. In einer Tool-Aufgabe halluziniert das Modell Inhalte, die nicht aus dem abgerufenen Tool-Ergebnis stammen. Der Score wurde deshalb per Halluzinations-Cap begrenzt. Für content-kritische Aufgaben wie Recherche, Befundberichte oder faktische Zusammenfassungen ist das nicht bloß ein Schönheitsfehler. Es ist ein disqualifizierendes Signal. Ein Agent, der Tool-Output frei ergänzt, verhält sich wie ein Praktikant, der auf Nachfrage Zahlen erfindet, weil die Tabelle gerade nicht reicht.

Das relativiert die grundsätzlich gute Tool-Nähe spürbar. GLM-5 (2026-02-11) versteht das agentische Handwerk. Aber sobald das Modell die Grenze zwischen „interpretieren“ und „dazudichten“ verwischt, ist Aufsicht Pflicht.

UX Writing: überraschend stark, dann technisch auf die Nase gefallen

Im UX-Writing kommt GLM-5 (2026-02-11) auf 73,17%. Das ist respektabel, gerade für ein Modell, dessen Kernidentität nicht in feinpolierter Produktkommunikation liegt. Die Sprache bleibt meist klar, die Antworten sind knapp genug, und bei Tonalität sowie Umformulierung arbeitet das Modell professionell. Es kann toxische Formulierungen entschärfen, Bias reduzieren und Texte funktional in einen produktionsfähigen Zustand bringen.

Aber dann kommt der Bruch, der in einem echten Produktteam sofort auffallen würde. In einer UX-Writing-Aufgabe haben interne Reasoning-Tokens das komplette Ausgabe-Budget verdrängt. 7470 interne Denktokens, 0 verbleibende Output-Tokens. Das Ergebnis ist keine schlechte Antwort, sondern praktisch keine verwertbare Antwort. Der automatische Abzug ist deshalb vollkommen berechtigt. Die inhaltliche Qualität ist an dieser Stelle egal, weil der Nutzer nichts Brauchbares bekommt.

Im UX-Writing-Bereich bricht eine Ausgabe mitten in der geforderten Struktur ab. Die Antwort ist technisch abgebrochen, kein inhaltlicher Fehler. Der Abzug im Score resultiert aus der unvollständigen Antwort, nicht aus inhaltlichen Mängeln.

Das ist ein klassisches Risiko bei Thinking-Modellen: Sie verbrennen ihr Budget im Maschinenraum und kommen mit leerem Tank beim Leser an. Für experimentelle Knobelaufgaben ist das ärgerlich. Für Produkttexte mit klarer Formvorgabe ist es schlicht unprofessionell.

Content Transformation: kreativ brauchbar, sprachlich nicht ganz vertrauenswürdig

Mit 76,52% gehört Content Transformation zu den stärkeren Modulen des Modells. Das passt zum Long-Context-Tag. GLM-5 (2026-02-11) kann Material umformen, strukturieren und in neue Formate übertragen, ohne sich in Token-Masse zu verlieren. Besonders bei einer komplexen Video-Skript-Aufgabe liefert es ein produktionsreifes Resultat mit Timestamps, visuellen Hinweisen, Easter Egg und guter gesprochenen Tonlage. Nicht alles sitzt perfekt. Es fehlt etwa ein sauber gesetzter Pattern Interrupt, also jener bewusste Rhythmusbruch, der in Videos die Aufmerksamkeit zurückholt. Doch insgesamt zeigt das Modell hier Handwerk.

In einer anderen Aufgabe des Moduls leistet es sich allerdings einen klaren Hard-Constraint-Verstoß: Trotz expliziter Vorgabe antwortet es auf Englisch statt auf Deutsch. Das System markiert das als Language Mismatch. Solche Verstöße sind keine Geschmacksfrage, sondern ein echter Instruction-Following-Fehler. Gerade in Redaktions-, Marketing- oder Lokalisierungsworkflows ist die Zielsprache keine freundliche Empfehlung, sondern Vertragsbestandteil.

In einer Aufgabe im Content-Transformation-Bereich ignorierte das Modell die explizite Sprachanweisung und antwortete auf Englisch. Das ist ein Ausreißer, der im Produktiveinsatz ohne Nachkontrolle direkt fehlschlägt.

Man kann also sagen: Wenn GLM-5 (2026-02-11) die Aufgabe richtig erfasst, liefert es oft brauchbare Transformation. Aber die Sprachdisziplin ist nicht unangreifbar. Für Teams mit fester Ausgabesprache bedeutet das: immer mit Guardrails und Validierung.

Documentation Quality: ordentlich strukturiert, ohne editorische Brillanz

Die 67,42% in Documentation Quality beschreiben das Modell ziemlich treffend. Es kann dokumentieren. Es schreibt strukturiert, relativ ökonomisch und meist nachvollziehbar. Was fehlt, ist der letzte Schliff. Top-Modelle in diesem Bereich denken mit, antizipieren Verständnislücken und liefern nicht bloß Schrittfolgen, sondern belastbare Dokumentation für Menschen mit Zeitdruck.

GLM-5 (2026-02-11) macht hier eher die vernünftige Pflicht als die beeindruckende Kür. Für interne Handreichungen, technische Zusammenfassungen oder erste Entwürfe ist das genug. Für Dokumentation, die dauerhaft Bestand haben soll, wünscht man sich mehr Präzision, bessere Priorisierung und manchmal auch mehr pädagogischen Ehrgeiz.

Cultural Intelligence: professionell, aber etwas blutarm

Mit 71,04% schlägt sich GLM-5 (2026-02-11) in Cultural Intelligence ordentlich. Das Modell erkennt problematische Formulierungen, entfernt toxische Sprache und korrigiert Gender-Bias zuverlässig. In den Protokollen wird aber auch deutlich, dass es bei solchen Aufgaben oft die sichere Mitte sucht. Es macht den Text sauberer, aber nicht unbedingt lebendiger. Aus aggressiver Recruiting-Rhetorik wird funktional neutrale Professionalität. Das ist nicht falsch. Es ist nur nicht immer die beste Version derselben Botschaft.

Gerade bei inklusiven Umformulierungen zeigt sich ein Charakterzug des Modells: Es entschärft lieber, als dass es kreativ neu auflädt. Der Judge nennt das zu Recht einen Tondefizit. Wo das Referenzmaterial Energie, Mut und Begeisterung in eine inklusive Sprache übersetzt, nimmt GLM-5 (2026-02-11) oft nur den Stachel heraus. Das Ergebnis ist brauchbar. Es ist nur manchmal so inspirierend wie ein frisch gestrichener Serverraum.

Halluzinationen und Vertrauensprofil

Halluzinationen

Über alle Module hinweg ist GLM-5 (2026-02-11) nicht generell ein Fantast. Gerade deshalb wiegt der dokumentierte Tool-Halluzinationsfall schwer. Das Modell erfand Inhalte, die nicht im Tool-Output standen, und wurde dafür zu Recht gedeckelt. Dieser eine Befund reicht, um das Vertrauensprofil neu zu kalibrieren.

Denn Halluzinationen sind nicht gleich verteilt. In freier Textproduktion kann man sie oft erkennen und abfangen. In agentischen Workflows mit Tool-Aufrufen sind sie gefährlicher, weil sie den Anschein von Faktentreue tragen. Wenn ein Modell auf Basis externer Daten arbeitet, muss die Bindung an diese Daten eiserner sein als in jeder Marketingaufgabe. GLM-5 (2026-02-11) erfüllt diesen Standard nicht durchgehend.

Datenschutz und Datenhoheit

Für europäische Unternehmen ist die Datenschutzlage der eigentliche Stolperdraht. Der berechnete Sovereign Risk liegt bei HIGH. Grund ist nicht nur die Herkunft des Modells, sondern die konkrete Provider-Situation: Zhipu AI sitzt in Beijing, China, verarbeitet API-Anfragen laut Vendor Card in China und unterliegt China (PIPL/CSL/DSL). Für Nutzer aus Deutschland und der EU heißt das sehr konkret: Es gibt keinen EU-Angemessenheitsbeschluss, und die Verarbeitung personenbezogener Daten über diese Cloud ist compliance-seitig heikel.

Erschwerend kommt hinzu, dass kein GDPR DPA als verfügbar ausgewiesen ist. Für Unternehmen, die DSGVO-konform arbeiten müssen, ist das kein abstrakter Schönheitsfehler, sondern ein praktisches Hindernis. Die Datenspeicherung ist mit -1 Tagen nicht verlässlich spezifiziert. Das ist keine Information, mit der ein Datenschutzbeauftragter ruhig schlafen würde. Das Weights-Provenienz-Risiko liegt bei MEDIUM: Die Gewichte stammen von einem chinesischen Anbieter und unterliegen damit dessen Rechtsraum, auch wenn sie öffentlich verfügbar sind. Da dieses Review aber das Cloud-Angebot betrachtet, ist die Provider-Jurisdiktion der entscheidende Punkt.

Fazit

GLM-5 (2026-02-11) ist ein Modell mit Charakter, aber auch mit klaren Bedingungen. Als agentisches Frontier-MoE-Modell überzeugt es durch starke CLI-Nähe, gutes strukturelles Arbeiten, vernünftige Token-Ökonomie und brauchbare Leistungen in Content-Transformation, UX-Writing und toolnahen Aufgaben. Sein 202K-Kontextfenster und der Thinking-Fokus machen es attraktiv für längere Arbeitsketten, mehrstufige Analysen und Batch-Prozesse. Der Preis ist fair. Die Geschwindigkeit ist für diesen Typ noch akzeptabel. Das eigentliche Problem sind nicht die 17,23 Tokens pro Sekunde, sondern die fünf Timeouts und die brutale Tail-Latenz.

Inhaltlich ist das Modell meist kompetent, aber selten herausragend tief. Security-Analysen sind nützlich, doch nicht vollständig genug für Freigaben. Reasoning ist korrekt, aber nicht auf jenem Niveau, das man bei einem Thinking-Label automatisch vermuten könnte. Schwerer wiegen die Praxisfehler: eine halluzinierte Tool-Antwort, ein Sprachverstoß im Content-Workflow und ein UX-Fall, bei dem internes Denken die sichtbare Antwort vollständig verdrängt. Das sind keine Petitessen. Das sind Produktionsrisiken.

Meine Empfehlung ist daher klar: GLM-5 (2026-02-11) eignet sich für überwachte Agenten- und Batch-Workflows, technische Voranalysen, CLI-nahe Assistenz und längere Transformationsaufgaben. Für zeitkritische, compliance-sensitive oder faktisch heikle Prozesse würde ich es nur mit Retries, Output-Validierung und strikter Tool-Result-Kontrolle einsetzen. Wer ein Modell sucht, das man einfach laufen lässt und dann vergisst, ist hier falsch. Wer ein leistungsfähiges, günstiges, aber beaufsichtigungsbedürftiges Arbeitstier sucht, findet hier ein interessantes Angebot mit rauer Oberfläche.

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.