Режим /chat в Z.ai — як працює та коли використовувати (2026)

Режим /chat у Z.ai — це базовий інтерфейс для швидких, інтерактивних розмов з моделями GLM-5 та GLM-5.2. Він забезпечує миттєві відповіді без додаткового overhead від інструментів чи планування.

Спойлер: Chat — це lightweight completions з підтримкою історії, system prompt та streaming, ідеальний для RAG, чат-ботів та генерації тексту, на відміну від Agent mode з autonomous tool-use. У червні 2026 вийшов GLM-5.2 з контекстом 1M токенів і coding-first позиціонуванням — ключові зміни описані нижче.

📚 Зміст статті

• 🆕 GLM-5.2: що змінилось у червні 2026
• 📌 Що відбувається всередині chat-mode (LLM inference pipeline)
• 📌 Управління контекстом та історією
• 📌 Підтримка системних інструкцій
• 📌 Обмеження chat-режиму
• 📌 Приклади use-cases (чат-бот, RAG, генерація тексту)
• 📌 Порівняння з ChatGPT та Claude Chat
• ❓ Часті питання (FAQ)
• ✅ Висновки

Детальний огляд платформи Z.ai (архітектура, Chat vs Agent): тут

🆕 GLM-5.2: що змінилось у червні 2026

13 червня 2026 Z.ai випустив GLM-5.2 — coding-first оновлення з 1M-токенним контекстом. Якщо ви читали цю статтю раніше, саме цей розділ містить найбільш актуальні зміни.

Стаття спочатку описувала GLM-5 (лютий 2026). За чотири місяці вийшли GLM-5.1 (березень) і GLM-5.2 (13 червня). Ось що принципово змінилось:

📊 Незалежні бенчмарки GLM-5.2

На відміну від GLM-5, який запускався без опублікованих бенчмарків, для GLM-5.2 з'явились незалежні результати:

• SWE-bench Pro: 62.1% — проти 58.6% у GPT-5.5, 2-ге місце серед coding-моделей на Code Arena leaderboard (Artificial Analysis, червень 2026)
• GPQA Diamond: 89.5% — graduate-level reasoning (Requesty, червень 2026)
• Intelligence Index: 51.1 — загальна здатність (Artificial Analysis)
• Terminal-Bench: близько до Claude Opus 4.8 за результатами першого тижня після релізу

⚠️ Важлива примітка: самостійні бенчмарки GLM-5.2 ще нечисленні — компанія не публікувала таблицю результатів на день релізу. Трактуйте цифри GLM-5.1 як перевірену нижню межу, а GLM-5.2 — як оновлення з очікуваним приростом, підтвердженим першими незалежними тестами.

🛠️ GLM Coding Plan: новий спосіб доступу

З GLM-5.1 Z.ai запустила окрему підписку для coding-інструментів — GLM Coding Plan. GLM-5.2 доступний через неї з дня релізу:

Підтримувані coding-агенти з першого дня: Claude Code, Cline, Roo Code, Goose, OpenCode, Crush, OpenClaw, Kilo Code — через OpenAI-сумісний або Anthropic Messages API endpoint. По суті: config-level swap без змін у коді.

⚠️ Ключове обмеження GLM-5.2: text-only

GLM-5.2 — виключно текстова модель. Немає підтримки зображень, аудіо, відео та PDF-скріншотів. Мультимодальність залишається в окремій закритій моделі GLM-5V. Якщо ваш workflow включає діаграми, скріншоти або PDF — GLM-5.2 не підходить без додаткового preprocessing.

💡 Якщо ви читали цю статтю раніше: скрізь де написано «200K токенів» — для GLM-5.2 актуальна цифра 1M токенів. Це змінює стратегію управління контекстом: ручне скорочення історії стає критичним значно рідше.

🎯 Що відбувається всередині chat-mode (LLM inference pipeline)

Chat-mode виконує роль lightweight інтерфейсу для швидкого отримання відповідей: модель працює в режимі прямого decode без накладних витрат на агентну логіку чи оркестрацію інструментів.

Детальний розбір inference-пайплайну в chat-режимі (GLM-5 / GLM-5.2):

1. Підготовка вхідних даних: клієнт надсилає масив messages (role: system/user/assistant). Системний промпт (якщо є) стає першим елементом. Вся історія розмови включається в запит без автоматичного скорочення чи summarization.
2. Токенізація та формування контексту: токенайзер перетворює текст у послідовність токенів (BPE-подібний). Контекст обмежується 200 000 токенів у GLM-5 / 1 000 000 токенів у GLM-5.2 — при перевищенні клієнт повинен самостійно обрізати історію. Модель отримує повний контекст без попередньої компресії.
3. Проходження через модель:
   • MoE-шари: 256 експертів (GLM-5: 744B params), активація top-8 (~40B active параметрів на токен, sparsity ~5.9%).
   • DeepSeek Sparse Attention (DSA): замінює класичну attention, динамічно виділяє увагу тільки на релевантні токени, знижуючи обчислювальну складність з O(n²) до ближчої до лінійної на довгих послідовностях. Критично для 1M-контексту GLM-5.2.
4. Thinking mode (якщо увімкнено): У GLM-5 — параметр thinking: {"type": "enabled"}. У GLM-5.2 — два рівні: High (стандартні задачі) і Max (складні багатокрокові). Interleaved thinking генерує внутрішні роздуми між токенами decode, покращуючи якість на складних запитах, але збільшуючи кількість токенів та latency на 20–50%.
5. Генерація: autoregressive decode з використанням заданих параметрів (temperature, top_p, max_tokens тощо). Підтримуються як повна відповідь, так і streaming (stream: true) — токени надсилаються клієнту по мірі генерації. GLM-5.2 підтримує max output до 128K токенів (GLM-5 — значно менше).
6. Завершення: відповідь повертається як повідомлення з role: "assistant". Немає автоматичного продовження чи перевірки — процес закінчується після генерації.

Офіційна документація /chat/completions | Thinking mode в chat-режимі

Відмінності пайплайну від Agent mode

У Agent mode після кожного кроку decode модель може:

• Прийняти рішення про виклик інструменту (tool_calls)
• Виконати планування та self-check
• Ітерувати (plan → execute → observe → revise)

У chat-mode такого циклу немає — відповідь генерується за один прохід (single forward pass + decode), без зовнішнього loop'у чи оркестрації.

Технічні trade-offs

Простота пайплайну забезпечує:

• Мінімальний latency на першу відповідь (~0.5–2 секунди на коротких запитах)
• Низьке споживання ресурсів порівняно з Agent mode
• Передбачувану поведінку без несподіваних викликів інструментів

Водночас це обмежує можливості: модель не може самостійно коригувати помилки, перевіряти факти через інструменти чи виконувати багатоступеневі завдання.

Висновок: Inference-пайплайн chat-режиму — це класичний одноразовий completions-процес з MoE + DSA та опціональним interleaved thinking (два рівні у GLM-5.2), оптимізований для швидкості та простоти інтерактивних діалогів без елементів автономної агентної логіки.

Управління контекстом та історією

Механізм multi-turn у chat-режимі — це проста передача повної історії в кожному запиті, без вбудованого state management чи автоматичного управління пам'яттю на сервері. З GLM-5.2 і 1M-токенним вікном ручне скорочення потрібне значно рідше — але не зникає повністю.

Детальний опис роботи з контекстом у chat-режимі (GLM-5 / GLM-5.2):

• Формування контексту: клієнтський код (наприклад, через OpenAI-сумісний SDK) передає масив messages у запиті до /v4/chat/completions. Порядок повідомлень важливий: system (перше, якщо є), потім чергування user/assistant з початку сесії. Модель не зберігає стан між запитами — кожен запит незалежний і містить всю потрібну історію.
• Обробка на стороні моделі: модель отримує повний контекст і пропускає його через MoE-шари з DeepSeek Sparse Attention (DSA). DSA забезпечує стабільну якість уваги навіть на максимальній довжині без значної деградації needle-in-haystack. Контекст не кешується сервером у базовому chat-режимі (cached input доступний окремо).
• Обмеження довжини:
  • GLM-5: 200 000 токенів — при перевищенні запит відхиляється (400 Bad Request або 413 Payload Too Large)
  • GLM-5.2: 1 000 000 токенів — практично цілий репозиторій в одному запиті без чанкінгу
  В обох випадках модель не обрізає контекст автоматично — це відповідальність клієнта.
• Керування історією клієнтом: для сесій що перевищують ліміт необхідно:
  • Видаляти найстаріші повідомлення при наближенні до ліміту
  • Використовувати summarization попередньої історії (попросити модель стиснути попередні N повідомлень у 1–2 абзаци)
  • Застосовувати context caching якщо API підтримує: GLM-5 — cached input $0.20/млн; GLM-5.2 — $0.26/млн

Офіційна документація /chat/completions (messages та контекст) | Context caching у Z.ai API

Практичні наслідки та trade-offs

Переваги підходу:

• Повна прозорість — клієнт точно знає, що саме бачить модель
• Відсутність несподіваних скорочень історії сервером
• Ефективність DSA на довгих контекстах без втрати якості
• З GLM-5.2: 1M токенів — весь репозиторій, велика документація або тривала сесія без ручного обрізання

Недоліки:

• Зростання витрат токенів та latency при довгій історії (кожен запит повторно обробляє весь контекст)
• Необхідність ручного управління на клієнті, що ускладнює реалізацію для простих застосунків
• Відсутність автоматичного state management (на відміну від деяких чат-платформ з вбудованим кешем сесій)
• З GLM-5.2 на 1M токенах: вища ціна за токен ($1.40/млн input проти $1.00 у GLM-5) і потенційно повільніша генерація на максимальному контексті

У production-сценаріях для довгих сесій рекомендовано:

• Для GLM-5.2: якщо сесія вміщується в 1M — передавати повну історію, використовувати context caching ($0.26/млн) для повторного контексту
• Для GLM-5 або при перевищенні ліміту: стискати історію через окремий запит до моделі
• Використовувати векторні бази даних для RAG замість повного контексту (ефективніше за будь-якого ліміту)
• Переходити на Agent mode або спеціалізовані ендпоінти з кешуванням для складних multi-turn взаємодій

Висновок: Управління контекстом у chat-режимі Z.ai базується на передачі повної історії в кожному запиті. GLM-5.2 з 1M-токенним вікном суттєво знижує потребу в ручному скороченні для більшості реальних сесій, але не усуває її повністю — і збільшує вартість токенів та latency на максимальному контексті.

Підтримка системних інструкцій

Системна інструкція — це єдиний стабільний елемент контексту, який не змінюється при додаванні нових повідомлень, забезпечуючи послідовність поведінки моделі протягом multi-turn взаємодії.

Технічна реалізація в API Z.ai (OpenAI-сумісний /v4/chat/completions):

• System prompt передається як перший елемент масиву messages: {"role": "system", "content": "..."}.
• Він включається в контекст один раз на початку і залишається незмінним для всіх наступних повідомлень у цій сесії (клієнт не повинен повторно надсилати його в кожному запиті, якщо не хоче змінити інструкцію).
• Якщо system prompt відсутній — модель використовує дефолтну поведінку (нейтральний, корисний асистент без спеціалізації).
• System prompt обробляється як звичайна частина контексту: токенізація → проходження через MoE + DSA → вплив на attention та decode. Його довжина враховується в загальний ліміт (200K для GLM-5, 1M для GLM-5.2).
• Зміна system prompt можлива лише при новому запиті з новим масивом messages (тобто при перезапуску сесії або явній заміні).

Офіційна документація messages та system role

Практичні аспекти та приклади

System prompt дозволяє точно налаштувати модель під конкретне завдання. Типові сценарії використання:

• Стилістичні обмеження: {"role": "system", "content": "Відповідай тільки українською мовою. Уникай нецензурної лексики та політики."}
• Рольова спеціалізація: {"role": "system", "content": "Ти — старший backend-розробник з 15-річним досвідом. Аналізуй код критично, вказуй на потенційні вразливості та пропонуй оптимізації."}
• Формат відповідей: {"role": "system", "content": "Відповідай структуровано: 1. Короткий висновок 2. Покроковий аналіз 3. Рекомендації. Використовуй markdown."}
• Обмеження галюцинацій: {"role": "system", "content": "Якщо не впевнений у факті — скажи 'не маю достатньо даних' замість вигадування."}

Обмеження та trade-offs

• System prompt фіксований протягом сесії — для динамічної зміни поведінки потрібен новий запит з новим промптом.
• Довгий system prompt зменшує доступний простір для історії розмови. З GLM-5.2 (1M ліміт) це менш критично, ніж з GLM-5 (200K), але рекомендований розмір промпту — 200–500 токенів.
• Модель може «забувати» або ігнорувати частину промпту при дуже довгому контексті (DSA допомагає, але не усуває проблему повністю).
• Немає вбудованого multi-system prompt чи conditional instructions — все обмежується одним рядком content.

У production-рекомендаціях: тримайте system prompt стислим (200–500 токенів), щоб максимально використати контекст для корисного вмісту. Для складних сценаріїв з динамічними інструкціями — Agent mode або кілька окремих сесій.

Висновок: Підтримка системних інструкцій у chat-режимі Z.ai — стабільний і передбачуваний механізм через role: "system", що зберігається протягом усієї сесії. Механіка однакова для GLM-5 і GLM-5.2; різниця лише в тому, що з 1M контекстом довгий промпт «з'їдає» відносно меншу частку доступного простору.

Обмеження chat-режиму

Chat-режим реалізує прямий inference без зовнішнього loop'у, тому виключає будь-які форми автономного виконання завдань — що відрізняє його від Agent mode.

Основні технічні та функціональні обмеження chat-режиму (GLM-5 / GLM-5.2):

• Відсутність автоматичного tool-calling: модель не може самостійно вирішувати про виклик функцій чи інструментів. Для використання інструментів потрібно явно передавати tools та обробляти відповідь клієнтом (ручний цикл).
• Одноразовий характер генерації: після видачі відповіді процес завершується. Немає вбудованого механізму ітерації (plan → execute → observe → revise). Модель не аналізує власну відповідь, не перевіряє факти та не коригує помилки без нового запиту.
• Text-only у GLM-5.2: GLM-5.2 приймає і генерує виключно текст. Немає підтримки зображень, аудіо, відео та PDF-скріншотів — мультимодальність тільки в окремій закритій моделі GLM-5V. Якщо workflow включає діаграми або скріншоти — потрібен окремий preprocessing.
• Відсутність генерації кінцевих артефактів: відповідь обмежується текстом або кодом у полі content. Немає native створення файлів (.docx, .pdf, .xlsx), сайтів чи інших deliverables — це прерогатива Agent mode.
• Обмежена дія thinking mode: interleaved thinking (High/Max у GLM-5.2) покращує якість на складних запитах, але не дає агентної автономності. Роздуми залишаються внутрішніми. Latency зростає (додає 20–50% токенів та часу), але результат — все одно одна відповідь.
• Швидкість на довгому контексті:
  • GLM-5 (200K): з 25–30 ток/с на коротких запитах до 10–15 ток/с на максимальному контексті
  • GLM-5.2 (1M): compute overhead зростає пропорційно — очікуйте нижчу швидкість на повному контексті. Streaming пом'якшує first-token latency, але не усуває проблему.
• Відсутність вбудованого state management: сесія не зберігається на сервері — кожен запит незалежний. Клієнт повинен сам передавати всю історію, що збільшує витрати токенів.
• GLM Coding Plan: квотові обмеження: при використанні GLM-5.2 через Coding Plan діють тижневі ліміти промптів (Lite: ~400/тиждень, Pro: ~2000, Max: ~8000). Для production-навантаження з великими контекстами квота може вичерпатися швидше, ніж очікується. Premium-квота: ×2 до кінця вересня 2026 (off-peak 1×).

Наслідки обмежень у реальних сценаріях

Ці обмеження проявляються в задачах, де потрібна:

• Автономна перевірка та коригування (баг-фіксинг з запуском коду — неможливо без ручного циклу)
• Multi-step виконання з інструментами (пошук → аналіз → генерація звіту — вимагає ручної обробки)
• Генерація кінцевих продуктів (звіт у .docx, таблиця в .xlsx — тільки текстовий опис)
• Обробка зображень, PDF, аудіо — text-only в GLM-5.2

Для подолання цих обмежень:

• Agent mode — для автономності та deliverables
• Власний цикл на клієнті (LangChain / LlamaIndex з tool-calling)
• GLM-5V або мультимодальна альтернатива — для зображень і PDF
• Summarization або RAG — для економії контексту при довгих сесіях

Висновок розділу: Chat-режим Z.ai обмежений одноразовим прямим inference без механізмів автономії, ітеративного виконання чи генерації артефактів. GLM-5.2 знімає обмеження контексту (1M), але додає text-only обмеження і квоти Coding Plan. Для мультимодальних задач або autonomous execution — Agent mode або GLM-5V.

Приклади use-cases (чат-бот, RAG, генерація тексту)

Chat-режим оптимізовано для задач з високою швидкістю відповіді та підтримкою контексту, де модель виступає як безпосередній генератор тексту, а не як автономний виконавець завдань.

Основні сценарії використання chat-режиму в Z.ai (GLM-5 / GLM-5.2, 2026):

• Інтерактивні чат-боти (техпідтримка, customer service, внутрішні асистенти): підтримка контексту розмови протягом кількох ходів, швидкі відповіді. Перевага — низький latency та велике контекстне вікно: GLM-5 — до 200K токенів, GLM-5.2 — до 1M, що дозволяє утримувати в пам'яті весь попередній діалог навіть для довгих сесій підтримки.
• RAG-пайплайни (Retrieval-Augmented Generation): пошук релевантних фрагментів документів → вставка в контекст → генерація відповіді. З GLM-5.2 і 1M контекстом можна вставляти значно більше витягнутих фрагментів за один запит — не треба агресивно чанкувати базу знань. Приклад: корпоративний пошук по великій документації, аналіз юридичних договорів, технічна база знань.
• Генерація тексту та контенту: статті, пости у соцмережі, email-розсилки, переклади, описи продуктів. System prompt задає стиль, тон, мову. Підходить для одноразових генерацій або коротких ітерацій. Важливо: GLM-5.2 — text-only, зображення не генерує.
• Генерація та аналіз коду (швидкий прототипінг, код-рев'ю): пояснення фрагментів коду, генерація функцій/скриптів, дебагінг. З GLM-5.2 і 1M контекстом — завантаження цілого репозиторію або кількох великих файлів за один запит без чанкінгу. Thinking mode Max — для складного аналізу архітектури або рефакторингу. GLM-5.2 доступний через Coding Plan у Claude Code, Cline, Roo Code, Goose як drop-in заміна.
• Brainstorming, пояснення концепцій, навчання: покроковий розбір складних тем, генерація ідей, рольові симуляції. Thinking mode (High/Max у GLM-5.2) покращує якість на аналітичних запитах без переходу до повноцінного агентного циклу.

Коли chat-режим є оптимальним вибором

Сценарії, де chat-режим перевершує Agent mode:

• Потрібна перша відповідь за <2 секунди (низький latency без планування)
• Запит простий або середньої складності, не вимагає зовнішніх інструментів
• Великий контекст важливий, але достатньо тексту: GLM-5.2 тягне до 1M токенів
• Бюджет обмежений — chat-режим витрачає менше токенів, ніж Agent з thinking та tool-calls; GLM-5: $1.00/$3.20, GLM-5.2: $1.40/$4.40 за млн
• Не потрібні кінцеві артефакти (файли, сайти) — достатньо тексту/коду
• Workflow без зображень, аудіо чи PDF — GLM-5.2 text-only

У production-рекомендаціях: поєднувати chat-режим з RAG (векторний пошук + вставка в контекст) або використовувати його як «перший етап» перед переходом до Agent mode для складних завдань. Для coding-агентів — GLM-5.2 через Coding Plan як бюджетна альтернатива Claude Opus з порівнянними coding-результатами на SWE-bench.

Висновок: Chat-режим Z.ai ефективний для швидких інтерактивних задач з підтримкою великого контексту та генерацією тексту/коду. GLM-5.2 особливо сильний у RAG з великими документами і код-рев'ю великих репозиторіїв завдяки 1M-токенному вікну — за ціною нижчою, ніж Claude або GPT-5.

Порівняння з ChatGPT та Claude Chat

Chat-режим Z.ai забезпечує конкурентні можливості за ціною та довгим контекстом, але поступається в швидкості, мультимодальності та глибинному розумінні неоднозначних завдань. З GLM-5.2 головна перевага — 1M токенів для репозиторіїв і великих документів за ціною $1.40/млн input.

Порівняльна таблиця ключових характеристик (червень 2026, thinking mode увімкнено де доступно):

Аналіз ключових відмінностей

Контекст та довгі сесії: GLM-5.2 тепер лідирує — 1M токенів проти 200K у Claude і 128K–200K у ChatGPT (залежно від плану). Для RAG з великими документами, аналізу цілих репозиторіїв або тривалих сесій підтримки — GLM-5.2 тепер має найбільший практичний контекст серед трьох платформ.

Швидкість та latency: ChatGPT лідирує завдяки оптимізованому inference (25–40+ ток/с). GLM-5.2 на 1M контексті — повільніший через compute overhead MoE + DSA на максимальній довжині. Якщо critical — ultra-real-time чат без великих контекстів, ChatGPT виграє.

Reasoning та якість: Claude Opus 4.6/4.8 зберігає перевагу в nuanced, неоднозначних задачах та ситуаційній обізнаності. GLM-5.2 сильний у технічному reasoning та кодуванні: SWE-bench Pro 62.1% — вище GPT-5.5 (58.6%), але нижче Claude Opus 4.8 (~66–70%). Thinking mode Max у GLM-5.2 наближає якість для складних задач.

Мультимодальність: ChatGPT і Claude мають native підтримку vision/audio. GLM-5.2 — text-only; для зображень потрібна окрема GLM-5V або інша модель. Це жорстке обмеження для workflow з PDF-скріншотами, діаграмами або аудіо.

Вартість та доступність: Z.ai залишається найдешевшим API-варіантом: GLM-5.2 у 1.2–3.5× дешевше ChatGPT і в 3.5–10× дешевше Claude на тих самих обсягах. MIT-ліцензія дозволяє self-hosting для максимальної économії. Для coding через Coding Plan ($18/міс) — суттєво дешевше ніж Claude Pro або GPT-5 API для coding-агентів.

Конкурентне середовище: У червні 2026 з'явились нові конкуренти у low-cost сегменті. DeepSeek V4 Pro ($0.44–$0.87/млн) агресивно конкурує за ціною, Gemini 3.5 Flash — за балансом ціна/можливості. GLM-5.2 вирізняється комбінацією: 1M контекст + MIT-ліцензія + конкурентний SWE-bench — жоден із прямих конкурентів не має всіх трьох разом.

Висновок: Chat-режим Z.ai у версії GLM-5.2 — найкращий вибір для long-context RAG і repo-scale код-рев'ю за ціною нижчою ніж конкуренти. Claude Chat — для максимальної точності reasoning і мультимодальних задач. ChatGPT — для швидкості і native vision/audio. Вибір залежить від пріоритетів: 1M контекст + бюджет → GLM-5.2; мультимодальність + швидкість → ChatGPT; якість reasoning → Claude.

❓ Часті питання (FAQ)

Чим відрізняється chat від agent в Z.ai?

Chat-режим забезпечує швидкі відповіді без використання інструментів та без автоматичного планування — прямий inference для інтерактивних діалогів, генерації тексту чи коду. Agent-режим підтримує автономне планування, tool-calling, multi-turn ітерації з self-correction та генерацію кінцевих артефактів (.docx, .pdf, .xlsx, сайти). Agent-режим перетворює модель на виконавця завдань, тоді як chat-режим — класичний чат-інтерфейс без агентної логіки.

Чи підтримує chat-режим thinking mode?

Так. У GLM-5 — параметр thinking: {"type": "enabled"}. У GLM-5.2 — два рівні: High (стандартні задачі) і Max (складні багатокрокові). Interleaved thinking генерує внутрішні роздуми між токенами decode, покращуючи якість reasoning. Latency та витрата токенів зростає на 20–50%, але результат залишається одноразовою відповіддю — режим не перетворюється на агентний цикл.

Яка максимальна довжина контексту в chat-режимі?

GLM-5: 200 000 токенів (підтверджено до 202 752 у тестах HLE w/Tools). GLM-5.2: 1 000 000 токенів — практично весь репозиторій без чанкінгу. В обох випадках клієнт повинен самостійно керувати масивом messages. Перевищення ліміту — помилка запиту (400/413).

Яка різниця між GLM-5 і GLM-5.2 для chat-режиму?

Три ключових відмінності: (1) контекст 200K → 1M токенів — найбільша практична зміна для RAG і великих кодових баз; (2) max output ~8K → 128K токенів — GLM-5.2 може генерувати значно довші відповіді за один запит; (3) thinking effort: enabled/disabled → High/Max. Ціна зросла: $1.00/$3.20 (GLM-5) → $1.40/$4.40 (GLM-5.2) за млн токенів. GLM-5.2 text-only — це нова явна обмеженість якої не було у GLM-5. Для доступу до GLM-5.2 через chat — потрібен GLM Coding Plan від $18/міс; безкоштовний chat.z.ai поки на GLM-5.1.

Чи підходить GLM-5.2 для мультимодальних задач?

Ні. GLM-5.2 — виключно text-only: приймає і генерує тільки текст. Зображення, аудіо, відео та PDF-скріншоти без preprocessing не підтримуються. Для мультимодальних задач: GLM-5V (окрема закрита модель Z.ai), або Claude Chat / ChatGPT з native vision. Якщо workflow включає діаграми або скріншоти — GLM-5.2 не підходить без попереднього перетворення в текст.

✅ Висновки

• 🔹 Chat-режим Z.ai реалізує стандартний completions-пайплайн без додаткових циклів планування чи оркестрації. Механіка однакова для GLM-5 і GLM-5.2 — відрізняються масштаб контексту, рівні thinking і ціна.
• 🔹 GLM-5 (лютий 2026): контекст 200K токенів, thinking enabled/disabled, $1.00/$3.20 за млн, безкоштовний chat.z.ai. Актуальний для бюджетних production-чатботів і RAG.
• 🆕 GLM-5.2 (червень 2026): контекст 1M токенів, max output 128K, thinking High/Max, $1.40/$4.40 за млн, GLM Coding Plan від $18/міс. Text-only. SWE-bench Pro 62.1% — 2-ге місце серед coding-моделей. Доступний через Claude Code, Cline, Roo Code, Goose та ін.
• 🔹 Переваги режиму: низька затримка на першу відповідь, ефективність на довгих контекстах завдяки DSA, мінімальне споживання ресурсів порівняно з Agent-режимом, MIT open weights для self-hosting.
• 🔹 Обмеження: відсутність tool-calling, ітеративного виконання, self-correction та генерації артефактів; управління контекстом повністю на клієнті; GLM-5.2 text-only (немає зображень/аудіо); квоти Coding Plan (Lite: ~400 промптів/тиждень).
• 🔹 Найкращі сценарії: інтерактивні чат-боти, long-context RAG з великими документами, repo-scale код-рев'ю (GLM-5.2), генерація тексту/коду, brainstorming — де достатньо одноразової відповіді без автономного виконання.

Головна думка: Chat-режим Z.ai — оптимальний вибір, коли пріоритет — великий контекст, низька ціна API і MIT-ліцензія без прив'язки до хмарного провайдера. GLM-5.2 з 1M токенами практично закриває задачі repo-scale RAG і код-рев'ю за ціною нижчою ніж Claude або GPT-5.4. Якщо потрібна мультимодальність — ChatGPT або Claude. Якщо потрібна максимальна точність reasoning і nuanced аналіз — Claude Opus. Якщо потрібні artifacts і autonomous execution — Agent mode Z.ai.