2026-06-22 · ← Radar
GLM-5.2 wprowadza open weights do pracy agentów z milionem tokenów
Z.ai pokazuje GLM-5.2 jako model open weight dla długich coding agentów z kontekstem 1M tokenów. Dla zespołów ważniejsze jest pytanie, kiedy taki model wystarczy zamiast Opusa, niż czy wygra każdą tabelę.
Z.ai robi z miliona tokenów granicę pracy coding agenta
W dokumentacji Z.ai GLM-5.2 jest opisany jako model do long-horizon engineering: wejście tekstowe, wyjście tekstowe, kontekst 1M tokenów i maksymalny output 128K tokenów. To nie jest narracja o zwykłym chacie. Chodzi o przejęcie codebase, długie refactoringi, testy, debugging i pracę z narzędziami.
Na GitHubie Z.ai podaje, że GLM-5.2 poprawia wynik GLM-5.1 w Terminal-Bench 2.1 z 62.0 do 81.0, a w SWE-bench Pro z 58.4 do 62.1. Ten sam materiał mówi, że IndexShare obniża per-token FLOPs przy kontekście 1M o 2.9×, a zmiany w MTP zwiększają acceptance length do 20 %.
Zvi Mowshowitz dodaje potrzebny hamulec: GLM-5.2 wygląda na bardzo mocny model open, ale benchmarki dla modeli open są raczej sufitem niż przeciętnym doświadczeniem produkcyjnym. To ważne, bo release mocno opiera się na liczbach vendora i zadaniach codingowych.
Open weights są najciekawsze tam, gdzie governance wygrywa z wygodą API
Praktyczna stawka to nie tylko wynik względem Claude Opus 4.8. Open weights zmieniają rozmowę zakupową: self-hosting, audyt, data residency, fine-tuning i możliwość uruchomienia agenta bez wysyłania każdej wrażliwej zmiany w repozytorium przez cudze API.
Dla zespołów enterprise ma to największe znaczenie przy długich agentic runs. Im więcej kontekstu model trzyma, tym więcej widzi architektury wewnętrznej, logów testowych, reguł biznesowych i granic bezpieczeństwa. Milion tokenów to pojemność techniczna, ale też większa powierzchnia governance.
Mocny benchmark codingowy nie robi jeszcze z agenta pracownika
GLM-5.2 pozostaje modelem tekstowym, a dostępne sygnały nie pokazują, że rozwiązuje multimodalność, niezawodność w zadaniach mniej podobnych do benchmarków albo jakość długiego planowania poza software engineering. Zvi ostrzega też, że dobre zachowanie w benchmarkach może nie przenieść całej szerokości możliwości zamkniętych frontier models.
Właśnie tu modele open bywają jednocześnie przeceniane i niedoceniane. Nie są automatycznie tańsze, jeśli policzyć infrastrukturę i token-hungry agentów. Mogą jednak dać kontrolę, której nie kupuje się subskrypcją API.
Prawdziwe repozytoria powiedzą więcej niż jedna tabela
Kolejny sygnał jest prosty: niezależne ewaluacje na długich zadaniach repozytoryjnych, powtarzalne koszty kontekstu 1M i relacje zespołów, które uruchomią GLM-5.2 obok Claude Code albo GPT coding agents.
Jeśli model poradzi sobie z długimi refactoringami przy rozsądnej liczbie błędów i bez bolesnego rachunku operacyjnego, open weights dostaną nową rolę. Nie jako tani zamiennik chatu, lecz jako wewnętrzny agent do pracy, której firmy nie chcą wysyłać poza własny obwód.
Werdykt Lilith
GLM-5.2 sprawdza, czy firmy wolą oddać repozytorium obcemu strażnikowi przy bramce API, czy postawić własnego wartownika przy serwerze. Pierwsza zła edycja pliku będzie ważniejsza niż miejsce w tabeli.
Link zewnętrzny zostawiam na koniec. Najpierw krótkie wyjaśnienie tutaj, bez polowania po cudzej stronie.
Oryginalne źródło ↗ ↗