Саме цього нам і бракувало: зробили Claude Code багатокористувацьким

Тепер можна працювати з іншими людьми в одному терміналі, а також об’єднувати свої екземпляри Claude, щоб вони могли спілкуватися один з одним.

Затестити 🚬

Тим часом у Claude Code з’явилася нова команда: /checkup

Запускайте /checkup, щоб:

> Очистити невикористовувані skills/MCP-сервери/плагіни та звільнити контекст.
> Видалити дублювання між вашим локальним CLAUDE.md і версією CLAUDE.md у репозиторії.
> Розбити кореневий CLAUDE.md на вкладені CLAUDE.md і skills.
> Вимкнути повільні hooks.
> Оновити Claude Code до останньої версії.
> Увімкнути режим Auto за замовчуванням.
> Попередньо схвалити часто відхилювані команди лише для читання.
…а також виконати кілька інших корисних дій.

Перед внесенням будь-яких змін /checkup запросить ваше підтвердження. 👍

Ось що сталося після запуску /checkup:

Ось сценарій — можливо, комусь зайде: Claude Fable 5, який оркеструє Grok 4.5 ☕️

Усе, що потрібно, — це безплатний плагін для Claude Code, який робить Grok виконавцем за замовчуванням. Fable пише специфікації та перевіряє кожен диф, а Grok 4.5 займається написанням коду через Grok CLI.

- Grok бере на себе основний обсяг кодингу, а Fable відповідає за архітектурні рішення та контроль якості.
- Кожен диф автоматично проходить крос-перевірку різними моделями — без додаткових витрат.
- Якщо специфікації незалежні одна від одної, їх виконують паралельно окремі агенти.

Автор тестував цей підхід кілька днів, і найбільше вразило те, що Fable принципово не пише код. Він формує специфікації, надсилає їх виконавцю, оцінює отриманий результат і на цьому його завдання закінчується.

Налаштування:

1. claude plugin marketplace add DannyMac180/fable-advisor && claude plugin install fable-advisor
2. Установіть Grok CLI з http://x.ai/cli, потім виконайте grok login.
3. Виконайте команду /model fable.

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

NVIDIA, можливо, знайшла головний компроміс сучасних LLM

При роботі з будь‑яким LLM доводиться вибирати між швидкістю та якістю. Авторегресійні моделі типу GPT забезпечують високу якість, але працюють повільно, бо генерують по одному токену за раз.

Диффузійні моделі діють навпаки. Вони генерують цілі блоки паралельно і тому працюють швидше, проте до сьогодні за цю швидкість доводилося платити якістю.

Саме цю проблему спробували вирішити дослідники NVIDIA.

Вони взяли 30 B‑модель і розділили її на дві частини, щоб генерувати токени паралельно, а не по одному. Так з’явилася Nemotron‑Labs‑TwoTower — диффузійна мовна модель від NVIDIA Research, адаптована на базі Nemotron‑3‑Nano‑30B‑A3B.

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

Диффузійна LLM починає з блоку замаскованих токенів і розкриває їх за кілька проходів. На кожному проході вона читає весь вже згенерований текст і одночасно передбачає замасковані токени в поточному блоці. Виходить, що одна й та сама мережа одночасно виконує дві зовсім різні задачі. Вона повинна розуміти вже існуючий контекст і при цьому передбачати токени, яких ще немає.

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

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

1. Context Tower — заморожена частина моделі, яка читає весь вже згенерований текст точно так само, як це робила вихідна модель. Її більше не навчають, тому інтелектуальні здібності моделі повністю зберігаються.
2. Denoiser Tower — навчальна частина моделі, яка паралельно генерує кожен новий блок токенів. Щоб не втрачати контекст, вона постійно використовує cross‑attention до Context Tower.

Найцікавіше — як взаємодіють ці дві вежі. Вони з’єднані послойно: п’ятий шар Denoiser Tower взаємодіє з п’ятим шаром Context Tower, шостий — з шостим і так далі. Завдяки цьому Denoiser отримує доступ до всього багаторівневого представлення контексту базової моделі, а не лише до її фінального прихованого представлення.

Результати:
> У 2,42 рази вища пропускна здатність генерації
> Зберігається 98,7 % якості вихідної моделі
> Архітектура побудована на базі гібридної 30 B‑моделі Mamba‑Transformer MoE
> Для навчання використано всього близько 2,1 трлн токенів — лише частину від 25 трлн токенів, використаних при переднавчанні вихідної моделі

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

Тому для будь‑яких систем, чутливих до затримок, це підхід, який однозначно варто вивчити. Більше не обов’язково вибирати між моделлю, якій ви довіряєте, і потрібною швидкістю.

Ваги, код і методика навчання опубліковані у відкритому доступі.

Стаття: https://arxiv.org/pdf/2606.26493

Лол: Claude Fable 5 знову продовжили ще на тиждень.

Дякую, OpenAI. 🤣