Z.ai / GLM

1. Z.ai / Zhipu AI / GLM – was gehört zusammen?

GLM bezeichnet die Modell- und Forschungsfamilie, Zhipu AI das chinesische Unternehmen hinter einem großen Teil dieser Entwicklung und Z.ai die international ausgerichtete Produkt- und API-Marke. Diese Begriffe beschreiben unterschiedliche Ebenen.

Die Seite verwendet deshalb historische Namen im jeweiligen Zeitstand und nennt aktuelle Dienste nicht rückwirkend so, als hätten sie schon 2021 oder 2023 unter Z.ai existiert.

2. Modell ≠ Chatprodukt ≠ API ≠ Coding Plan ≠ ZCode ≠ AutoClaw

Ein GLM-Checkpoint ist das eigentliche Modell. Z.ai Chat ist eine Produktoberfläche, die API ein Entwicklerservice, der GLM Coding Plan ein Coding-Abonnement, ZCode ein Coding-Harness und AutoClaw ein agentisches Arbeitsprodukt.

Diese Trennung ist für Datenschutz, Preise, Toolrechte, Reproduzierbarkeit und Fehleranalyse entscheidend.

3. Warum die GLM-Linie historisch weit vor ChatGLM beginnt

Die Wurzel liegt in der GLM-Forschung von 2021. ChatGLM ist eine spätere dialogorientierte Abzweigung, nicht der Anfang der Architekturgeschichte.

Wer nur ChatGLM-6B betrachtet, übersieht GLM-130B, die Blank-Infilling-Idee und die Forschungsentwicklung, aus der die späteren Chat- und Agentenmodelle hervorgingen.

4. Open Weight ist bei GLM keine einheitliche Lizenzkategorie

Die Familie enthält MIT-lizenzierte Modelle, ältere eigene ChatGLM-Lizenzen und seit August 2026 bei GLM-5.3 eine eigene Modelllizenz mit besonderer Klausel für sehr große Model-as-a-Service-Anbieter.

Darum wird die Lizenz pro Checkpoint dokumentiert und nicht aus dem Hersteller- oder Familiennamen abgeleitet.

5. Stand dieser Chronik: 1. September 2026

Am Stichtag gehören GLM-5.3 und GLM-5.3-Flash zu den neuesten öffentlichen Modellen. GLM-5.3 ist auf komplexes Coding und lange Agentenaufgaben ausgerichtet; GLM-5.3-Flash ergänzt erstmals native Multimodalität in der GLM-5-Familie.

Zeitkritische Aussagen dieser Seite beziehen sich ausdrücklich auf diesen Stichtag und müssen bei späterer Nutzung neu geprüft werden.

6. 10. März 2021: GLM wird als neues Pretraining-Paradigma vorgestellt

Die ursprüngliche GLM-Arbeit verbindet autoregressives Generieren mit Blank Infilling. Statt nur das nächste Token fortzuschreiben, lernt das Modell auch, ausgelassene Textspannen in einer autoregressiven Reihenfolge zu rekonstruieren.

Diese Idee zielte darauf, Natural-Language-Understanding und Generierung in einem gemeinsamen Pretraining-Rahmen zu verbinden.

7. Autoregressive Blank Infilling

GLM maskiert Textspannen und generiert die fehlenden Inhalte autoregressiv. Dadurch unterscheidet sich der Trainingsansatz sowohl von klassischem BERT-Masking als auch von rein links-nach-rechts trainierten GPT-Modellen.

Für die spätere Produktgeschichte ist wichtig: GLM ist ursprünglich ein Forschungsparadigma und kein Chatbotname.

8. 2D Position Encoding im frühen GLM

Die ursprüngliche Architektur verwendet eine Positionsdarstellung, die maskierte Position und Position innerhalb eines rekonstruierten Spans trennen kann.

Solche Details gehören zur frühen GLM-Architektur und dürfen nicht ungeprüft auf GLM-4.5 oder GLM-5 übertragen werden.

9. GLM als Brücke zwischen NLU und Generation

Das Forschungsziel war eine Modellklasse, die Klassifikation, Verständnis und freie Textgenerierung mit einem gemeinsamen Framework unterstützt.

Spätere GLM-Generationen verschieben den Schwerpunkt zunehmend auf Chat, Reasoning, Multimodalität, Coding und Agenten.

10. ACL-2022-Kontext der GLM-Arbeit

Die GLM-Arbeit wurde als wissenschaftliches Pretraining-Konzept etabliert, bevor der öffentliche Chatbot-Boom 2022/2023 einsetzte.

Diese zeitliche Einordnung verhindert, die GLM-Geschichte fälschlich als Reaktion auf ChatGPT zu erzählen.

11. GLM-110M bis GLM-10B als frühe Skalierungsstufen

GLM 2021: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

12. Chinesische und englische GLM-Varianten

GLM 2021: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

13. Multilinguales GLM mit 104 Sprachen

GLM 2021: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

14. Pretraining-Aufgaben statt Produktoberfläche

GLM 2021: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

15. Blank-Infilling gegenüber Causal LM

GLM 2021: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

16. Maskierte Spans und Generationsreihenfolge

GLM 2021: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

17. Fine-Tuning im frühen GLM-Framework

GLM 2021: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

18. SwissArmyTransformer als Forschungswerkzeug

GLM 2021: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

19. Frühe GLM-Reproduzierbarkeit

GLM 2021: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

20. Warum frühe GLM-Checkpoints heute Archivmaterial sind

GLM 2021: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

21. Tokenizer und Vocabulary im historischen Kontext

GLM 2021: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

22. Architekturdetails nicht auf heutige GLM-Modelle übertragen

GLM 2021: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

23. Frühe Benchmarks richtig lesen

GLM 2021: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

24. Modellgröße ist nicht Produktreife

GLM 2021: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

25. Forschungsrepo und kommerzieller Dienst trennen

GLM 2021: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

26. 20. August 2022: GLM-130B

GLM-130B brachte die GLM-Idee in die 100-Milliarden-Parameter-Klasse und wurde als bilinguales chinesisch-englisches Pretrained Model veröffentlicht.

Die Veröffentlichung ist ein zentraler Übergang von der frühen GLM-Forschung zu einer Modellfamilie, die später ChatGLM hervorbrachte.

27. 130 Milliarden Parameter

GLM-130B skaliert den Ansatz auf rund 130 Milliarden Parameter. Solche Modelle verlangen völlig andere Speicher-, Parallelisierungs- und Serving-Strategien als spätere 6B-Chatvarianten.

Parameterzahl beschreibt dabei Gewichtskapazität, nicht automatisch aktive Rechenkosten, Kontextfenster oder Produktqualität.

28. Bilinguale Ausrichtung

GLM-130B wurde gezielt für Chinesisch und Englisch entwickelt. Diese bilinguale Linie prägt später ChatGLM und die internationale Ausrichtung der offenen GLM-Modelle.

Mehrsprachigkeit wächst in späteren Generationen deutlich über diese Ausgangsbasis hinaus.

29. 24. August 2022: quantisierte GLM-130B-Variante

Die Projektchronik dokumentiert eine INT4-Gewichtsquantisierung, die die Hardwareanforderungen stark reduzierte und GLM-130B auf einem einzelnen Server mit vier RTX 3090 praktikabler machte.

Quantisierung senkt den Speicherbedarf, verändert aber nicht die zugrunde liegende Parameterzahl und kann Genauigkeit, Latenz und Runtime-Kompatibilität beeinflussen.

30. ICLR 2023 und wissenschaftliche Einordnung

GLM-130B wurde als Forschungsarbeit akzeptiert und blieb zugleich als offenes Modell ein wichtiger Bezugspunkt für nachfolgende ChatGLM-Entwicklung.

Für Archivierung sollten Paper-Version, Gewichtsrevision, Runtime und Quantisierung getrennt festgehalten werden.

31. GLM-130B Base versus spätere Chatmodelle

GLM-130B: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

32. Tensor Parallelism bei 130B

GLM-130B: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

33. Pipeline Parallelism und große Checkpoints

GLM-130B: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

34. INT4 reduziert Speicher, nicht Modellkomplexität

GLM-130B: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

35. FP16-Aktivierungen in frühen Quantisierungsrezepten

GLM-130B: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

36. Vier RTX 3090 als historische Referenz

GLM-130B: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

37. Serving großer GLM-Modelle 2022

GLM-130B: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

38. Training und Inferenz nicht verwechseln

GLM-130B: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

39. Bilinguales Pretraining

GLM-130B: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

40. GLM-130B als Basis für ChatGLM

GLM-130B: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

41. Checkpoint-Sharding

GLM-130B: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

42. Reproduzierbare Hardwareangaben

GLM-130B: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

43. Warum heutige 1M-Kontextmodelle nicht mit GLM-130B vergleichbar sind

GLM-130B: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

44. Frühe GLM-Lizenzen separat prüfen

GLM-130B: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

45. Historische Benchmarks unter damaligen Harnesses

GLM-130B: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

46. GLM-130B heute lokal betreiben

GLM-130B: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

47. Archivwert großer früher Open Weights

GLM-130B: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

48. Von 130B dense zu späteren MoE-Systemen

GLM-130B: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

49. GLM-130B und die chinesische LLM-Landschaft

GLM-130B: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

50. Forschungslinie statt Consumerprodukt

GLM-130B: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

51. 14./15. März 2023: ChatGLM und ChatGLM-6B

Im März 2023 erschien ChatGLM als bilinguales Dialogmodell auf Basis der GLM-Linie; parallel wurde ChatGLM-6B als deutlich kleinerer offener Checkpoint veröffentlicht.

Die Unternehmenschronik nennt den 15. März, das öffentliche Repository dokumentiert die Ankündigung am 14. März. Für die Archivierung ist diese eintägige Quellenabweichung transparent zu behandeln.

52. ChatGLM-6B als lokale Einstiegsklasse

ChatGLM-6B zielte auf chinesisch-englischen Dialog und konnte quantisiert mit sehr wenig GPU-Speicher betrieben werden.

Damit wurde die GLM-Familie für lokale Experimente wesentlich zugänglicher als GLM-130B.

53. 6 GB GPU-Speicher als historischer Marketingpunkt

Das Projekt hob hervor, dass quantisierte Inferenz bereits auf GPUs mit etwa 6 GB VRAM möglich war.

Dieser Wert ist an damalige Quantisierung, Kontextlänge und Implementierung gebunden und darf nicht als allgemeine Mindestanforderung für spätere GLM-Modelle verstanden werden.

54. ChatGLM ist nicht gleich ChatGLM-6B

ChatGLM bezeichnete zugleich eine größere kommerzielle Produkt-/Modelllinie, während ChatGLM-6B der offen veröffentlichte kleinere Checkpoint war.

Diese Namensnähe ist eine der häufigsten historischen Quellen für falsche Parameterangaben.

55. 10. August 2023: ZhipuAI ChatGLM offiziell gestartet

Die Unternehmenschronik führt den offiziellen Start des registrierten ChatGLM-Produkts im August 2023.

Consumerprodukt, API-Modell und Open-Weight-Checkpoint müssen deshalb auch 2023 getrennt betrachtet werden.

56. ChatGLM-6B Base und Chat

ChatGLM 2023: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

57. ChatGLM-6B Quantisierung

ChatGLM 2023: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

58. INT4 und lokaler Betrieb

ChatGLM 2023: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

59. CPU-Inferenz als Notlösung

ChatGLM 2023: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

60. Apple-Silicon-Unterstützung der frühen Community

ChatGLM 2023: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

61. Trust Remote Code als damalige Runtime-Frage

ChatGLM 2023: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

62. Chattemplate der ersten Generation

ChatGLM 2023: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

63. Chinesisch-englischer Dialog

ChatGLM 2023: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

64. Kontextgrenzen der ersten ChatGLM-Generation

ChatGLM 2023: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

65. Halluzinationen trotz flüssigem Chinesisch

ChatGLM 2023: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

66. Alignment und Dialogtraining

ChatGLM 2023: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

67. Warum ChatGLM-6B heute ein Archivcheckpoint ist

ChatGLM 2023: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

68. Lizenz der ersten ChatGLM-Gewichte

ChatGLM 2023: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

69. Kommerzielle Nutzung nicht aus Repo-Lizenz ableiten

ChatGLM 2023: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

70. WebGLM als Retrieval-Forschung

ChatGLM 2023: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

71. 14. Juni 2023: WebGLM

ChatGLM 2023: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

72. Websuche ist kein Modellwissen

ChatGLM 2023: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

73. Retrievalqualität und Antwortqualität trennen

ChatGLM 2023: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

74. CodeGeeX-Verbindung im damaligen Ökosystem

ChatGLM 2023: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

75. ChatGLM als chinesische Open-LLM-Welle

ChatGLM 2023: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

76. 20 Millionen Downloads als Reichweitenindikator

ChatGLM 2023: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

77. Downloadzahl ist kein Qualitätsbenchmark

ChatGLM 2023: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

78. Historische Model Cards sichern

ChatGLM 2023: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

79. Frühe Transformers-Abhängigkeiten

ChatGLM 2023: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

80. Revision-Pinning bei trust_remote_code

ChatGLM 2023: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

81. Promptformate und Rollen

ChatGLM 2023: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

82. Mehrturn-Dialog

ChatGLM 2023: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

83. Streaming bei frühen Demos

ChatGLM 2023: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

84. Lokale GUI-Projekte rund um ChatGLM

ChatGLM 2023: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

85. ChatGLM in Unternehmen 2023

ChatGLM 2023: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

86. Datenschutz bei lokalem Checkpoint

ChatGLM 2023: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

87. Cloud-Chat versus lokales Modell

ChatGLM 2023: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

88. API-Endpunkt versus Repository

ChatGLM 2023: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

89. Versionierung vor semantischen Modellnamen

ChatGLM 2023: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

90. Warum 6B damals strategisch wichtig war

ChatGLM 2023: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

91. Der Übergang zu ChatGLM2

ChatGLM 2023: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

92. 25. Juni 2023: ChatGLM2-6B

ChatGLM2-6B brachte ein erneuertes Basismodell, 1,4 Billionen bilinguale Pretraining-Tokens, längeren Kontext und effizientere Inferenz.

Das Projekt dokumentierte deutliche Benchmarkgewinne gegenüber ChatGLM-6B; für Vergleiche sind jedoch dieselben Evaluationsbedingungen erforderlich.

93. ChatGLM2: 32K Basiskontext und 8K Dialogtraining

Die zweite Generation erweiterte das Kontextfenster des Basismodells von 2K auf 32K und wurde im Dialog-Alignment mit 8K trainiert.

Das Projekt warnte selbst davor, dass extrem lange Einzeldokumente damals noch nicht automatisch zuverlässig verstanden wurden.

94. ChatGLM2: Multi-Query Attention

MQA reduzierte KV-Cache- und Speicherbedarf und verbesserte die Inferenzgeschwindigkeit.

Solche Architekturoptimierungen sind ein Vorläufer der späteren starken Konzentration auf effizientes Serving und lange Agententrajektorien.

95. ChatGLM2: 42 Prozent schnellere Referenzinferenz

Das Projekt berichtete unter seiner offiziellen Implementierung eine um 42 Prozent höhere Inferenzgeschwindigkeit gegenüber der ersten Generation.

Diese Zahl ist eine historische Messung und kein heutiger universeller Performancewert.

96. Oktober 2023: ChatGLM3

ChatGLM3 führte die 6B-Linie fort und verlagerte den Schwerpunkt stärker auf Tool Use, Code Interpreter, Retrieval und Agentenprotokolle.

Damit nähert sich die Familie erstmals sichtbar dem späteren Muster Modell + Tools + Agent-Harness.

97. ChatGLM3-6B

ChatGLM2/3: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

98. ChatGLM3-6B-32K

ChatGLM2/3: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

99. ChatGLM3-6B-128K

ChatGLM2/3: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

100. Tool-Aufrufe in ChatGLM3

ChatGLM2/3: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

101. Code Interpreter als externe Ausführungsschicht

ChatGLM2/3: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

102. Retrieval in ChatGLM3-Demos

ChatGLM2/3: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

103. AgentTuning-Idee

ChatGLM2/3: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

104. Funktionsaufrufe benötigen Schema-Validierung

ChatGLM2/3: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

105. Lokale 4-Bit-Quantisierung

ChatGLM2/3: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

106. Rund 13 GB VRAM in FP16 als damalige Referenz

ChatGLM2/3: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

107. CPU-Betrieb mit hohem RAM-Bedarf

ChatGLM2/3: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

108. MPS auf Apple Silicon

ChatGLM2/3: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

109. ChatGLM3-Base

ChatGLM2/3: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

110. ChatGLM3-Chat

ChatGLM2/3: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

111. Langkontext nicht mit Memory verwechseln

ChatGLM2/3: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

112. 128K-Modellvarianten sauber benennen

ChatGLM2/3: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

113. ChatGLM3 als letzte große ChatGLM-Namensphase

ChatGLM2/3: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

114. Tool-Rechte sind nicht Modellrechte

ChatGLM2/3: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

115. RAG-Fehler trotz richtigem Modell

ChatGLM2/3: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

116. ChatGLM3 und die Vorbereitung von GLM-4

ChatGLM2/3: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

117. Historische API-Aliase

ChatGLM2/3: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

118. Prompttemplate-Versionen

ChatGLM2/3: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

119. Tokenizer-Revisionen

ChatGLM2/3: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

120. Quantisierte Community-Formate

ChatGLM2/3: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

121. Archivierung von Remote-Code-Repositories

ChatGLM2/3: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

122. 25. Januar 2024: GLM-4

GLM-4 markiert den Übergang zu einer breiteren Foundation-Model-Familie mit stärkerem Reasoning, Tool Use und Multimodalität.

Die spätere technische Veröffentlichung beschreibt GLM-4, GLM-4-Air und GLM-4-9B als zusammengehörige Generation.

123. 5./18. Juni 2024: GLM-4-9B Open Weights

Das Open-Source-Repository dokumentiert die Veröffentlichung der GLM-4-9B-Serie am 5. Juni; die Unternehmenschronik nennt den 18. Juni als offiziellen Meilenstein für GLM-4-9B und GLM-4V-9B.

Die Chronik hält beide Datumsquellen auseinander, statt daraus ein scheinbar exaktes Einzeldatum zu erfinden.

124. GLM-4-9B Base

Der Base-Checkpoint dient als Ausgangspunkt für Fine-Tuning und eigene Anpassung.

Er ist nicht mit dem Chatmodell identisch und verwendet andere Nutzungsannahmen.

125. GLM-4-9B-Chat mit 128K

Die Chatvariante wurde mit einem deutlich längeren Kontext als das Base-Modell angeboten.

Kontextfenster, Training und tatsächliche Long-Context-Qualität bleiben unterschiedliche Eigenschaften.

126. GLM-4-9B-Chat-1M

Bereits 2024 existierte eine spezielle 1M-Kontextvariante des offenen GLM-4-9B-Chats.

Das zeigt, dass die spätere 1M-Linie von GLM-5.2 nicht die erste nominelle Million-Token-Variante der GLM-Geschichte war; 2026 geht es stärker um robuste Langhorizontarbeit.

127. GLM-4V-9B

GLM-4V-9B brachte Vision-Language-Fähigkeiten in die offene 9B-Klasse.

Bildverständnis, OCR, UI-Grounding und spätere multimodale Codingmodelle entwickeln sich danach als eigene Teilpfade weiter.

128. 12. August 2024: GLM-4-Plus

GLM-4-Plus wurde als stärkere kommerzielle Foundation-Modellgeneration vorgestellt.

Zeitgleich wurde ChatGLM um eine Video-Call-Funktion erweitert; Modell und Kommunikationsoberfläche sind dennoch getrennte Schichten.

129. 15. August 2024: LongWriter-GLM4-9B

LongWriter zeigte, wie sich lange Ausgaben durch gezielte Trainingsdaten verbessern lassen und demonstrierte über 10.000 Tokens lange Einzelantworten.

Großes Kontextfenster und große Ausgabelänge sind unterschiedliche technische Achsen.

130. 5. September 2024: LongCite-GLM4-9B

LongCite fokussierte feingranulare Quellenzuordnung in Long-Context-Q&A.

Eine Zitation ist dennoch nur dann belastbar, wenn die zitierte Stelle den jeweiligen Satz tatsächlich stützt.

131. 25./28. Oktober 2024: GLM-4-Voice

GLM-4-Voice brachte end-to-end Sprachdialog mit chinesisch-englischer Ausrichtung und emotionaler Sprachmodellierung.

Voice ist nicht nur Speech-to-Text plus Text-to-Speech; end-to-end Modelle können Audioeigenschaften direkt im Modellpfad verarbeiten.

132. Oktober 2024: AutoGLM

AutoGLM verschiebt die Familie von Antwortgenerierung zu Device Agency: Bildschirm verstehen, Aktionen auswählen und reale App-Workflows ausführen.

Damit entstehen zusätzliche Sicherheitsfragen rund um Klicks, Zahlungen, Berechtigungen und irreversible Aktionen.

133. 15. November 2024: GLM-PC

GLM-PC übertrug das Agentenkonzept auf Desktop- beziehungsweise PC-Interaktion.

Computer Use ist ein Produkt-/Agentenproblem, kein bloßer Textbenchmark.

134. 20. Dezember 2024: GLM-Zero-Preview

GLM-Zero-Preview repräsentiert eine frühe explizite Reasoning-Linie innerhalb des GLM-Ökosystems.

Spätere GLM-4.5- und GLM-5-Generationen integrieren Reasoning stärker in hybride beziehungsweise obligatorische Thinking-Modi.

135. GLM-4-Air

GLM-4 und 2024: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

136. GLM-4 kommerziell und GLM-4-9B offen

GLM-4 und 2024: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

137. GLM-4 All Tools

GLM-4 und 2024: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

138. Tool Use als Produktstack

GLM-4 und 2024: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

139. Websuche mit GLM-4

GLM-4 und 2024: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

140. Dateiverarbeitung

GLM-4 und 2024: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

141. Code Interpreter

GLM-4 und 2024: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

142. Vision und Text in einer Session

GLM-4 und 2024: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

143. GLM-4-9B mit Ollama

GLM-4 und 2024: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

144. GLM-4-9B mit llama.cpp

GLM-4 und 2024: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

145. OpenVINO- und Intel-Pfade

GLM-4 und 2024: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

146. FlashAttention 2

GLM-4 und 2024: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

147. YaRN und Langkontext

GLM-4 und 2024: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

148. Fine-Tuning von GLM-4V

GLM-4 und 2024: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

149. LongReward

GLM-4 und 2024: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

150. LongWriter-Datensatz

GLM-4 und 2024: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

151. LongCite-45k

GLM-4 und 2024: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

152. Feingranulare Quellenmarkierung

GLM-4 und 2024: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

153. GLM-4-Voice Audio-Tokenizer

GLM-4 und 2024: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

154. Audio-Latenz und Streaming

GLM-4 und 2024: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

155. AutoGLM Screenshot-Loop

GLM-4 und 2024: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

156. Tap/Swipe/Type als Agentenaktionen

GLM-4 und 2024: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

157. App-Popups und UI-Drift

GLM-4 und 2024: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

158. Device Agency und Sandbox

GLM-4 und 2024: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

159. GLM-PC Bildschirmverständnis

GLM-4 und 2024: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

160. Desktop-Aktionen reversibel halten

GLM-4 und 2024: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

161. GLM-Zero und Reasoning-Preview

GLM-4 und 2024: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

162. Reasoningtrace nicht mit Wahrheit verwechseln

GLM-4 und 2024: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

163. 2024 als Übergang von Chat zu Agent

GLM-4 und 2024: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

164. Multimodalität wird eigene Modellfamilie

GLM-4 und 2024: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

165. Historische Consumer-Marke ChatGLM

GLM-4 und 2024: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

166. GLM-4 API-Modellnamen

GLM-4 und 2024: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

167. GLM-4-Plus als Cloudmodell

GLM-4 und 2024: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

168. Open-Weight- und Cloud-Lifecycle trennen

GLM-4 und 2024: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

169. Kontextgrößen in der GLM-4-Familie

GLM-4 und 2024: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

170. Ausgabelimit und Kontextlimit

GLM-4 und 2024: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

171. 2024er Modellkarten archivieren

GLM-4 und 2024: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

172. Serving-Framework-Versionen festhalten

GLM-4 und 2024: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

173. GLM-4-9B als langfristig nutzbares Archivmodell

GLM-4 und 2024: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

174. Übergang zu GLM-4.1V und GLM-4.5

GLM-4 und 2024: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

175. 8. Januar 2025: GLM-Realtime

GLM-Realtime wurde als end-to-end Echtzeitmodell für Sprache und Function Calling vorgestellt.

Realtime-Anwendungen müssen Latenz, Unterbrechbarkeit, Audiozustand und Toolrechte zusätzlich zur Modellqualität messen.

176. 22. März 2025: AutoGLM Reflection

AutoGLM Reflection kombinierte Deep Research mit operationalen Agentenfähigkeiten.

Recherche und Handlung in einem Agenten erhöhen den Nutzen, aber auch die Angriffsfläche durch falsche Quellen und überprivilegierte Aktionen.

177. 14. April 2025: GLM-4-32B-0414

Die offene GLM-4-Linie wurde auf 32B erweitert und für Dialog, Reasoning und weitere Szenarien differenziert.

Ein späterer Checkpoint innerhalb derselben Generation kann durch Training und Kontextregime wichtiger sein als die bloße Parametersteigerung.

178. 1./2. Juli 2025: GLM-4.1V-9B-Thinking

GLM-4.1V-9B-Thinking brachte explizites multimodales Reasoning in eine offene 9B-Visionklasse.

Die Linie bildet eine wichtige Brücke zu GLM-4.5V, GLM-4.6V und GLM-5V-Turbo.

179. 28. Juli 2025: GLM-4.5

GLM-4.5 wurde als Agentic, Reasoning and Coding Foundation Model vorgestellt.

Mit 355B Gesamt- und 32B aktiven Parametern pro Forward Pass ist es ein sparse MoE und nicht als 355B-dense Modell zu verstehen.

180. GLM-4.5-Air

GLM-4.5-Air reduziert die MoE-Skala auf 106B Gesamt- und 12B aktive Parameter.

Air ist ein eigener Modellcheckpoint mit anderem Servingprofil, nicht einfach ein niedrigerer API-Tarif desselben Gewichts.

181. 15 Billionen Tokens im GLM-4.5-Training

Die Entwicklerdokumentation nennt 15T allgemeine Pretraining-Tokens und anschließendes Training für Code, Reasoning und Agentenaufgaben.

Trainingsvolumen allein beweist keine Qualität; Datenmischung, Architektur und Post-Training sind ebenso entscheidend.

182. 128K Kontext bei GLM-4.5

GLM-4.5 startet die neue Agentengeneration mit 128K Kontext.

Schon zwei Monate später wird GLM-4.6 auf 200K erweitert, was die schnelle Veränderung dieser Produktklasse zeigt.

183. Hybrid Reasoning bei GLM-4.5

Die Modelle unterstützen Thinking- und Non-Thinking-Modi.

Das erlaubt eine Latenz-/Qualitätsentscheidung pro Aufgabe und ist historisch wichtig, weil GLM-5.3 später Thinking nicht mehr vollständig abschaltbar macht.

184. 11. August 2025: GLM-4.5V

GLM-4.5V erweiterte die agentische Linie um stärkere multimodale Wahrnehmung und wurde mit einem offenen Desktop-Assistant-Debuggingpfad verbunden.

Visuelle Agenten müssen Screenshots, UI-Zustand und Aktionsfolgen zusammen protokollieren.

185. 30. September 2025: GLM-4.6

GLM-4.6 erhöhte den Kontext auf 200K und verbesserte Coding, Reasoning, Tool Use, Search Agents und Schreibqualität.

Der Modellwechsel ist deshalb mehr als ein Benchmarkupdate: Er verändert die Eignung für längere agentische Sessions.

186. 200K Kontext bei GLM-4.6

Die 200K-Klasse bleibt später auch bei GLM-4.7 und zunächst GLM-5/5.1 wichtig.

Erst GLM-5.2 verschiebt die robuste Langhorizontlinie auf 1M Kontext.

187. 22. Dezember 2025: GLM-4.7

GLM-4.7 fokussiert Coding, mehrstufiges Reasoning und Tool Use und verbessert ausdrücklich Frontend-Ästhetik sowie Terminalaufgaben.

Die Entwicklerdokumentation führt GLM-4.7, FlashX und Flash als eigene Varianten.

188. Preserved Thinking in GLM-4.7

Reasoningblöcke können über mehrere Turns erhalten bleiben, um Kontinuität und Cache-Hits in Coding-Agenten zu verbessern.

Das funktioniert nur korrekt, wenn das Harness die ursprünglichen Reasoningblöcke vollständig und unverändert zurückgibt.

189. Turn-level Thinking in GLM-4.7

Thinking kann turnweise ein- oder ausgeschaltet werden.

Diese Kontrolle unterscheidet sich vom späteren GLM-5.3, bei dem Thinking obligatorisch ist und nur die Tiefe gesteuert wird.

190. GLM-4.7-Flash

Die 30B-A3B-Klasse bietet einen wesentlich leichteren Open-Weight-Pfad für schnelle lokale oder kostengünstige Inferenz.

Der Name Flash bezeichnet hier tatsächlich eine kleine aktive MoE-Klasse; GLM-5.3-Flash 2026 ist dagegen mit 320B/18B deutlich größer.

191. 8. Dezember 2025: AutoGLM wird Open Source

AutoGLM veröffentlichte Kernmodelle, Phone-Use-Framework und Toolchain und positionierte private Deploymentfähigkeit als Weg zu kontrollierbarer Device Agency.

Das Projekt nennt Modelle unter MIT und Code unter Apache 2.0; Lizenzdetails werden dennoch je Repository geprüft.

192. 10. Dezember 2025: GLM-ASR-2512

Mit GLM-ASR entstand eine spezialisierte Spracherkennungslinie neben den allgemeinen LLMs.

ASR-Fehler, Sprechertrennung und Zeitstempel sind eigene Problemklassen und sollten nicht als Chatmodellfehler bewertet werden.

193. 11. Dezember 2025: AutoGLM-Phone-Multilingual

Die mobile Agentenlinie wurde für chinesische und englische Apps verbreitert und mit ADB-basierter Aktionsausführung dokumentiert.

ADB-Zugriff kann tiefgreifende Aktionen ausführen; Rechte, Testgerät und Zahlungsgrenzen gehören deshalb zum Sicherheitsdesign.

194. GLM-4.5 MoE-Routing

GLM 2025: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

195. 355B gesamt versus 32B aktiv

GLM 2025: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

196. 106B/12B bei Air

GLM 2025: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

197. MIT-Lizenz der GLM-4.5-Open-Weights

GLM 2025: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

198. FP8-Versionen

GLM 2025: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

199. H100-Anforderungen für Referenzdeployment

GLM 2025: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

200. SGLang als Servingpfad

GLM 2025: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

201. vLLM-Unterstützung

GLM 2025: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

202. LoRA-Fine-Tuning

GLM 2025: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

203. Reasoning und Tool Use gemeinsam testen

GLM 2025: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

204. Web Browsing als Agententool

GLM 2025: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

205. Frontend-Generierung

GLM 2025: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

206. Software Engineering

GLM 2025: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

207. GLM-4.5V Screen Understanding

GLM 2025: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

208. GLM-4.6 Tool Use während Inferenz

GLM 2025: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

209. Search-based Agents

GLM 2025: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

210. 200K Kontext praktisch nutzen

GLM 2025: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

211. GLM-4.7 Retained Reasoning

GLM 2025: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

212. GLM-4.7 Toolbench-Verbesserungen

GLM 2025: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

213. GLM-4.7 Frontendästhetik

GLM 2025: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

214. GLM-4.7 Präsentationslayout

GLM 2025: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

215. FlashX als Plattformvariante

GLM 2025: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

216. Flash als lokaler Effizienzpfad

GLM 2025: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

217. GLM-4.7 Maximum Output 128K

GLM 2025: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

218. Prompt- und Reasoningblöcke cachen

GLM 2025: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

219. AutoGLM Phone Use

GLM 2025: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

220. MobileRL

GLM 2025: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

221. ComputerRL

GLM 2025: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

222. AgentRL

GLM 2025: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

223. Virtuelle Cloud-Telefone

GLM 2025: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

224. Auditierbare Agentenaktionen

GLM 2025: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

225. Zahlungen als Hochrisikoaktion

GLM 2025: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

226. GLM-ASR-Fehlerprofile

GLM 2025: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

227. AutoGLM und Datenschutz

GLM 2025: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

228. 2025 als Agentenjahr der GLM-Linie

GLM 2025: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

229. GLM-5: von Vibe Coding zu Agentic Engineering

GLM-5 skaliert die Foundation auf 744B Gesamt- und 40B aktive Parameter und richtet Training sowie Post-Training auf komplexe Systementwicklung und lang laufende Agentenaufgaben aus.

Der Schwerpunkt verschiebt sich von einzelnen Codeantworten zu Projektarbeit mit Planung, Experimenten, Toolaufrufen und Iteration.

230. 744B Gesamt- und 40B aktive Parameter

GLM-5 ist ein sehr großes MoE: Fast alle Gewichte müssen gespeichert beziehungsweise verteilt werden, obwohl pro Token nur ein Teil aktiv gerechnet wird.

Aktive Parameter sind deshalb kein RAM-Wert und keine Aussage darüber, dass das Modell wie ein 40B-Checkpoint gespeichert werden kann.

231. 28,5 Billionen Pretraining-Tokens

Die GLM-5-Dokumentation nennt 28,5T Tokens gegenüber 23T in der GLM-4.5-Vergleichslinie.

Mehr Daten sind nur eine Dimension; Architektur, DSA, RL-Umgebung und Post-Training tragen ebenfalls zum Sprung bei.

232. DeepSeek Sparse Attention in GLM-5

GLM-5 integriert DSA, um langen Kontext mit reduzierten Servingkosten zu verarbeiten.

Die Übernahme einer Architekturidee bedeutet nicht, dass GLM-5 ein DeepSeek-Modell ist; Training, Gewichte und Produkt bleiben Z.ai-eigenständig.

233. slime als asynchrones RL-Framework

Z.ai entwickelte slime für großskaliges asynchrones Reinforcement Learning und nutzt es über die GLM-5-Familie hinweg.

Post-Training-Infrastruktur wird damit zu einem eigenen technischen Bestandteil der Modellgeschichte.

234. 7. April 2026: GLM-5.1

GLM-5.1 fokussiert stabile Long-Horizon-Agentenarbeit und wird in den Release Notes mit bis zu acht Stunden autonomer Arbeit in einer einzelnen Ausführung beschrieben.

Solche Angaben sind Produkt-/Evaluationsaussagen und kein Versprechen, jede Aufgabe acht Stunden ohne menschliche Kontrolle sicher ausführen zu können.

235. GLM-5.1: 200K Kontext und 128K Output

Die Migrationsdokumentation nennt 200K Kontext sowie bis zu 128K Ausgabe.

Große Ausgaben erhöhen Kosten, Prüfaufwand und Risiko von Drift; sie sollten nicht allein deshalb maximal gewählt werden.

236. Streaming Tool Calls in GLM-5.1

Mit tool_stream können Toolargumente während der Generierung gestreamt werden.

Ein Client muss Teilstücke korrekt zusammensetzen und darf unvollständige JSON-Argumente nicht vorschnell ausführen.

237. 16. Juni 2026: GLM-5.2

GLM-5.2 erweitert den robusten Agentenkontext auf 1M Tokens und führt eine neue Long-Horizon-Architektur- und Trainingslinie ein.

Die Million Tokens sind hier nicht nur ein nominelles Kontextlimit, sondern werden ausdrücklich als belastbare Projektkontextklasse positioniert.

238. GLM-5.2: 1M Kontext

Ein 1M-Kontext kann große Repositories, Dokumentbestände und lange Agententrajektorien aufnehmen.

Trotzdem bleiben Retrieval, Strukturierung und Kontextdisziplin nötig, weil Aufmerksamkeit, Kosten und irrelevanter Kontext weiterhin praktische Grenzen setzen.

239. IndexShare

IndexShare teilt einen Indexer über jeweils vier Sparse-Attention-Layer und reduziert laut Z.ai die per-token FLOPs bei 1M Kontext um den Faktor 2,9.

Diese Optimierung betrifft die Langkontextarchitektur und ist nicht mit Cache-Hits oder Quantisierung gleichzusetzen.

240. Verbessertes MTP für speculative decoding

GLM-5.2 verbessert die Multi-Token-Prediction-Schicht und erhöht die Akzeptanzlänge für speculative decoding.

Speculative Decoding beschleunigt Inferenz, ohne die logische Modellgröße zu reduzieren.

241. GLM-5.2 unter MIT

Die offenen Gewichte von GLM-5.2 werden unter MIT veröffentlicht.

Damit unterscheidet sich GLM-5.2 lizenzrechtlich ausdrücklich vom späteren GLM-5.3-Hauptmodell.

242. 14. August 2026: GLM-5.3

GLM-5.3 verwendet denselben Basismodell-Checkpoint wie GLM-5.2; der gesamte dokumentierte Leistungsgewinn stammt aus weiter skaliertem Post-Training.

Das ist ein besonders klares Beispiel dafür, dass eine neue Modellgeneration nicht zwingend neue Pretraining-Gewichte voraussetzt.

243. GLM-5.3 und Z.ai Code Bench

Z.ai berichtet rund 50 Prozent Verbesserung gegenüber GLM-5.2 auf dem eigenen Code Bench und deutliche Gewinne bei langen Coding- und Terminalaufgaben.

Private Benchmarks liefern nützliche Signale, müssen aber neben öffentlichen Benchmarks und realen Regressionstests betrachtet werden.

244. Emergent Cyber Capability bei GLM-5.3

Z.ai beobachtete starke Zuwächse bei Vulnerability Discovery und Exploitation-Benchmarks und führt ein Security Disclosure Ledger für reale Funde.

Diese Fähigkeit erhöht gleichzeitig den defensiven Nutzen und das Missbrauchsrisiko; Zugriffsrechte, Sandbox und verantwortliche Offenlegung werden wichtiger.

245. GLM-5.3: Thinking ist nicht mehr abschaltbar

Die API verlangt Thinking und steuert nur noch reasoning_effort mit low, high oder max.

Anwendungen, die zuvor thinking.type=disabled verwendet haben, müssen vor dem Modellwechsel migriert werden.

246. GLM-5.3: low, high und max

Die drei Effort-Stufen steuern Rechen- und Reasoningbudget. Für Coding empfiehlt Z.ai max, während low für leichtere Aufgaben Latenz und Kosten reduzieren kann.

Effort ist eine Produkteinstellung, kein anderer Modellcheckpoint.

247. 28. August 2026: GLM-5.3-Gewichte verfügbar

Nach der Ankündigung wurden die Gewichte Ende August auf Hugging Face bereitgestellt; das Repository umfasst einen sehr großen, geshardeten Checkpoint von rund 756 GB.

Damit ist GLM-5.3 tatsächlich als Open Weight verfügbar, aber nicht unter MIT oder Apache 2.0.

248. Eigene GLM-5.3-Lizenz

Die GLM-5.3-Lizenz erlaubt weitreichend Nutzung, Modifikation, Distribution, Fine-Tuning und kommerziellen Einsatz, enthält aber eine Sonderregel für Model-as-a-Service-Unternehmen mit mehr als 10 Milliarden US-Dollar Jahresumsatz.

Für solche MaaS-Anbieter ist vor kommerzieller Nutzung eine Z.ai-Sicherheitsprüfung vorgesehen; daher ist die Lizenz nicht pauschal als MIT zu bezeichnen.

249. 30. August 2026: GLM-5.3-Flash

GLM-5.3-Flash ist der neueste Stichtagsrelease und erstmals ein nativ multimodales Modell in der GLM-5-Hauptfamilie.

Es verbindet Text, Bilder, Video und Dateien mit Coding, Tool Use und Agentenarbeit.

250. GLM-5.3-Flash: 320B Gesamt / 18B aktiv

Die Flash-Variante ist wesentlich kleiner als das 744B/40B-Flagship, bleibt aber ein großes MoE und ist kein Consumer-6B-Modell.

Der Name Flash beschreibt die effizientere Positionierung, nicht eine minimale Speicherklasse.

251. Hybrid aus Sparse und Linear Attention

GLM-5.3-Flash kombiniert sparse und lineare Attention, um präzisen Langkontext günstiger zu bedienen.

Diese Architektur unterscheidet sich vom GLM-5.2/5.3-Hauptbasismodell und wurde für Flash neu trainiert.

252. Manifold-Constrained Hyper-Connections

GLM-5.3-Flash verwendet mHC als zusätzliche Skalierungs- und Effizienztechnik.

Solche Architekturdetails sollten bei Runtime-Kompatibilität dokumentiert werden, weil ältere Inferenzframeworks neue Layer möglicherweise noch nicht unterstützen.

253. 30T multimodales Pretraining

Z.ai nennt für Flash einen neuen 30T-Token multimodalen Korpus.

Die nativ multimodale Basis ist der zentrale Unterschied zu GLM-5.3, das als textorientiertes Hauptmodell aus dem GLM-5.2-Base hervorgeht.

254. GLM-5.3-Flash unter MIT

Die öffentlichen Flash-Gewichte tragen auf Hugging Face MIT-Lizenz.

Damit ist die Flash-Lizenz permissiver und einfacher einzuordnen als die eigene GLM-5.3-Lizenz.

255. Ox Alpha als anonymer Vorabtest

Vor der offiziellen Veröffentlichung wurde GLM-5.3-Flash laut Z.ai unter dem Namen Ox Alpha mit realem Traffic getestet.

Anonyme Arena- oder Traffic-Tests sind nützlich gegen Markenbias, ersetzen aber keine reproduzierbare lokale Evaluation.

256. GLM-5 Modellgröße und Speicherbedarf

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

257. GLM-5 FP8

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

258. GLM-5.1 versus GLM-5

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

259. Acht-Stunden-Agentenlauf kritisch interpretieren

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

260. GLM-5.1 Multi-Turn SFT

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

261. Process-Quality-Evaluation

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

262. Tool Use über lange Horizonte

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

263. GLM-5.2 long-horizon environments

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

264. SAO im GLM-5.2-Post-Training

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

265. 1M Kontext und Repositoryarbeit

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

266. 1M Kontext und Dokumentanalyse

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

267. IndexShare im Serving

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

268. Speculative Decoding mit MTP

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

269. GLM-5.2 reasoning_effort high/max

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

270. GLM-5.2 kein non-thinking Flagship

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

271. GLM-5.3 gleiche Base, anderes Post-Training

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

272. Mehr Post-Training ohne neues Pretraining

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

273. Terminal-Bench 3.0

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

274. DeepSWE v1.1

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

275. Agents' Last Exam

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

276. CyberGym

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

277. ExploitBench

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

278. ExploitGym

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

279. Security Disclosure Ledger

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

280. Verantwortliche Schwachstellenoffenlegung

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

281. Defensive Nutzung von GLM-5.3

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

282. Cyberfähigkeit und Agentenrechte

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

283. GLM-5.3 1M Kontext

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

284. GLM-5.3 128K Output

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

285. GLM-5.3 Tool Streaming

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

286. GLM-5.3 Open Weights

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

287. GLM-5.3 Lizenz nicht FLOSS pauschalisieren

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

288. GLM-5.3 SaaS-Ausnahme

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

289. GLM-5.3-Flash neue Base

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

290. GLM-5.3-Flash 18B aktiv

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

291. GLM-5.3-Flash native Vision

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

292. GLM-5.3-Flash Videoeingabe

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

293. GLM-5.3-Flash Dateiinput

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

294. GLM-5.3-Flash Hybrid Attention

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

295. GLM-5.3-Flash mHC

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

296. GLM-5.3-Flash Inferenz auf chinesischen Beschleunigern

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

297. ReplaySSM im Flash-Serving

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

298. W8A8-Quantisierung im Flash-Serving

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

299. KV-Cache-Quantisierung

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

300. Encode-Prefill-Decode-Disaggregation

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

301. GLM-5.3-Flash in AutoClaw

GLM-5-Familie: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

302. GLM-5.3-Flash in ZCode

GLM-5-Familie: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

303. GLM-5.3 versus Flash auswählen

GLM-5-Familie: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

304. Aktueller Endpunkt am 1. September 2026

GLM-5-Familie: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

305. 14. Januar 2026: GLM-Image

GLM-Image kombiniert ein autoregressives 9B-Modell für semantische Planung mit einem 7B-DiT-Diffusionsdecoder für visuelle Details.

Die hybride Bildarchitektur zielt besonders auf textreiche Poster, Diagramme und wissensintensive Bildgenerierung.

306. GLM-Image und Text im Bild

Ein Schwerpunkt ist stabilere Typografie innerhalb generierter Grafiken.

Auch bei spezialisierten Modellen müssen Texte in produktiven Bildern manuell geprüft werden, besonders bei Zahlen, Formeln und Markenangaben.

307. GLM-OCR

GLM-OCR ist ein spezialisierter Dokumentparser mit nur rund 0,9B Parametern und separatem Fokus auf Text, Tabellen, Formeln, Handschrift und Stempel.

OCR ist damit keine Nebenfunktion des Chatmodells, sondern ein eigener effizienter Modellpfad.

308. 0,9B GLM-OCR

Die geringe Modellgröße ermöglicht vLLM- und SGLang-Serving mit deutlich weniger Ressourcen als GLM-5.

Für Dokumentpipelines kann ein kleines Spezialmodell sinnvoller sein als ein großes Generalistenmodell.

309. 1. April 2026: GLM-5V-Turbo

GLM-5V-Turbo ist ein multimodales Codingmodell für Video, Bild, Text und Dateien mit 200K Kontext und bis zu 128K Output.

Es schließt die Schleife aus Umgebung verstehen, planen und handeln in visuellen Coding- und Computer-Use-Szenarien.

310. GLM-ASR-Nano

Die 2026 sichtbare ASR-Nano-Linie erweitert Speech Recognition um kompaktere Modelle.

Spracherkennung wird getrennt von Echtzeit-Dialog und TTS evaluiert.

311. GLM-TTS

GLM-TTS steht für Sprachsynthese innerhalb des Z.ai-Modellportfolios.

Voice Generation benötigt eigene Prüfungen für Aussprache, Sprecherähnlichkeit, Rechte und missbräuchliche Imitation.

312. AutoClaw: Agent für Arbeit

AutoClaw ist eine Desktop-Agentenschicht, die Browser, Dateien, APIs, Skripte und Messaging-Kanäle bedienen kann.

Das Produkt kann GLM-Modelle einsetzen, ist aber nicht selbst ein Foundation-Modell.

313. 29. Mai 2026: AutoClaw Cluster Mode

Cluster Mode erzwingt einen Prozess aus Planen, Recherchieren, Parallelisieren, Prüfen und Liefern.

Mehragentensysteme können Fehler reduzieren, erzeugen aber zusätzliche Koordinations-, Kosten- und Berechtigungsrisiken.

314. AutoClaw Multi-Agent

Mehrere Agenten können getrennte Workspaces und Memories besitzen.

Isolation ist nur dann belastbar, wenn auch Dateizugriffe, Tokens, Connectorrechte und lokale Prozesse getrennt konfiguriert sind.

315. Hermes Self-Evolution

AutoClaw kann aus bestätigten Nutzerkorrekturen dauerhafte Regeln beziehungsweise Skills ableiten.

Das Produkt beschreibt einen Bestätigungsmechanismus; Memory-Regeln bleiben trotzdem eine Produktschicht und verändern nicht die GLM-Gewichte.

316. 24. Juni 2026: AutoClaw 1.9 und GLM-5.2

AutoClaw integrierte GLM-5.2 und nutzte den 1M-Kontext für lange PRDs, Dokumentbestände und Designarbeit.

Dies illustriert, wie ein Foundation-Modell erst durch Produkttools, Rendering und Iteration zu einem Arbeitsworkflow wird.

317. Auto Design

Auto Design erzeugt und überarbeitet UI- und Designartefakte innerhalb AutoClaw.

Design-Agent, Bildmodell und Codingmodell dürfen nicht als derselbe technische Baustein beschrieben werden.

318. ZCode

ZCode ist Z.ai's aktuelles Coding-Harness und wird am Stichtag tief mit GLM-5.3 und GLM-5.3-Flash integriert.

Es ergänzt das Modell um Workspace, Tools, Skills, MCP, Browser Control, Aufgaben, Remote Control und Multi-Agent-Koordination.

319. ZCode Goal Mode

Goal Mode plant, implementiert, testet und verifiziert längere Codingziele.

Long-Horizon-Autonomie sollte durch Branches, Tests, Diff-Prüfung und begrenzte Schreibrechte abgesichert werden.

320. ZCode Remote Control

Lange Tasks können mobil überwacht und gesteuert werden.

Remote Control verändert den Kontrollkanal, nicht die zugrunde liegenden Modellgewichte.

321. GLM Coding Plan

Der Coding Plan ist ein Abonnement für unterstützte Codingtools und verwendet einen eigenen Coding-Endpunkt.

Sein Kontingent ist nicht als allgemeines API-Guthaben gedacht und unterliegt eigenen Nutzungsregeln.

322. General API versus Coding Endpoint

Die allgemeine API verwendet /api/paas/v4, während der Coding Plan /api/coding/paas/v4 nutzt.

Ein falscher Endpunkt kann zu Authentifizierungs-, Quota- oder Funktionsunterschieden führen, obwohl derselbe Modellname verwendet wird.

323. GLM-Image autoregressiver Planer

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

324. GLM-Image Diffusionsdecoder

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

325. Glyph Encoder

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

326. Bildauflösungen und Seitenverhältnisse

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

327. GLM-Image für Diagramme

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

328. GLM-Image für Poster

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

329. GLM-OCR Tabellen

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

330. GLM-OCR Formeln

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

331. GLM-OCR Handschrift

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

332. GLM-OCR Stempel

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

333. GLM-OCR für RAG

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

334. GLM-OCR lokale Inferenz

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

335. GLM-5V-Turbo Vision Coding

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

336. GLM-5V-Turbo Videoverständnis

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

337. GLM-5V-Turbo UI-Agenten

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

338. GLM-ASR versus GLM-Realtime

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

339. TTS versus Voice-Dialog

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

340. AutoGLM versus AutoClaw

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

341. AutoClaw lokal als Harness

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

342. Cloudmodell trotz lokalem Agenten

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

343. Browserautomation

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

344. Dateizugriff

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

345. Shellausführung

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

346. Connectoren

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

347. Messaging-Integrationen

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

348. Cluster Mode

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

349. Subagenten

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

350. Agenten-Memory

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

351. Skill-Evolution

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

352. ZCode Workspace

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

353. ZCode Plugins

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

354. ZCode Skills

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

355. ZCode MCP

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

356. ZCode Browser Control

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

357. ZCode Präsentationsvorschau

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

358. ZCode Projektwissen

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

359. ZCode Subagenten

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

360. ZCode Automationen

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

361. ZCode Remote Workspace

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

362. Coding Plan Lite/Pro/Max

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

363. Coding Plan Punkte

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

364. Off-Peak-Kontingent

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

365. Coding Plan nicht resellen

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

366. Coding Plan nicht als SaaS-Backend

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

367. Z.ai Chat als Consumerprodukt

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

368. Open WebUI als Frontendbasis

Produkte und Spezialmodelle 2026: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

369. Z.ai API Platform

Produkte und Spezialmodelle 2026: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

370. bigmodel.cn und Z.ai nicht gleichsetzen

Produkte und Spezialmodelle 2026: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

371. China- und internationale Produktpfade

Produkte und Spezialmodelle 2026: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

372. Aktuelles GLM-Portfolio am 1. September 2026

Der Stichtag verlangt eine Trennung zwischen Hauptmodell, Effizienzmodell, multimodalen Spezialisten und Produktoberflächen.

Wer nur nach dem neuesten Namen sucht, kann für OCR, Bildgenerierung oder lokale Edge-Szenarien leicht das falsche Werkzeug wählen.

373. Flagship: GLM-5.3

Aktuelles Portfolio: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

374. Effizienz: GLM-5.3-Flash

Aktuelles Portfolio: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

375. Long Context: GLM-5.2

Aktuelles Portfolio: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

376. Agentic Engineering: GLM-5.1

Aktuelles Portfolio: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

377. Vision Coding: GLM-5V-Turbo

Aktuelles Portfolio: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

378. Dokumente: GLM-OCR

Aktuelles Portfolio: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

379. Bildgenerierung: GLM-Image

Aktuelles Portfolio: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

380. Spracherkennung: GLM-ASR

Aktuelles Portfolio: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

381. Sprachsynthese: GLM-TTS

Aktuelles Portfolio: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

382. Device Agency: AutoGLM

Aktuelles Portfolio: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

383. Arbeitsagent: AutoClaw

Aktuelles Portfolio: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

384. Coding Harness: ZCode

Aktuelles Portfolio: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

385. Coding-Abonnement: GLM Coding Plan

Aktuelles Portfolio: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

386. Consumerchat: Z.ai

Aktuelles Portfolio: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

387. Developer Platform: Z.ai API

Aktuelles Portfolio: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

388. Aktuelle Open-Weight-Lizenzen vergleichen

Aktuelles Portfolio: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

389. GLM-5.3-Lizenz versus MIT

Aktuelles Portfolio: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

390. Open Weights versus Open Source

Aktuelles Portfolio: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

391. Modellgröße versus aktive Parameter

Aktuelles Portfolio: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

392. Kontext versus Outputlimit

Aktuelles Portfolio: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

393. Thinking versus Agent Planning

Aktuelles Portfolio: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

394. Search versus Modellwissen

Aktuelles Portfolio: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

395. Memory versus Kontext

Aktuelles Portfolio: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

396. Tool Use versus autonome Aktion

Aktuelles Portfolio: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

397. Model Card versus Produktmarketing

Aktuelles Portfolio: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

398. Z.ai REST API

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

399. Chat Completions

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

400. Multimodale Chat Completion

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

401. Streaming

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

402. Reasoning Content

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

403. Thinking-Konfiguration

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

404. reasoning_effort

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

405. Tool Calls

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

406. Streaming Tool Calls

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

407. Function Calling

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

408. Tool Choice

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

409. Structured Output

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

410. JSON-Ausgabe

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

411. Context Caching

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

412. Cached Input

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

413. Files

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

414. File Upload

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

415. 100 Dateien pro Agentenpfad

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

416. 100 MB pro Datei

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

417. 180 Tage Dateiaufbewahrung im Agenten-Upload

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

418. Web Search

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

419. Web Reader

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

420. Search-Ergebnis versus Modellantwort

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

421. Retrieval

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

422. Agenten-API

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

423. Agent State

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

424. Conversation State

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

425. SDK für Python

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

426. SDK für Java

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

427. Direktes HTTP

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

428. API Keys

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

429. Rate Limits

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

430. Billing Delay

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

431. Model Aliases

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

432. Feste Model IDs

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

433. Migration GLM-4.7 zu GLM-5.1

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

434. Migration GLM-5.1 zu GLM-5.3

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

435. thinking.disabled ist bei GLM-5.3 ungültig

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

436. tool_stream korrekt zusammensetzen

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

437. max_tokens und Kontext

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

438. temperature

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

439. top_p

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

440. Sampling nur gezielt verändern

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

441. OpenAI-kompatible Clients

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

442. Anthropic-kompatible Codingtools

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

443. Coding Endpoint

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

444. General Endpoint

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

445. Coding Plan Auth

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

446. Claude Code mit GLM

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

447. Cline mit GLM

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

448. OpenCode mit GLM

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

449. Roo Code mit GLM

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

450. Kilo Code mit GLM

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

451. MCP als Toolprotokoll

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

452. MCP-Serverrechte

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

453. Browser Tool

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

454. Code Execution

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

455. Web Reader Cache

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

456. API-Fehlercodes

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

457. Idempotenz bei Schreibaktionen

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

458. Retry-Strategie

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

459. Timeouts bei Long-Horizon-Tasks

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

460. Abbruch und Cancel

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

461. Kostenprotokoll

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

462. Tokenprotokoll

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

463. Cache-Hit-Rate

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

464. Response-Validierung

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

465. Schema-Validierung

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

466. Toolresultate als untrusted input

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

467. Prompt Injection in Toolresultaten

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

468. Agenten-Loop-Limit

API und Integration: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

469. Human-in-the-loop

API und Integration: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

470. Audit Log

API und Integration: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

471. Regressionstest nach Modellwechsel

API und Integration: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

472. GLM lokal betreiben

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

473. Hugging Face Checkpoints

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

474. ModelScope

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

475. Safetensors-Shards

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

476. GLM-5.3 rund 756 GB Checkpoint

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

477. BF16 versus FP8

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

478. Quantisierung

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

479. Weight Memory

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

480. KV-Cache

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

481. 1M Kontext und KV-Speicher

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

482. MoE-Speicher ist nicht aktive Parameterzahl

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

483. Tensor Parallelism

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

484. Expert Parallelism

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

485. Pipeline Parallelism

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

486. vLLM

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

487. SGLang

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

488. KTransformers

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

489. Transformers

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

490. Unsloth

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

491. xLLM

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

492. Ascend NPU

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

493. vLLM-Ascend

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

494. AMD-Unterstützung je Runtime prüfen

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

495. NVIDIA H100/H200

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

496. Consumer-GPU-Grenzen

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

497. Multi-GPU-NVLink

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

498. PCIe als Bottleneck

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

499. CPU-Offload

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

500. RAM-Offload

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

501. NVMe-Offload

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

502. FP8-Kompatibilität

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

503. W8A8

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

504. INT4-Communityquantisierungen

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

505. GGUF bei kleineren historischen GLMs

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

506. llama.cpp für GLM-4-9B

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

507. Ollama für GLM-4-9B

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

508. GLM-4.7-Flash lokal

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

509. GLM-OCR lokal

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

510. AutoGLM-Phone lokal

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

511. GLM-5.3-Flash lokale Anforderungen

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

512. Neuer Linear-Attention-Layer und Runtimeversion

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

513. Chattemplate exakt pinnen

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

514. clear_thinking

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

515. Tokenizerrevision

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

516. generation_config

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

517. Speculative Decoding

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

518. MTP-Unterstützung

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

519. Prefix Cache

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

520. Batching

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

521. Continuous Batching

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

522. Prefill versus Decode

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

523. Disaggregated Serving

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

524. ReplaySSM

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

525. Prompt Cache

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

526. Long-Context-Benchmark lokal

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

527. Durchsatz versus Latenz

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

528. Tokens pro Sekunde richtig messen

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

529. Time to First Token

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

530. Tool-Latenz separat messen

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

531. Energieverbrauch

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

532. Serverbetrieb versus Desktop

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

533. Air-Gapped Deployment

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

534. Netzwerkzugriffe der Runtime prüfen

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

535. Telemetry prüfen

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

536. Model Download Hashes

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

537. Revision Pinning

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

538. Container Images pinnen

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

539. CUDA-Version

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

540. PyTorch-Version

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

541. Transformers-Version

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

542. vLLM-Version

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

543. SGLang-Version

Lokale Inferenz: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

544. Reproduzierbarer Startbefehl

Lokale Inferenz: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

545. Health Checks

Lokale Inferenz: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

546. Rollback auf vorherigen Checkpoint

Lokale Inferenz: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

547. Z.ai Consumer-Privacy ist nicht die API-DPA

Die Z.ai Privacy Policy gilt für individuelle Nutzer und nennt eine singapurische Gesellschaft als Verantwortlichen; für Business/API-Daten verweist sie ausdrücklich auf ein separates Data Processing Addendum.

Consumerchat und API dürfen deshalb datenschutzrechtlich nicht pauschal gleichgesetzt werden.

548. Consumer-Inhalte können zur Serviceverbesserung verarbeitet werden

Die Terms of Use sehen für individuelle Nutzer eine Verarbeitung von User Content zur Verbesserung beziehungsweise Entwicklung von Diensten vor, einschließlich Speicherung nicht-personenbezogener Inhalte für ML-/AI-Entwicklung.

Für vertrauliche Daten ist daher nicht nur der Modellname, sondern die konkrete Produkt- und Vertragsklasse entscheidend.

549. API-DPA

Für Business- und Enterprise-API-Nutzung enthält die Dokumentation ein eigenes Data Processing Addendum mit Rollen, Transfers und Rückgabe-/Löschungsregeln.

Vertragliche Aussagen werden nicht auf Consumer-Z.ai oder Drittanbieter-Harnesses übertragen.

550. Datencontroller im internationalen Z.ai-Dienst

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

551. Consumer versus Business

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

552. API-DPA

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

553. Internationaler Datentransfer

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

554. Datenresidenz nicht aus chinesischer Modellherkunft ableiten

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

555. Z.ai international versus bigmodel.cn

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

556. Trainingsnutzung von Consumerinhalten

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

557. Opt-out und Kontoeinstellungen aktuell prüfen

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

558. Feedbackdaten

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

559. API-Logs

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

560. Agenten-Dateien

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

561. 180-Tage-Dateiaufbewahrung

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

562. Cloud-Cache

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

563. Coding Plan Datenfluss

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

564. ZCode Workspace-Daten

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

565. AutoClaw lokale Dateien

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

566. AutoClaw Cloudmodellzugriff

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

567. Lokal ausgeführter Agent ist nicht automatisch lokale Inferenz

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

568. Self-Hosting als stärkste Modellkontrolle

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

569. Self-Hosting braucht eigene Logsicherheit

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

570. API-Key-Schutz

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

571. Secrets nicht in Prompt

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

572. Secrets in Repositorys

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

573. Git-Credentials

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

574. SSH-Keys

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

575. MCP-Token

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

576. Browser-Cookies

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

577. Prompt Injection

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

578. Indirect Prompt Injection

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

579. Webseiten als untrusted input

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

580. Dateien als untrusted input

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

581. Visuelle Prompt Injection

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

582. Tool Output Injection

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

583. Agentenrechte minimieren

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

584. Read-only zuerst

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

585. Schreibrechte begrenzen

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

586. Shellzugriff sandboxen

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

587. Netzwerkzugriff beschränken

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

588. Zahlungen bestätigen

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

589. Löschaktionen bestätigen

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

590. Git Push bestätigen

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

591. Package Installation kontrollieren

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

592. Supply-Chain-Risiko

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

593. Remote Code in historischen GLM-Repos

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

594. trust_remote_code pinnen

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

595. Model Card ist kein Security Audit

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

596. GLM-5.3 Cyberfähigkeit

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

597. Dual-Use Coding

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

598. Vulnerability Disclosure

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

599. Exploitgenerierung absichern

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

600. Security Scanning defensiv verwenden

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

601. Sandbox für Securitytests

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

602. Keine Produktionssecrets in Security-Agenten

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

603. AutoGLM Device Agency

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

604. ADB-Rechte

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

605. Cloud Phone als Sandbox

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

606. AutoClaw Browserautomation

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

607. ZCode Browser Control

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

608. MCP OAuth

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

609. Connector ACL

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

610. Memory Isolation

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

611. Multi-Agent-Isolation

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

612. Human Review

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

613. Least Privilege

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

614. Fail Safe

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

615. Rollback

Datenschutz und Sicherheit: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

616. Audit Trail

Datenschutz und Sicherheit: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

617. Reproduzierbare Logs

Datenschutz und Sicherheit: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

618. Rechts- und Complianceprüfung

Datenschutz und Sicherheit: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

619. Wann GLM-5.3 wählen

Praktische Auswahl: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

620. Wann GLM-5.3-Flash wählen

Praktische Auswahl: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

621. Wann GLM-5.2 weiter sinnvoll ist

Praktische Auswahl: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

622. Wann GLM-5.1 weiter sinnvoll ist

Praktische Auswahl: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

623. Wann GLM-4.7-Flash genügt

Praktische Auswahl: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

624. Wann GLM-5V-Turbo besser passt

Praktische Auswahl: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

625. Wann GLM-OCR statt Generalist

Praktische Auswahl: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

626. Wann GLM-Image statt Visionmodell

Praktische Auswahl: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

627. Wann GLM-ASR

Praktische Auswahl: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

628. Wann GLM-TTS

Praktische Auswahl: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

629. Wann AutoGLM

Praktische Auswahl: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

630. Wann AutoClaw

Praktische Auswahl: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

631. Wann ZCode

Praktische Auswahl: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

632. Wann Coding Plan

Praktische Auswahl: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

633. Wann allgemeine API

Praktische Auswahl: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

634. Wann Self-Hosting

Praktische Auswahl: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

635. Wann lokales kleines GLM-4-Modell

Praktische Auswahl: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

636. Wann 1M Kontext wirklich nötig ist

Praktische Auswahl: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

637. Wann Retrieval besser als 1M Rohkontext ist

Praktische Auswahl: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

638. Wann Reasoning low

Praktische Auswahl: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

639. Wann Reasoning high

Praktische Auswahl: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

640. Wann Reasoning max

Praktische Auswahl: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

641. Wann Tools abschalten

Praktische Auswahl: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

642. Wann Websuche zuschalten

Praktische Auswahl: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

643. Wann Agenten nicht autonom laufen sollten

Praktische Auswahl: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

644. Coding im kleinen Repository

Praktische Auswahl: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

645. Monorepo-Analyse

Praktische Auswahl: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

646. Long-Horizon Refactoring

Praktische Auswahl: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

647. Frontend und visuelles Feedback

Praktische Auswahl: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

648. Dokumentextraktion

Praktische Auswahl: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

649. Research mit Quellen

Praktische Auswahl: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

650. Automatisierte Office-Arbeit

Praktische Auswahl: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

651. Security Review

Praktische Auswahl: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

652. Lokaler Datenschutz

Praktische Auswahl: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

653. Kostenoptimierung

Praktische Auswahl: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

654. Latenzoptimierung

Praktische Auswahl: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

655. Durchsatzoptimierung

Praktische Auswahl: für die Chronik ist dieser Punkt eine eigene Ebene und darf nicht mit benachbarten Produktnamen gleichgesetzt werden.

Bei Vergleichen zählt deshalb der konkrete Checkpoint, die Produktoberfläche, der Toolpfad und der dokumentierte Zeitstand.

656. Edge-Szenario

Praktische Auswahl: technisch ist hier weniger der Markenname als die konkrete Implementierung entscheidend.

Kontextlänge, Chattemplate, Thinking-Modus, Toolschema, Runtime und Lizenz können selbst innerhalb derselben Familie deutlich variieren.

657. Unternehmensintegration

Praktische Auswahl: dieser Baustein zeigt, wie sich GLM von einem Sprachmodellprojekt zu einem breiten Modell- und Agentenökosystem entwickelt hat.

Für reproduzierbare Tests wird die jeweilige Version getrennt von Z.ai-Chat, API, Coding Plan, ZCode oder AutoClaw dokumentiert.

658. Archivierung alter GLM-Checkpoints

Praktische Auswahl: in praktischen Integrationen entstehen Fehler häufig nicht im Modell allein, sondern an der Grenze zwischen Modell, Harness und Werkzeug.

Darum werden Eingabeformat, Ausgabeformat, Toolrechte, Cache, Streaming und Deploymentform gemeinsam geprüft.

659. Problemhilfe: Modellname wird abgelehnt

Bei „Modellname wird abgelehnt“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

660. Problemhilfe: GLM-5.3 liefert 400 bei thinking disabled

Bei „GLM-5.3 liefert 400 bei thinking disabled“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

661. Problemhilfe: reasoning_effort wird ignoriert

Bei „reasoning_effort wird ignoriert“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

662. Problemhilfe: Antwort enthält kein reasoning_content

Bei „Antwort enthält kein reasoning_content“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

663. Problemhilfe: Reasoningblöcke gehen zwischen Turns verloren

Bei „Reasoningblöcke gehen zwischen Turns verloren“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

664. Problemhilfe: Preserved Thinking bricht den Cache

Bei „Preserved Thinking bricht den Cache“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

665. Problemhilfe: Tool Call ist unvollständig

Bei „Tool Call ist unvollständig“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

666. Problemhilfe: Streaming Tool JSON ist kaputt

Bei „Streaming Tool JSON ist kaputt“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

667. Problemhilfe: Toolargumente werden doppelt ausgeführt

Bei „Toolargumente werden doppelt ausgeführt“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

668. Problemhilfe: Agent hängt in Toolschleife

Bei „Agent hängt in Toolschleife“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

669. Problemhilfe: Agent wiederholt dieselbe Suche

Bei „Agent wiederholt dieselbe Suche“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

670. Problemhilfe: Agent verliert Ziel nach vielen Turns

Bei „Agent verliert Ziel nach vielen Turns“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

671. Problemhilfe: 1M-Kontext erzeugt trotzdem falsche Antwort

Bei „1M-Kontext erzeugt trotzdem falsche Antwort“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

672. Problemhilfe: Repository passt angeblich trotz 1M nicht

Bei „Repository passt angeblich trotz 1M nicht“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

673. Problemhilfe: Output bricht vor 128K ab

Bei „Output bricht vor 128K ab“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

674. Problemhilfe: 413 bei Datei-Upload

Bei „413 bei Datei-Upload“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

675. Problemhilfe: Dateiformat wird abgelehnt

Bei „Dateiformat wird abgelehnt“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

676. Problemhilfe: Agent findet hochgeladene Datei nicht

Bei „Agent findet hochgeladene Datei nicht“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

677. Problemhilfe: Web Reader liefert leere Seite

Bei „Web Reader liefert leere Seite“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

678. Problemhilfe: Websuche findet falsche Quelle

Bei „Websuche findet falsche Quelle“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

679. Problemhilfe: Quelle stützt den Satz nicht

Bei „Quelle stützt den Satz nicht“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

680. Problemhilfe: Citation verweist auf falschen Abschnitt

Bei „Citation verweist auf falschen Abschnitt“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

681. Problemhilfe: JSON Structured Output ist ungültig

Bei „JSON Structured Output ist ungültig“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

682. Problemhilfe: JSON verliert unerwartete Tokens

Bei „JSON verliert unerwartete Tokens“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

683. Problemhilfe: 429 Rate Limit

Bei „429 Rate Limit“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

684. Problemhilfe: 401 API Key

Bei „401 API Key“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

685. Problemhilfe: 403 trotz gültigem Key

Bei „403 trotz gültigem Key“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

686. Problemhilfe: Coding Plan funktioniert im General Endpoint nicht

Bei „Coding Plan funktioniert im General Endpoint nicht“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

687. Problemhilfe: General API funktioniert im Coding Tool anders

Bei „General API funktioniert im Coding Tool anders“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

688. Problemhilfe: Quota scheint falsch

Bei „Quota scheint falsch“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

689. Problemhilfe: Billing ist verzögert

Bei „Billing ist verzögert“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

690. Problemhilfe: Cache-Hit bleibt null

Bei „Cache-Hit bleibt null“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

691. Problemhilfe: Cache macht alte Antwort sichtbar

Bei „Cache macht alte Antwort sichtbar“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

692. Problemhilfe: GLM-5.3-Flash startet in vLLM nicht

Bei „GLM-5.3-Flash startet in vLLM nicht“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

693. Problemhilfe: Linear-Attention-Klasse fehlt

Bei „Linear-Attention-Klasse fehlt“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

694. Problemhilfe: SGLang startet neuen Checkpoint nicht

Bei „SGLang startet neuen Checkpoint nicht“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

695. Problemhilfe: Transformers kennt Architektur nicht

Bei „Transformers kennt Architektur nicht“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

696. Problemhilfe: CUDA OOM

Bei „CUDA OOM“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

697. Problemhilfe: KV-Cache OOM bei langem Kontext

Bei „KV-Cache OOM bei langem Kontext“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

698. Problemhilfe: MoE braucht viel mehr Speicher als aktive Parameter vermuten lassen

Bei „MoE braucht viel mehr Speicher als aktive Parameter vermuten lassen“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

699. Problemhilfe: FP8 ist langsamer als erwartet

Bei „FP8 ist langsamer als erwartet“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

700. Problemhilfe: Quantisierte Version liefert Qualitätsverlust

Bei „Quantisierte Version liefert Qualitätsverlust“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

701. Problemhilfe: Mehr GPUs machen es nicht schneller

Bei „Mehr GPUs machen es nicht schneller“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

702. Problemhilfe: Expert Parallelism skaliert schlecht

Bei „Expert Parallelism skaliert schlecht“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

703. Problemhilfe: NVLink fehlt

Bei „NVLink fehlt“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

704. Problemhilfe: CPU-Offload ist extrem langsam

Bei „CPU-Offload ist extrem langsam“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

705. Problemhilfe: Tokenizer passt nicht zum Checkpoint

Bei „Tokenizer passt nicht zum Checkpoint“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

706. Problemhilfe: Chattemplate falsch

Bei „Chattemplate falsch“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

707. Problemhilfe: clear_thinking falsch gesetzt

Bei „clear_thinking falsch gesetzt“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

708. Problemhilfe: GLM-4.7 verhält sich nach Migration anders

Bei „GLM-4.7 verhält sich nach Migration anders“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

709. Problemhilfe: GLM-5.2 verhält sich anders als 5.3

Bei „GLM-5.2 verhält sich anders als 5.3“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

710. Problemhilfe: GLM-5.3 ist langsamer als Flash

Bei „GLM-5.3 ist langsamer als Flash“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

711. Problemhilfe: Flash ist nicht klein genug für Consumer-GPU

Bei „Flash ist nicht klein genug für Consumer-GPU“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

712. Problemhilfe: Visionmodell übersieht UI-Detail

Bei „Visionmodell übersieht UI-Detail“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

713. Problemhilfe: Videoanalyse verliert zeitliche Reihenfolge

Bei „Videoanalyse verliert zeitliche Reihenfolge“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

714. Problemhilfe: OCR liest Tabelle falsch

Bei „OCR liest Tabelle falsch“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

715. Problemhilfe: OCR liest Formel falsch

Bei „OCR liest Formel falsch“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

716. Problemhilfe: OCR erkennt Stempel falsch

Bei „OCR erkennt Stempel falsch“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

717. Problemhilfe: ASR verwechselt Fachbegriffe

Bei „ASR verwechselt Fachbegriffe“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

718. Problemhilfe: TTS spricht Namen falsch

Bei „TTS spricht Namen falsch“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

719. Problemhilfe: GLM-Image schreibt Text falsch

Bei „GLM-Image schreibt Text falsch“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

720. Problemhilfe: Bildmodell verändert Zahlen

Bei „Bildmodell verändert Zahlen“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

721. Problemhilfe: AutoGLM tippt in falsches Feld

Bei „AutoGLM tippt in falsches Feld“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

722. Problemhilfe: AutoGLM hängt an Popup

Bei „AutoGLM hängt an Popup“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

723. Problemhilfe: AutoClaw Agent sieht falschen Workspace

Bei „AutoClaw Agent sieht falschen Workspace“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

724. Problemhilfe: Multi-Agent Memory vermischt sich

Bei „Multi-Agent Memory vermischt sich“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

725. Problemhilfe: ZCode arbeitet auf falschem Branch

Bei „ZCode arbeitet auf falschem Branch“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

726. Problemhilfe: ZCode installiert falsches Paket

Bei „ZCode installiert falsches Paket“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

727. Problemhilfe: ZCode committet Secret

Bei „ZCode committet Secret“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

728. Problemhilfe: Remote Agent sieht geheime Datei

Bei „Remote Agent sieht geheime Datei“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

729. Problemhilfe: MCP Server verbindet nicht

Bei „MCP Server verbindet nicht“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

730. Problemhilfe: MCP OAuth scheitert

Bei „MCP OAuth scheitert“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

731. Problemhilfe: MCP Resultat injiziert Instruktion

Bei „MCP Resultat injiziert Instruktion“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

732. Problemhilfe: Browser Control hat alte Session

Bei „Browser Control hat alte Session“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

733. Problemhilfe: Scheduled Task läuft doppelt

Bei „Scheduled Task läuft doppelt“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

734. Problemhilfe: Long-Horizon Task verbraucht zu viel Budget

Bei „Long-Horizon Task verbraucht zu viel Budget“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

735. Problemhilfe: Subagenten widersprechen sich

Bei „Subagenten widersprechen sich“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

736. Problemhilfe: Security-Agent produziert riskanten Exploitcode

Bei „Security-Agent produziert riskanten Exploitcode“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

737. Problemhilfe: Vulnerability-Fund ist False Positive

Bei „Vulnerability-Fund ist False Positive“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

738. Problemhilfe: Rollback nach Modellupdate

Bei „Rollback nach Modellupdate“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

739. Problemhilfe: Regression nach latest-Alias

Bei „Regression nach latest-Alias“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

740. Problemhilfe: Historischer ChatGLM-Code lädt nicht mehr

Bei „Historischer ChatGLM-Code lädt nicht mehr“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

741. Problemhilfe: trust_remote_code Sicherheitswarnung

Bei „trust_remote_code Sicherheitswarnung“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

742. Problemhilfe: Alter ChatGLM-Checkpoint braucht alte Transformers-Version

Bei „Alter ChatGLM-Checkpoint braucht alte Transformers-Version“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

743. Problemhilfe: GLM-4-9B Ollama-Template ist falsch

Bei „GLM-4-9B Ollama-Template ist falsch“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

744. Problemhilfe: 1M-Test ist nicht reproduzierbar

Bei „1M-Test ist nicht reproduzierbar“ wird zuerst bestimmt, ob der Fehler aus Modell, API, Harness, Runtime, Tool, Berechtigung oder Kontext stammt. Ein Modellwechsel ohne diese Trennung verschiebt den Fehler häufig nur.

Sinnvoll sind ein minimales reproduzierbares Beispiel, feste Modellrevision, protokollierte Parameter, reduzierte Toolrechte und ein Vergleich mit einem bekannten funktionierenden Baseline-Aufruf.

745. Mythos: ChatGLM war der Anfang von GLM

Die Aussage „ChatGLM war der Anfang von GLM“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

746. Mythos: Z.ai und Zhipu AI sind exakt derselbe Produktname

Die Aussage „Z.ai und Zhipu AI sind exakt derselbe Produktname“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

747. Mythos: ChatGLM-6B war das große kommerzielle ChatGLM

Die Aussage „ChatGLM-6B war das große kommerzielle ChatGLM“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

748. Mythos: GLM-5.3 ist MIT-lizenziert

Die Aussage „GLM-5.3 ist MIT-lizenziert“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

749. Mythos: GLM-5.3-Flash ist nur eine quantisierte GLM-5.3-Version

Die Aussage „GLM-5.3-Flash ist nur eine quantisierte GLM-5.3-Version“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

750. Mythos: GLM-5.3-Flash ist ein 18B-Modell

Die Aussage „GLM-5.3-Flash ist ein 18B-Modell“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

751. Mythos: 40B aktive Parameter bedeuten 40B Speicherbedarf

Die Aussage „40B aktive Parameter bedeuten 40B Speicherbedarf“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

752. Mythos: MoE lädt nur die aktiven Experten

Die Aussage „MoE lädt nur die aktiven Experten“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

753. Mythos: 1M Kontext ist Memory

Die Aussage „1M Kontext ist Memory“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

754. Mythos: 1M Kontext macht Retrieval überflüssig

Die Aussage „1M Kontext macht Retrieval überflüssig“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

755. Mythos: 1M Kontext garantiert korrekte Langdokumentanalyse

Die Aussage „1M Kontext garantiert korrekte Langdokumentanalyse“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

756. Mythos: 128K Output sollte immer voll genutzt werden

Die Aussage „128K Output sollte immer voll genutzt werden“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

757. Mythos: Reasoning max ist immer besser

Die Aussage „Reasoning max ist immer besser“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

758. Mythos: Thinking kann bei GLM-5.3 ausgeschaltet werden

Die Aussage „Thinking kann bei GLM-5.3 ausgeschaltet werden“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

759. Mythos: GLM-5.3 hat ein neues Basismodell gegenüber 5.2

Die Aussage „GLM-5.3 hat ein neues Basismodell gegenüber 5.2“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

760. Mythos: Mehr Post-Training ist nur Fine-Tuning im kleinen Sinn

Die Aussage „Mehr Post-Training ist nur Fine-Tuning im kleinen Sinn“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

761. Mythos: GLM-5.3 ist nur ein Codingmodell

Die Aussage „GLM-5.3 ist nur ein Codingmodell“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

762. Mythos: Cyberfähigkeit macht das Modell automatisch unsicher

Die Aussage „Cyberfähigkeit macht das Modell automatisch unsicher“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

763. Mythos: Open Weight bedeutet Open Source ohne Einschränkung

Die Aussage „Open Weight bedeutet Open Source ohne Einschränkung“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

764. Mythos: MIT bei Flash gilt automatisch für alle GLM-Modelle

Die Aussage „MIT bei Flash gilt automatisch für alle GLM-Modelle“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

765. Mythos: GLM-4.5 hat 355B aktive Parameter

Die Aussage „GLM-4.5 hat 355B aktive Parameter“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

766. Mythos: GLM-4.5-Air ist nur ein Tarif

Die Aussage „GLM-4.5-Air ist nur ein Tarif“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

767. Mythos: GLM-4.7-Flash und 5.3-Flash sind dieselbe Größenklasse

Die Aussage „GLM-4.7-Flash und 5.3-Flash sind dieselbe Größenklasse“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

768. Mythos: GLM-5V-Turbo ist einfach GLM-5 mit Bildinput

Die Aussage „GLM-5V-Turbo ist einfach GLM-5 mit Bildinput“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

769. Mythos: GLM-OCR ist nur ein Prompt auf GLM-5

Die Aussage „GLM-OCR ist nur ein Prompt auf GLM-5“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

770. Mythos: GLM-Image ist ein normales Diffusionsmodell

Die Aussage „GLM-Image ist ein normales Diffusionsmodell“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

771. Mythos: AutoGLM ist ein Foundation-Modell

Die Aussage „AutoGLM ist ein Foundation-Modell“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

772. Mythos: AutoClaw ist ein GLM-Checkpoint

Die Aussage „AutoClaw ist ein GLM-Checkpoint“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

773. Mythos: ZCode ist nur ein Editor

Die Aussage „ZCode ist nur ein Editor“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

774. Mythos: Coding Plan ist normales API-Guthaben

Die Aussage „Coding Plan ist normales API-Guthaben“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

775. Mythos: Coding Endpoint und General Endpoint sind austauschbar

Die Aussage „Coding Endpoint und General Endpoint sind austauschbar“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

776. Mythos: Z.ai Chat und API haben identische Datenschutzregeln

Die Aussage „Z.ai Chat und API haben identische Datenschutzregeln“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

777. Mythos: lokaler AutoClaw bedeutet lokale GLM-Inferenz

Die Aussage „lokaler AutoClaw bedeutet lokale GLM-Inferenz“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

778. Mythos: Self-Hosting ist automatisch sicher

Die Aussage „Self-Hosting ist automatisch sicher“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

779. Mythos: Open Weights senden keine Daten

Die Aussage „Open Weights senden keine Daten“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

780. Mythos: Tool Use bedeutet, das Modell besitzt die Tools intern

Die Aussage „Tool Use bedeutet, das Modell besitzt die Tools intern“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

781. Mythos: Websuche ist Modellwissen

Die Aussage „Websuche ist Modellwissen“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

782. Mythos: Memory trainiert die Gewichte neu

Die Aussage „Memory trainiert die Gewichte neu“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

783. Mythos: Agenten denken unabhängig vom Harness

Die Aussage „Agenten denken unabhängig vom Harness“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

784. Mythos: Mehr Agenten bedeuten automatisch bessere Qualität

Die Aussage „Mehr Agenten bedeuten automatisch bessere Qualität“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

785. Mythos: Preserved Thinking ist Langzeitgedächtnis

Die Aussage „Preserved Thinking ist Langzeitgedächtnis“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

786. Mythos: Reasoningtrace beweist Richtigkeit

Die Aussage „Reasoningtrace beweist Richtigkeit“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

787. Mythos: Benchmarks beweisen den besten Produktionscheckpoint

Die Aussage „Benchmarks beweisen den besten Produktionscheckpoint“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

788. Mythos: ein neuer Alias ist reproduzierbar

Die Aussage „ein neuer Alias ist reproduzierbar“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

789. Mythos: FP8 ist immer schneller

Die Aussage „FP8 ist immer schneller“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

790. Mythos: Quantisierung kostet nie Qualität

Die Aussage „Quantisierung kostet nie Qualität“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

791. Mythos: mehr GPUs skalieren linear

Die Aussage „mehr GPUs skalieren linear“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

792. Mythos: Consumer-GPU genügt für jedes Flash-Modell

Die Aussage „Consumer-GPU genügt für jedes Flash-Modell“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

793. Mythos: Vision versteht jedes UI-Element zuverlässig

Die Aussage „Vision versteht jedes UI-Element zuverlässig“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

794. Mythos: OCR-Confidence beweist Wahrheit

Die Aussage „OCR-Confidence beweist Wahrheit“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

795. Mythos: Security-Benchmark entspricht realer Exploitierbarkeit

Die Aussage „Security-Benchmark entspricht realer Exploitierbarkeit“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

796. Mythos: ein Schwachstellenfund ist automatisch ein CVE

Die Aussage „ein Schwachstellenfund ist automatisch ein CVE“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

797. Mythos: Z.ai ist ausschließlich ein chinesischer Consumerchat

Die Aussage „Z.ai ist ausschließlich ein chinesischer Consumerchat“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

798. Mythos: GLM ist nur chinesischsprachig

Die Aussage „GLM ist nur chinesischsprachig“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

799. Mythos: GLM-130B war ein Chatbot

Die Aussage „GLM-130B war ein Chatbot“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

800. Mythos: ChatGLM3 hatte keine Tools

Die Aussage „ChatGLM3 hatte keine Tools“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

801. Mythos: GLM-4 war nur proprietär

Die Aussage „GLM-4 war nur proprietär“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

802. Mythos: GLM-4-9B-1M und GLM-5.2-1M sind technisch gleich

Die Aussage „GLM-4-9B-1M und GLM-5.2-1M sind technisch gleich“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

803. Mythos: GLM-Zero ist der heutige Reasoningpfad

Die Aussage „GLM-Zero ist der heutige Reasoningpfad“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

804. Mythos: GLM-5.3 macht GLM-5.2 archivisch wertlos

Die Aussage „GLM-5.3 macht GLM-5.2 archivisch wertlos“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

805. Mythos: neuester Checkpoint ist immer beste Wahl

Die Aussage „neuester Checkpoint ist immer beste Wahl“ ist als pauschale Regel falsch oder mindestens irreführend. Die GLM-Geschichte enthält mehrere Architektur-, Lizenz-, Produkt- und Deploymentpfade, die sich nicht auf einen Markennamen reduzieren lassen.

Korrekt ist die Prüfung des konkreten Checkpoints, Stichtags, Lizenztexts, Kontext- und Outputlimits, Produktpfads sowie der tatsächlich verwendeten Tools und Datenflüsse.

806. Archivierung: GLM 2021 archivieren

Für „GLM 2021 archivieren“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

807. Archivierung: GLM-Paper-Version archivieren

Für „GLM-Paper-Version archivieren“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

808. Archivierung: GLM-130B Checkpoint archivieren

Für „GLM-130B Checkpoint archivieren“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

809. Archivierung: GLM-130B Quantisierung dokumentieren

Für „GLM-130B Quantisierung dokumentieren“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

810. Archivierung: ChatGLM-6B Revision

Für „ChatGLM-6B Revision“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

811. Archivierung: ChatGLM2-6B Revision

Für „ChatGLM2-6B Revision“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

812. Archivierung: ChatGLM3-6B Revision

Für „ChatGLM3-6B Revision“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

813. Archivierung: GLM-4-9B Base

Für „GLM-4-9B Base“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

814. Archivierung: GLM-4-9B Chat

Für „GLM-4-9B Chat“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

815. Archivierung: GLM-4-9B Chat 1M

Für „GLM-4-9B Chat 1M“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

816. Archivierung: GLM-4V-9B

Für „GLM-4V-9B“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

817. Archivierung: LongWriter

Für „LongWriter“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

818. Archivierung: LongCite

Für „LongCite“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

819. Archivierung: GLM-4-Voice

Für „GLM-4-Voice“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

820. Archivierung: AutoGLM 2024

Für „AutoGLM 2024“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

821. Archivierung: GLM-PC

Für „GLM-PC“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

822. Archivierung: GLM-Zero-Preview

Für „GLM-Zero-Preview“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

823. Archivierung: GLM-4-32B-0414

Für „GLM-4-32B-0414“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

824. Archivierung: GLM-4.1V-Thinking

Für „GLM-4.1V-Thinking“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

825. Archivierung: GLM-4.5

Für „GLM-4.5“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

826. Archivierung: GLM-4.5-Air

Für „GLM-4.5-Air“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

827. Archivierung: GLM-4.5V

Für „GLM-4.5V“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

828. Archivierung: GLM-4.6

Für „GLM-4.6“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

829. Archivierung: GLM-4.7

Für „GLM-4.7“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

830. Archivierung: GLM-4.7-Flash

Für „GLM-4.7-Flash“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

831. Archivierung: AutoGLM Open Source

Für „AutoGLM Open Source“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

832. Archivierung: GLM-5

Für „GLM-5“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

833. Archivierung: GLM-5.1

Für „GLM-5.1“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

834. Archivierung: GLM-5.2

Für „GLM-5.2“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

835. Archivierung: GLM-5.3

Für „GLM-5.3“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

836. Archivierung: GLM-5.3-Lizenz

Für „GLM-5.3-Lizenz“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

837. Archivierung: GLM-5.3-Flash

Für „GLM-5.3-Flash“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

838. Archivierung: GLM-5V-Turbo

Für „GLM-5V-Turbo“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

839. Archivierung: GLM-OCR

Für „GLM-OCR“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

840. Archivierung: GLM-Image

Für „GLM-Image“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

841. Archivierung: GLM-ASR

Für „GLM-ASR“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

842. Archivierung: GLM-TTS

Für „GLM-TTS“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

843. Archivierung: Z.ai API Snapshot

Für „Z.ai API Snapshot“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

844. Archivierung: Coding Plan Snapshot

Für „Coding Plan Snapshot“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

845. Archivierung: ZCode Version

Für „ZCode Version“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

846. Archivierung: AutoClaw Version

Für „AutoClaw Version“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

847. Archivierung: Chattemplate

Für „Chattemplate“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

848. Archivierung: Tokenizer

Für „Tokenizer“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

849. Archivierung: generation_config

Für „generation_config“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

850. Archivierung: Runtimeversion

Für „Runtimeversion“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

851. Archivierung: Container Digest

Für „Container Digest“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

852. Archivierung: GPU-Treiber

Für „GPU-Treiber“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

853. Archivierung: Quantisierung

Für „Quantisierung“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

854. Archivierung: Samplingparameter

Für „Samplingparameter“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

855. Archivierung: reasoning_effort

Für „reasoning_effort“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

856. Archivierung: Toolschema

Für „Toolschema“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

857. Archivierung: MCP-Konfiguration

Für „MCP-Konfiguration“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

858. Archivierung: Browserzustand

Für „Browserzustand“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

859. Archivierung: Dateisnapshot

Für „Dateisnapshot“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

860. Archivierung: Prompt und Systemregeln

Für „Prompt und Systemregeln“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

861. Archivierung: Evaluation Harness

Für „Evaluation Harness“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

862. Archivierung: Benchmarkdatensatz

Für „Benchmarkdatensatz“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

863. Archivierung: Antwort und Tooltrajectory

Für „Antwort und Tooltrajectory“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

864. Archivierung: Kosten und Tokenverbrauch

Für „Kosten und Tokenverbrauch“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

865. Archivierung: SHA-256 der lokalen Gewichte

Für „SHA-256 der lokalen Gewichte“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

866. Archivierung: Lizenzdatei mit archivieren

Für „Lizenzdatei mit archivieren“ reicht der Modellname allein nicht. Archiviert werden Datum, exakte Revision, Lizenz, Konfigurationsdateien und der verwendete Runtimepfad.

Bei agentischen Tests kommen Prompt, Reasoning-/Thinking-Einstellung, Toolschema, Berechtigungen, Dateien, Netzwerkzugriffe und Evaluationsharness hinzu, damit ein späterer Vergleich überhaupt nachvollziehbar bleibt.

867. Vergleich mit OpenAI / ChatGPT

GLM und ChatGPT unterscheiden sich nicht nur in Modellfamilien, sondern auch in Produktintegration, Lizenzierung offener Gewichte und Agenten-/Codingpfaden. Ein sinnvoller Vergleich nennt daher Modell, Produktmodus und Tools.

Die vollständigen Vergleichsseiten werden nur selektiv intern verlinkt; diese Chronik bleibt auf die GLM-Entwicklung konzentriert.

868. Vergleich mit Anthropic Claude

ZCode und Coding Plan können Claude-Code-artige Harnesses bedienen, doch GLM ist dabei das Modell hinter einem fremden Toolprotokoll. Harness und Modell dürfen nicht verwechselt werden.

Die vollständigen Vergleichsseiten werden nur selektiv intern verlinkt; diese Chronik bleibt auf die GLM-Entwicklung konzentriert.

869. Vergleich mit Google Gemini

Bei beiden Familien spielen Multimodalität, langes Kontextfenster und Agenten eine große Rolle. Die konkrete Open-Weight-Strategie und lokale Deploymentfähigkeit unterscheiden sich jedoch deutlich.

Die vollständigen Vergleichsseiten werden nur selektiv intern verlinkt; diese Chronik bleibt auf die GLM-Entwicklung konzentriert.

870. Vergleich mit xAI Grok

Grok ist stärker an ein geschlossenes Produkt- und API-Ökosystem gebunden, während GLM mehrere große Open-Weight-Pfade anbietet. Datenschutz und Tooling werden dennoch pro Produkt geprüft.

Die vollständigen Vergleichsseiten werden nur selektiv intern verlinkt; diese Chronik bleibt auf die GLM-Entwicklung konzentriert.

871. Vergleich mit Meta Llama / Muse

GLM verbindet offene Gewichte mit eigenen Consumer-, Coding- und Agentenprodukten. Llama ist stärker als offene Foundation-Familie bekannt, während Meta-Produkte und Modelle ebenfalls getrennt werden müssen.

Die vollständigen Vergleichsseiten werden nur selektiv intern verlinkt; diese Chronik bleibt auf die GLM-Entwicklung konzentriert.

872. Vergleich mit DeepSeek

Beide Ökosysteme setzen stark auf offene Gewichte, MoE, effiziente Attention und agentisches Coding. GLM-5 integriert sogar DSA, bleibt aber eine eigenständige Architektur- und Trainingslinie.

Die vollständigen Vergleichsseiten werden nur selektiv intern verlinkt; diese Chronik bleibt auf die GLM-Entwicklung konzentriert.

873. Vergleich mit Alibaba Qwen

Qwen besitzt eine sehr breite multimodale Modellfamilie; GLM legt 2026 besonderen Schwerpunkt auf Long-Horizon-Agentic-Engineering, ZCode, AutoClaw und Device Agency.

Die vollständigen Vergleichsseiten werden nur selektiv intern verlinkt; diese Chronik bleibt auf die GLM-Entwicklung konzentriert.

874. Vergleich mit Mistral AI

Mistral und GLM kombinieren offene Gewichte mit gehosteten Produkten und Agenten. Lizenzierung und regionale Datenpfade sind jedoch völlig getrennt zu prüfen.

Die vollständigen Vergleichsseiten werden nur selektiv intern verlinkt; diese Chronik bleibt auf die GLM-Entwicklung konzentriert.

875. Vergleich mit Perplexity

Perplexity ist primär als Search-/Answer-/Agentenprodukt organisiert, GLM dagegen als Foundation-Modellfamilie mit eigenen Produkt- und Toolschichten.

Die vollständigen Vergleichsseiten werden nur selektiv intern verlinkt; diese Chronik bleibt auf die GLM-Entwicklung konzentriert.

876. Vergleich mit Microsoft Copilot

Copilot ist eine Produktfamilie über viele Microsoft-Oberflächen; GLM ist eine Modellfamilie, die unter anderem in Coding-Harnesses eingesetzt werden kann. Produktname und Foundation-Modell sind unterschiedliche Vergleichsebenen.

Die vollständigen Vergleichsseiten werden nur selektiv intern verlinkt; diese Chronik bleibt auf die GLM-Entwicklung konzentriert.

877. Wohin die GLM-Linie 2026 zeigt

Der August-Stand verbindet zwei Richtungen: ein sehr großes, stark post-trainiertes GLM-5.3 für komplexe Langhorizontarbeit und ein neu trainiertes, nativ multimodales GLM-5.3-Flash für effizientere Alltags- und Agentenworkloads.

Parallel wachsen ZCode und AutoClaw zu Harnesses, in denen Agenten, Browser, Dateien, Skills, Memory und Toolrechte mindestens so wichtig sind wie der Modellcheckpoint.

878. Fazit: Von Blank Infilling zu Agentic Engineering

Die GLM-Geschichte beginnt 2021 als Pretraining-Forschungsansatz, skaliert 2022 auf GLM-130B, wird 2023 mit ChatGLM lokal populär, öffnet sich 2024 für Multimodalität und Tools und erreicht 2025/2026 eine ausgeprägte Agenten- und Codingarchitektur.

Der wichtigste praktische Schluss bleibt die saubere Schichtentrennung: Modell, Chatprodukt, API, Coding Plan, ZCode, AutoGLM, AutoClaw, Search, Memory und lokale Inferenz sind keine Synonyme.

Weiterführende interne Themen

Die übergreifende Methoden- und Sicherheitsseite bleibt KI-Werkzeuge. Für direkte technische Vergleiche stehen die großen Chroniken zu OpenAI / ChatGPT, Anthropic Claude, Google Gemini, xAI / Grok, Meta AI / Llama / Muse, Perplexity AI, DeepSeek, Alibaba Qwen, Microsoft Copilot und Mistral AI / Vibe bereit.