GLM 5.2 gegen Opus
(techstackups.com)- Mit demselben One-Shot-Prompt zum Erstellen eines rohen WebGL-3D-Platformers lieferte Opus schnellere und ausgereiftere Ergebnisse, während GLM-5.2 die Vorteile geringerer Kosten und offener Gewichte zeigte
- GLM-5.2 ist ein Open-Weights-Modell unter MIT-Lizenz von Z.ai mit 1M-Token-Kontext und den Denkstufen High/Max, ist aber rein textbasiert und daher bei bildgestützter Selbstverifikation eingeschränkt
- Die tatsächlichen Testkosten lagen bei 5,39 $ für GLM-5.2 und etwa 21,92 $ für Opus; die Build-Zeiten betrugen 1 Stunde 10 Minuten 40 Sekunden bzw. 33 Minuten 30 Sekunden, womit sich ein klarer Trade-off zwischen Tempo und Kosten ergibt
- Im Ergebnis von GLM-5.2 gab es grundlegende Probleme wie fehlende Texturen, nicht funktionierende Stacheln, keine Siegbedingung und ein verbleibendes Debug-Overlay; Opus war sauberer, hatte aber noch eine zu großzügige Kollisionsbewertung bei schmalen schwebenden Plattformen und einen zu weit reichenden Sieg-Trigger
- Auch in Benchmarks und externen Bewertungen erscheint GLM-5.2 als starkes Open-Weights-Modell, doch bei vielen Coding- und Agentenaufgaben liegt Opus vorn; Kosten, Offenheit und visuelle Beurteilung werden damit zu den entscheidenden Auswahlkriterien
Unterschiede bei derselben Aufgabe
- GLM-5.2 ist ein aktuelles Beispiel für das Potenzial offener Modelle, doch bei derselben realen Aufgabe lieferte Claude Opus 4.8 schnellere und präzisere Ergebnisse
- Im Test erhielten beide Modelle denselben One-Shot-Prompt und sollten ohne Game Engine oder 3D-Rendering-Bibliotheken wie Three.js einen 3D-Platformer für den Browser in rohem WebGL von Grund auf erstellen
- Beide Ergebnisse und der Quellcode sind öffentlich verfügbar
- Beide Spiele verwenden kostenlose CC0-Assets aus dem Kenney Platformer Kit
Charakter und Ansatz von GLM-5.2
- GLM-5.2 ist das aktuelle Flaggschiffmodell von Z.ai und wird als Open Weights unter MIT-Lizenz bereitgestellt
- Es kann heruntergeladen und lokal ausgeführt oder über die Z.ai API aufgerufen werden
- Die Gewichte sind auf Hugging Face und ModelScope verfügbar, ohne regionale Beschränkung
- Lokales Serving ist mit Frameworks wie vLLM, SGLang und Transformers möglich
- Das Modell zielt auf Long-Horizon-Aufgaben wie lang andauernde mehrstufige Coding-Agent-Workflows ab
- Es bietet ein Kontextfenster von 1M Token
- Es gibt die Denkstufen High und Max; im Test wurde High verwendet
- Die entscheidende Einschränkung ist, dass es rein textbasiert ist
- GLM-5.2 kann keine Bilder lesen
- Für Workflows, in denen Screenshots oder Diagramme direkt geprüft werden müssen, ist ein multimodales Modell wie Claude Opus erforderlich
Preise und Laufkosten
- Laut Vendor-Dokumentation sind die Preise pro 1M Token bei GLM-5.2 niedriger als bei Opus
- Claude Opus 4.8: Input 5 $, Cache Read 0,50 $, Output 25 $
- GLM-5.2: Input 1,4 $, Cache Read 0,26 $, Output 4,4 $
- Beim Output-Token-Preis liegt GLM-5.2 bei weniger als einem Fünftel von Opus
- Im praktischen Spielentwicklungs-Test entwickelten sich Zeit und Kosten jedoch in entgegengesetzte Richtungen
| Kennzahl | GLM-5.2 (Pi/OpenRouter) | Opus (Claude Code) |
|---|---|---|
| Build-Zeit nach Uhr | 1 Stunde 10 Minuten 40 Sekunden | 33 Minuten 30 Sekunden |
| Output-Token | 131.000 | 216.809 |
| Maximale Kontextnutzung | 16 % von 1M | 19 % von 1M |
| Tool-Aufrufe | 128 | 153 |
| Kosten | 5,39 $ tatsächlich berechnet | ca. 21,92 $ geschätzt |
- Opus war in etwa der halben Zeit fertig, während GLM-5.2 die Aufgabe zu deutlich geringeren Kosten abschloss
Die Testaufgabe: roher WebGL-3D-Platformer
- Die Aufgabe war strukturell komplexer als das Erstellen einer einfachen Landingpage
- GLB-Modellparser
- Matrix- und Vektormathematik
- GLSL-Shader
- Skelettanimation mit Skinning
- Loop mit festem Zeitschritt
- Kollisionsverarbeitung
- Follow-Kamera
- Beide Modelle erhielten denselben Prompt, dieselben Assets und nur einen einzigen Versuch ohne Hinweise
- Die Fertigstellungsbedingungen waren wie folgt
- Eine 3D-Engine und ein Renderer auf Basis von rohem WebGL
- Ein Loader für die bereitgestellten 3D-Charakter- und Weltmodelle
- Charakterbewegung und Sprünge mit Gravitation und Kollision
- Follow-Kamera und Tastatursteuerung
- Ein vollständiges Spiel, das sich mit einem einzigen Kommando im Browser ausführen lässt
- Beide Modelle implementierten große Teile eines GLB-Binärparsers, Matrix- und Quaternion-Mathematik, eines WebGL2-Renderers, von GLSL-Skinning-Shadern und AABB-Kollision mit Substeps selbst
- Auch die Build-Protokolle sind veröffentlicht
Spielergebnis und verbleibende Bugs
- Beide Spiele haben die Form eines 3D-Platformers aus der Third-Person-Perspektive
- Bewegung mit WASD oder den Pfeiltasten
- Springen mit Space
- Sprinten mit Shift
- Kameradrehung per Mausziehen
- Zoom per Mausrad
- Ziel ist es, Münzen zu sammeln, Stacheln auszuweichen und die Flagge zu erreichen
- Wer von der Karte fällt, kehrt zum Startpunkt zurück
-
Ergebnis von GLM-5.2
- Das Spiel von GLM-5.2 wirkte insgesamt roh und unausgereift
- Einige Materialien des Charakters fehlten, und die Figur lief mit dem Rücken zur Bewegungsrichtung
- Stachelfallen töteten oder resetten den Charakter nicht, und beim Erreichen der Flagge wurde keine Siegbedingung ausgelöst
- Beim Bewegen der Kamera verschwand der Kopf, und auch ein Debug-Overlay blieb sichtbar
- Der Abschnitt, in dem eine Feder den Charakter auf die nächste Plattform schleudert, funktionierte gut
- Die Kenney-Modelle verweisen auf eine gemeinsame Farbpalette in einer separaten Datei, doch der Renderer von GLM-5.2 lud diese Datei nicht und ersetzte sie daher durch flache Farben
-
Ergebnis von Opus
- Das Spiel von Opus war sauberer und funktionierte besser
- Kamera und Controller funktionierten, und auch die Logik, bei der Stacheln den Spieler töten, war vorhanden
- Texturen wurden korrekt angewendet, Animationen liefen flüssig, und beim Erreichen der Flagge war ein Sieg möglich
- Die verbleibenden Bugs waren eher Edge Cases als Probleme der Grundfunktionalität
- Der Charakter konnte kurzzeitig neben Plattformen in der Luft stehen; Ursache war eine zu großzügige Coyote-Time, die Sprünge noch direkt nach dem Verlassen der Kante erlaubte
- Die Siegbedingung wurde ausgelöst, obwohl man sich noch recht weit von der Flagge entfernt befand
Multimodaler Unterschied bei der Selbstverifikation
- Beide Modelle wurden angewiesen, das Ergebnis vor Abschluss der Arbeit zu verifizieren
- Opus ist multimodal und prüfte nach dem Rendern des Spiels die aufgenommenen Screenshots direkt
- Es erkannte die noch sichtbare Debug-Anzeige, entfernte sie und schloss die Arbeit erst dann ab
- In der finalen Szene prüfte es Blöcke, Treppen, Münzen, Edelsteine, Stacheln, Flagge, Charakter, Score-HUD, Beleuchtung und Geometrie
- GLM-5.2 konnte keine Bilder lesen und die Screenshots daher nicht direkt betrachten
- Stattdessen nutzte es einen Umweg, bei dem rohe Pixeldaten gelesen und grob mit erwarteten Farbwerten verglichen wurden
- Im gespeicherten Bild wurden Farbkriterien wie grass green, dirt brown, coin gold, flag red, character bluish, half-Lambert lit und no black geprüft
- Diese Methode übersah Probleme im tatsächlichen Bild
- Der Charakter wirkte grau, und Texturen fehlten
- Das Debug-Overlay war weiterhin über dem Bild sichtbar
- Bei Aufgaben, in denen das visuelle Ergebnis wichtig ist, führt multimodale Verifikation damit zu einem realen Qualitätsunterschied
Position in Benchmarks
- In den Modellkarten-Benchmarks von Z.ai liegt GLM-5.2 bei vielen Messgrößen direkt hinter den besten geschlossenen Modellen und führt bei einigen Reasoning-Benchmarks sogar
- Wichtige Werte sind wie folgt
- HLE: GLM-5.2 40,5, Opus 4.8 49,8
- HLE with tools: GLM-5.2 54,7, Opus 4.8 57,9
- AIME 2026: GLM-5.2 99,2, Opus 4.8 95,7
- IMOAnswerBench: GLM-5.2 91,0, Opus 4.8 83,5
- SWE-bench Pro: GLM-5.2 62,1, Opus 4.8 69,2
- NL2Repo: GLM-5.2 48,9, Opus 4.8 69,7
- ProgramBench: GLM-5.2 63,7, Opus 4.8 71,9
- SWE-Marathon: GLM-5.2 13,0, Opus 4.8 26,0
- MCP-Atlas public: GLM-5.2 76,8, Opus 4.8 77,8
- Tool-Decathlon: GLM-5.2 48,2, Opus 4.8 59,9
- Auch die unabhängigen Ausführungen von ArtificialAnalysis bewerten GLM-5.2 als starkes Open-Weights-Modell
- Intelligence Index v4.1: 51 Punkte
- Höher als MiniMax-M3 mit 44, DeepSeek V4 Pro mit 44 und Kimi K2.6 mit 43
- TerminalBench v2.1 liegt bei 78 %, verwendet aber ein anderes Harness als die 81 bzw. 82,7 der Modellkarte
- Die Output-Token pro Aufgabe liegen mit etwa 43k über den 26k von GLM-5.1
- Der Verlauf in Benchmarks ähnelt dem praktischen Test
- GLM-5.2 gehört unter den Open-Weights-Modellen zur Spitzengruppe und ist bei Reasoning teilweise konkurrenzfähig
- Opus liegt in vielen Coding- und Agenten-Benchmarks vorn
Externe Reaktionen
- Simon Willison bezeichnete GLM-5.2 als „wahrscheinlich das leistungsfähigste rein textbasierte Open-Weights-LLM“
- In seinem SVG-Test erzeugte GLM-5.2 einen Pelikan auf einem Fahrrad als vollständig animierte Szene ohne defekte Teile
- Im Test mit einem Opossum auf einem Scooter war es jedoch schwächer als das frühere GLM-5.1, die Leistung ist also nicht überall gleichmäßig
- Artificial Analysis bewertet GLM-5.2 im eigenen Intelligence Index als führendes Open-Weights-Modell
- Es werde auf demselben Niveau als das günstigste Modell gesehen und liege damit an der Frontier von Kosten zu Intelligenz
- Zugleich wird es als tokenintensives Modell mit rund 43k Output-Token pro Aufgabe eingestuft
- Nathan Lambert meinte mit Blick auf das LMArena-Leaderboard, GLM-5.2 könne sogar als besserer Agent als Gemini gelten, und sprach bei einem Open Model unter MIT-Lizenz von einer „serious accomplishment“
- Er betonte zugleich, dass die führenden US-Modelle insgesamt weiterhin vorne liegen, chinesische Labore aber mit weniger Compute sehr hohe Werte erreichen
Welches Modell man wählen sollte
- GLM-5.2 ist ein Open-Weights-Modell, das starke Leistung zu einem Bruchteil der Opus-Kosten bietet
- Es eignet sich, wenn Kosten und Offenheit wichtig sind und die Aufgabe vor allem text- und logikorientiert ist
- Herunterladbare Gewichte können nicht plötzlich wie bei geschlossenen Modellen eingestellt oder eingeschränkt werden
- Opus lieferte im Test schnellere, sauberere und präzisere Ergebnisse
- Es kann visuelle Resultate direkt betrachten und verifizieren
- Es eignet sich besser für Aufgaben, bei denen Genauigkeit, Policy und visuelle Beurteilung wichtig sind und höhere Kosten tragbar sind
- GLM-5.2 ist weniger ein Ersatz für Opus als Hauptmodell als vielmehr ein günstiges, dauerhaft zugängliches starkes Zusatzmodell
1 Kommentare
Hacker-News-Kommentare
Ich verstehe wirklich nicht, warum One-Shot-Prompting so ein großes Thema ist.
Per Definition kann ein einzelner Prompt nicht die Komplexität eines Softwareprojekts abbilden. Am Ende liefert das Modell nur ein Ergebnis, indem es auf Basis des vorhandenen Codes in seinem Trainingskorpus eine Reihe von Annahmen trifft.
Ich würde viel lieber einen Coding-Agenten sehen, der sich an die Guardrails einer von Menschen geprüften Spezifikation und an Coding-Konventionen hält und dabei die Schritte einer Plan-Datei exakt befolgt. Man sollte auch verifizieren, ob die Agent-Loop bei einem vom Menschen gesetzten Ziel nicht aus den Guardrails ausbricht und bis zum Abschluss des Ziels stabil bleibt.
Außerdem ist die Fähigkeit, den Kontext des beabsichtigten Use Cases zu verstehen, in vorhandenem Code Bugs oder mögliche Performance-Verbesserungen zu finden und Refactorings vorzuschlagen, ein deutlich wertvollerer Maßstab.
Es ist weniger ein Benchmark dafür, ob die Ausgabe zur Eingabe passt, sondern eher dafür, ob das Ergebnis in sich konsistent ist. Bei einem Spiel würde man etwa prüfen, ob es endet, wenn man das Ziel erreicht, ob man stirbt, wenn man Stacheln berührt, und ob beim Bewegen keine seltsamen Randfälle auftreten.
Trotzdem hätte man dieselbe Laufzeitumgebung verwenden und den Versuch mehrfach wiederholen sollen, um auch die Streuung der Ergebnisse zu sehen.
Früher habe ich mich über Ingenieure lustig gemacht, die ein Framework-README mit einem leeren Projekt durchgespielt und dann gesagt haben: „Dieses Framework ist perfekt für unsere 10 Jahre alte Produktions-App.“ Greenfield-Denken ist die Lösung für jedes Problem und zugleich das Problem jeder Lösung.
One-Shot-Fähigkeit ist ebenfalls eine wichtige Metrik für die Selbsteinschätzung und sollte gemessen werden, aber an einer bereits etablierten großen Codebasis.
Claude Code und Opus haben so viel Aufmerksamkeit bekommen, weil die Laufzeitumgebung besser geworden ist und sie dadurch viele Fehler selbst korrigieren können, ohne Benutzereingaben zu brauchen. Langfristig werden die größten Verbesserungen wohl bei Autonomie über mehrere Stunden und bei Selbstkorrektur entstehen.
Mit ein paar Input-Tokens Millionen von Tokens zu erzeugen, vermittelt aus meiner Sicht nicht besonders viel Bedeutung.
Um bessere Modelle zu bewerten, muss man der Aufgabe einfach mehr Anforderungen hinzufügen. Auch wenn das kein realistischer Use Case ist, halte ich es für eine nützliche Methode.
Natürlich kann ein Softwareingenieur mit Steuerung durch den Menschen deutlich bessere Ergebnisse aus dem Modell herausholen. Je nach Ingenieur kann es aber auch schlechter werden.
Ein einzelner One-Shot-Durchlauf nach dem Muster „Mit demselben One-Shot-Prompt direkt gegen Claude Opus 4.8 antreten: Ein 3D-Platformer von Grund auf in rohem WebGL bauen“ ist weder ein Benchmark noch repräsentativ für die reale Nutzung.
Die meisten Agenten-Anwendungen sind kollaborativ, daher sollte man Zuverlässigkeit testen, etwa ob ein Agent eine Aufgabe abschließt, ohne Testergebnisse zu erfinden, sowie Steuerbarkeit, also ob er meinen Anweisungen folgt oder stattdessen sein eigenes Ding macht.
Dieser Test zeigt, was beide Modelle leisten können, wenn man ihnen eine langwierige und technisch schwierige One-Shot-Aufgabe gibt.
Ein Format, das Zusammenarbeit, Aufgabenübergabe, Abschluss, testgetriebene Entwicklung und Steuerbarkeit bewertet, ist aus meiner Sicht ein sehr guter Test, den man künftig unbedingt ausprobieren sollte.
Wenn ich darüber nachdenke, besteht der Großteil meiner Agentenarbeit aus Unteragenten, die mit eigenen Prompts in der Hauptsitzung laufen. Auch das kann man als kurze Version vollständig autonomer Arbeit sehen.
Der Artikel behandelt so etwas auch, und das hier war nie als formaler Benchmark gedacht. Formale Benchmarks gibt es bereits mehr als genug.
Anthropic hat mir ständig 529 Overloaded zurückgeworfen, also habe ich mich gestern bei GLM 5.2 angemeldet und es ausprobiert.
Es gefällt mir, aber in xhigh von GLM 5.2 hat schon eine einzige Sitzung mit 2 Prompts 22 % meines Light-Plan-Kontingents im 5-Stunden-Reset-Fenster verbraucht.
Mit dem Ergebnis bin ich zufrieden, die Qualität ist ordentlich. Ich würde gern beide nutzen, daher wäre ein integrierter Abo-Plan schön, mit dem man Anthropic und GLM zusammen verwenden kann.
Mein Eindruck nach einigen Projekten mit GLM 5.2 ist, dass es ziemlich lange dauert, bis es überhaupt mit dem Schreiben von Code beginnt, und dass es definitiv kein schnelles Modell ist.
In der Erkundungs- und Planungsphase geht es oft auf Abwege, korrigiert sich später aber wieder, und leicht zu steuern ist es nicht. Es halluziniert nämlich Inhalte, an die es sich später selbst nicht hält. Trotzdem ist die Ausgabequalität ziemlich gut.
Ich habe zum Beispiel das Rendering in einer Swift+Zig-Codebasis optimiert, bin aber bei 5.000 Dateneinträgen steckengeblieben. GLM 5.2 verbrachte 20 Minuten damit, einen Benchmark zu erstellen und Daten zu extrahieren, und ich war so frustriert, dass ich den Zugriff auf alle Tools außer dem Editor gesperrt habe und weggegangen bin. Als ich etwa 30 Minuten später zurückkam, hatte es auf Basis des bereits erstellten Benchmarks und einiger „Schlussfolgerungen“ drei Bottlenecks optimiert und außerdem gesagt, dass es mehr Daten brauche, da es seinen Verdacht nicht verifizieren könne.
Die Implementierung funktionierte gut und war idiomatisch und nicht invasiv. Ich würde sogar sagen, sie war idiomatischer als das Ergebnis, das GPT 5.5 im selben Repository erzeugt hatte. Ich würde GLM gern öfter verwenden, aber GPT erledigt dieselbe Anfrage normalerweise fünfmal schneller.
Wegen GLM 5.2 richte ich nun ein Setup ein, in dem mehrere Instanzen parallel in isolierten Containern und JJ-Workspaces laufen.
Es ging darum, den Linksklick in der macOS-Menüleiste abzufangen und zu bewirken, dass Ctrl-Klick oder Rechtsklick das Menü wie ein normaler Linksklick öffnen, allerdings nur unter bestimmten Bedingungen.
Mitten in der Problemlösungssitzung habe ich das Modell auf GLM-5.2 umgestellt, ohne erneut zu prompten, also mitten im laufenden Reasoning, und ein paar Minuten später war das Problem behoben. Das lief über die abonnementsbasierte Zuteilung von OpenCode Go, und bei solchen Problemen hätte der Opus-Verbrauch leicht das komplette aktuelle 5-Stunden-Fenster oder sogar das Wochenlimit aufbrauchen können.
Wenn man sieht, dass das Modell vom Kurs abkommt oder etwas entdeckt, das ich ihm nicht gesagt habe, kann ich es anhalten und korrigieren. Oder ich kann nachvollziehen, warum es diese Wahl getroffen hat, und muss mir später weniger Fragen stellen.
Entspricht auch meiner Erfahrung. Ich nutze es auf Pi, und es ist zwar klug und die Ausgabe ist auch gut, aber der Weg dorthin ist nicht effizient
Dort steht: „GLM-5.2 konnte keine Bilder lesen, daher entstand hier das Problem. Es ist nicht multimodal. Deshalb habe ich statt Screenshots einen Trick verwendet und ein Skript geschrieben, das rohe Pixeldaten liest und prüft, ob die Farben ungefähr wie erwartet herauskommen“ — aber die bessere Methode wäre, https://github.com/openbmb/MiniCPM-V zu verwenden
Wenn man wirklich will, kann man Bilder auch an Opus übergeben, und trotzdem dürfte man noch Kosten sparen
Ich habe mich bei Ollama angemeldet, um mit Open-Source-Modellen zu experimentieren
In den letzten drei Monaten war es eher ein ständiges Ausprobieren und Testen, aber GLM ist zusammen mit Claude das erste Modell, das ich täglich für echte Programmierarbeit nutze. Es ist ziemlich gut, so gut, dass ich mein tägliches Ollama-Limit komplett ausschöpfe
GLM verbraucht weniger Tokens und macht auch weniger Tool-Aufrufe, braucht für die Fertigstellung aber mehr als doppelt so lange
Wenn diese Zeit nicht auf das Modellverhalten selbst zurückgeht, frage ich mich, wo sie verbraucht wird
Sind einzelne Tool-Aufrufe komplexer und dauern deshalb länger, oder rechnet das Modell pro Token einfach mehr, sodass die Tokens pro Sekunde niedriger sind?
Dazu kommt, dass einige Open-Weight-Modelle wie GLM 5.2 oder DeepSeek v4 Pro bei der Token-Erzeugung deutlich langsamer sind, was sich auf die wahrgenommene Latenz auswirkt. Trotzdem würde ich GLM 5.2 nicht als langsames Modell bezeichnen; in Notion ist es zum Beispiel aktuell eines der schnellsten Modelle
Eine andere Möglichkeit ist, dass Opus einen Ansatz wie Mixture of Experts verwendet und der Teil des Modells, der auf einmal in den Speicher geladen wird, kleiner sein könnte als bei GLM
Bei GLM 5.2 gibt es ein großes Problem, das sinnvollen Erfolg begrenzt: der Wert eines Coding-Abos
Rein nach API-Preisen schlägt GLM 5.2 die Konkurrenz. Aber API-Abrechnung für Coding-Arbeit nutzen im Grunde nur Großunternehmen, und bei ihnen verschwinden stark subventionierte Abo-Produkte zunehmend
Gleichzeitig werden solche Unternehmen ihre Mitarbeiter keine chinesischen APIs verwenden lassen
Für Einzelpersonen und kleine Teams ist das Coding-Abo von Z.ai schwächer als das von Anthropic und OpenAI. Vielleicht bekommt man eine ähnliche Nutzung wie bei Claude, aber Codex bietet für das gezahlte Geld eindeutig mehr Nutzung
Man kann darüber streiten, wie nah Z.ai an GPT5.5 und Opus 4.8 herangekommen ist, aber in einer Welt, in der alles gleich viel kostet und man frei wählen kann, würde ich GLM nicht auswählen
Daher ist die entscheidende Frage, wie gut das Angebot von Z.ai mit GLM 5.3 oder 6 wird und wie stark OpenAI und Anthropic ihre aktuellen Produkte in naher Zukunft einschränken werden
Für solche Unternehmen hat es einen unmittelbaren Wert, Infrastruktur rund um KI aufzubauen, die ihnen nicht jederzeit weggenommen werden kann. Andere Länder außerhalb Europas sind preissensibler und haben auch nicht dieselbe Angst davor, Beziehungen zu chinesischen Firmen einzugehen
Wenn gleichzeitig gilt, dass „diese Unternehmen ihre Mitarbeiter keine chinesischen APIs verwenden lassen“, frage ich mich, auf wen Amazon Bedrock mit GLM eigentlich abzielt
Einzelpersonen würden wahrscheinlich günstigere US-Anbieter wie DeepInfra wählen. Der Cache-Input von GLM kostet $0.18 pro 1 Million Tokens, bei Opus sind es $0.50. Fireworks AI ist ebenfalls eine Option
Mitarbeiter und Studierende, die sich daran gewöhnt haben, mit 20- oder 100-Dollar-Plänen beim Programmieren Tokens im Wert von Tausenden Dollar zu verbrauchen, werden auf Unternehmensausgaben drängen
Ein konkurrenzfähiges chinesisches Modell wird diese Unternehmensausgaben wohl nicht ersetzen, aber offenere Modelle, die in den USA oder der EU gehostet werden, könnten das tun
Die Existenz von GLM 5.2 setzt dem Preis, den OpenAI und Anthropic für API-Zugang verlangen können, eine Obergrenze
Meine Vermutung ist, dass die meisten Aufgaben über Coding-Pläne laufen
Allerdings nervt es, dass die Pläne neben Nutzungslimits auch noch zu restriktiv sind. Verständlich, aber unpraktisch. In der Praxis sind eigentlich nur Anthropic und vielleicht Google wirklich streng
Anthropic hat mit einer Richtlinie Angst gemacht, nach der später zu API-Tarifen abgerechnet werden kann, wenn die Nutzung aus ihrer Sicht nicht den Nutzungsbedingungen entspricht. Vielleicht ist das unbegründete Sorge, aber es fühlt sich so an, als könnten sie das tatsächlich tun, und deshalb meide ich sie
Dort war die Infrastruktur jedoch offensichtlich überlastet, sodass 100 % der 5.2-Chat-Anfragen in einem Timeout endeten. Wenn die Infrastruktur die Modellleistung einholt, probiere ich es später noch einmal und kann erst dann beurteilen, ob sich ein Abo lohnt
Ich war heute überrascht, dass GLM-5.2 bei ästhetischem Empfinden und UI-Arbeit viel besser war als GPT-5.5
Ich werde meine Claude/Codex-Konfiguration über Conductor vorerst beibehalten, aber wegen dieses Modells habe ich OpenCode eingerichtet, die Desktop-App heruntergeladen und den Großteil meiner Arbeit heute dort erledigt
Wenn ich Sätze lese wie „GLM-5.2 war deutlich günstiger. Opus war in der halben Zeit fertig und lieferte ein saubereres Spiel“, merke ich sofort diesen LLM-haften Stil
Es wirkt, als würden alle Modelle auf diese Schreibweise konvergieren, und selbst wenn die Leistung besser wird, ändert sich daran kaum etwas
Die Branche des technischen Schreibens steckt derzeit in einer schweren Krise. Unternehmen verlangen in kürzerer Zeit mehr Arbeit, während die Qualität deutlich sinkt, sodass im Alltag immer weniger Zeit bleibt, die sprachliche Qualität von Texten zu überarbeiten.
Wir arbeiten gerade an vorderster Front dieses Wandels und sind deshalb am stärksten betroffen, aber zugleich ist es anregend und zugleich sehr frustrierend, dass wir die Veränderungen als Erste ausprobieren können.