Swarm в Kimi K3 — это режим, где K3 работает не как один агент, а как **руководитель целой команды AI-агентов**.
Ты даёшь ей большую задачу, а K3 сама решает, как её декомпозировать, сколько агентов запустить, что выполнять параллельно и как потом собрать результаты. У каждого подагента свой отдельный контекст, поэтому они могут независимо исследовать разные части задачи и не забивать основной контекст K3.
Главное отличие Kimi — это не просто обычный `spawn 20 agents`. Такая работа поддерживается на уровне самой модели благодаря PARL — Parallel-Agent Reinforcement Learning. Во время обучения Kimi специально учили быть хорошим оркестратором: находить части задачи, которые действительно можно выполнять одновременно, правильно распределять их между агентами и сокращать критический путь выполнения.
Плюс этому помогают особенности самой K3: огромный контекст, сильная работа с длинными agentic-задачами и tool calling, а также возможность дробить рабочую память между независимыми контекстами агентов.
То есть совсем грубо:
обычная модель:
один AI → последовательно делает всю задачу
K3 Swarm:
K3 → сама строит команду → параллельно запускает агентов → проверяет результаты → при необходимости создаёт новую волну → собирает финальный ответ
По сути, K3 становится не просто разработчиком, а AI-тимлидом и планировщиком распределённых вычислений, причём навык управления этой командой у неё не только захардкожен во внешнем фреймворке, а частично обучен через PARL.
🔥1
Есть одна история из Яндекс.Такси, которую я очень люблю вспоминать, когда начинается очередной разговор в духе «а давайте сюда AI прикрутим».
Мы тогда делали диспатчер — систему, которая распределяет заказы между водителями.
На самом деле задача там сильно сложнее, чем «найти ближайшую машину».
У пассажира может быть ребенок, багаж, нужен определенный тариф, дополнительные требования. Есть водитель, который может принять заказ, а может не принять. Может доехать, а может отмениться. Пассажир тоже может отмениться. Плюс нужно не конкретному человеку сделать максимально хорошо, а оптимизировать вывоз целого района.
То есть чем больше людей в итоге реально уехало — тем лучше работает диспатчер.
И первая версия всего этого была, по сути, максимально инженерной.
Фильтры, правила, эвристики, scoring, классическая оптимизация.
Грубо говоря, много хорошо написанных
И что самое смешное — работало это очень хорошо. Быстро, дешево, понятно, предсказуемо.
Потом, конечно, появился ML.
Начали предсказывать то, что уже нельзя нормально описать руками:
— примет ли водитель заказ;
— доедет ли он до пассажира;
— сколько реально займет подача;
— какова вероятность отмены.
И эти предикты уже подмешивались в scoring, после чего обычный алгоритм принимал решение, кому отдать заказ.
Это дало еще несколько процентов к вывозу. По памяти, что-то порядка 5–7%.
На масштабе Яндекс.Такси это, естественно, огромные деньги.
Но вместе с этими процентами внезапно появляется еще один маленький Яндекс.Такси внутри Яндекс.Такси 🙂
Датасеты.
Feature pipelines.
Обучение.
Эксперименты.
Мониторинг.
Retraining.
Drift.
Постоянный tuning.
И вот тут очень хороший вопрос: а точно ли вам вообще нужен AI?
Потому что есть еще очень показательная история со Stockfish и Leela Chess Zero.
Leela — практически AI-native подход. Нейросеть находится в центре системы: оценивает позиции, ходы, вокруг нее строится поиск.
Stockfish исторически — наоборот. Максимально классический движок: search, pruning, эвристики, десятилетия оптимизации.
И когда нейросети стали реально полезными, Stockfish не переписали в Leela.
Туда добавили NNUE.
То есть взяли великолепную классическую систему и заменили нейросетью ровно тот кусок, где нейросеть оказалась лучше — evaluation.
Search остался.
Эвристики остались.
Вся эта гигантская алгоритмическая инженерия никуда не делась.
И, кстати, ровно к такому же выводу я пришел в своих трейдинг-ботах.
Я там уже много чего попробовал.
Разные модели, разные способы предсказания, разные комбинации ML с сигналами.
Но в итоге основа у меня все равно алгоритмическая.
Логика входа и выхода, риск, арбитраж, исполнение, работа со стаканом, ограничения — это обычные алгоритмы.
ML я использую в основном там, где он действительно хорошо работает:
→ CatBoost для тюнинга параметров и оценки фич;
→ иногда LSTM для конкретных временных зависимостей;
→ модели как дополнительный сигнал, а не как мозг всей системы.
И чем больше я с этим экспериментирую, тем сильнее убеждаюсь, что этот подход реально работает.
Не пытаться заставить модель принимать все решения.
А оставить детерминированную систему там, где у тебя есть понимание процесса, и использовать ML для тех частей, где есть неопределенность или слишком сложная зависимость между фичами.
Мне кажется, это вообще очень правильный паттерн для AI-разработки.
Не надо начинать с AI.
Сначала решите задачу нормально.
Если работает правило — используйте правило.
Если работает алгоритм — используйте алгоритм.
Если есть хорошая математическая оптимизация — используйте ее.
А потом найдите то место, где у вас начинается неопределенность и где prediction действительно дает дополнительную ценность.
Вот туда и ставьте модель.
Проблема текущего AI-хайпа в том, что очень часто делают наоборот: сначала берут модель, а потом начинают придумывать, какую инженерную задачу ею заменить.
Хотя зачастую лучшая AI-система — это вообще не «AI-система».
Это очень хорошая классическая система, в которую в правильном месте вставили модель.
Мы тогда делали диспатчер — систему, которая распределяет заказы между водителями.
На самом деле задача там сильно сложнее, чем «найти ближайшую машину».
У пассажира может быть ребенок, багаж, нужен определенный тариф, дополнительные требования. Есть водитель, который может принять заказ, а может не принять. Может доехать, а может отмениться. Пассажир тоже может отмениться. Плюс нужно не конкретному человеку сделать максимально хорошо, а оптимизировать вывоз целого района.
То есть чем больше людей в итоге реально уехало — тем лучше работает диспатчер.
И первая версия всего этого была, по сути, максимально инженерной.
Фильтры, правила, эвристики, scoring, классическая оптимизация.
Грубо говоря, много хорошо написанных
switch/case.И что самое смешное — работало это очень хорошо. Быстро, дешево, понятно, предсказуемо.
Потом, конечно, появился ML.
Начали предсказывать то, что уже нельзя нормально описать руками:
— примет ли водитель заказ;
— доедет ли он до пассажира;
— сколько реально займет подача;
— какова вероятность отмены.
И эти предикты уже подмешивались в scoring, после чего обычный алгоритм принимал решение, кому отдать заказ.
Это дало еще несколько процентов к вывозу. По памяти, что-то порядка 5–7%.
На масштабе Яндекс.Такси это, естественно, огромные деньги.
Но вместе с этими процентами внезапно появляется еще один маленький Яндекс.Такси внутри Яндекс.Такси 🙂
Датасеты.
Feature pipelines.
Обучение.
Эксперименты.
Мониторинг.
Retraining.
Drift.
Постоянный tuning.
И вот тут очень хороший вопрос: а точно ли вам вообще нужен AI?
Потому что есть еще очень показательная история со Stockfish и Leela Chess Zero.
Leela — практически AI-native подход. Нейросеть находится в центре системы: оценивает позиции, ходы, вокруг нее строится поиск.
Stockfish исторически — наоборот. Максимально классический движок: search, pruning, эвристики, десятилетия оптимизации.
И когда нейросети стали реально полезными, Stockfish не переписали в Leela.
Туда добавили NNUE.
То есть взяли великолепную классическую систему и заменили нейросетью ровно тот кусок, где нейросеть оказалась лучше — evaluation.
Search остался.
Эвристики остались.
Вся эта гигантская алгоритмическая инженерия никуда не делась.
И, кстати, ровно к такому же выводу я пришел в своих трейдинг-ботах.
Я там уже много чего попробовал.
Разные модели, разные способы предсказания, разные комбинации ML с сигналами.
Но в итоге основа у меня все равно алгоритмическая.
Логика входа и выхода, риск, арбитраж, исполнение, работа со стаканом, ограничения — это обычные алгоритмы.
ML я использую в основном там, где он действительно хорошо работает:
→ CatBoost для тюнинга параметров и оценки фич;
→ иногда LSTM для конкретных временных зависимостей;
→ модели как дополнительный сигнал, а не как мозг всей системы.
И чем больше я с этим экспериментирую, тем сильнее убеждаюсь, что этот подход реально работает.
Не пытаться заставить модель принимать все решения.
А оставить детерминированную систему там, где у тебя есть понимание процесса, и использовать ML для тех частей, где есть неопределенность или слишком сложная зависимость между фичами.
Мне кажется, это вообще очень правильный паттерн для AI-разработки.
Не надо начинать с AI.
Сначала решите задачу нормально.
Если работает правило — используйте правило.
Если работает алгоритм — используйте алгоритм.
Если есть хорошая математическая оптимизация — используйте ее.
А потом найдите то место, где у вас начинается неопределенность и где prediction действительно дает дополнительную ценность.
Вот туда и ставьте модель.
Проблема текущего AI-хайпа в том, что очень часто делают наоборот: сначала берут модель, а потом начинают придумывать, какую инженерную задачу ею заменить.
Хотя зачастую лучшая AI-система — это вообще не «AI-система».
Это очень хорошая классическая система, в которую в правильном месте вставили модель.
1👍20🔥5❤3💯2✍1🙏1
🔎 Бывший глава поиска Яндекса строит Google для AI-агентов
Из стелса вышел Keenable — стартап Андрея Стыскина, бывшего главы поиска и рекламы Яндекса и директора Web Infrastructure в Amazon AGI.
Вместе с Matthias Petri, который строил web grounding для Alexa, они сразу подняли $26 млн от Accel и Conviction.
Keenable — не очередная обертка над Google или Bing. Компания заявляет собственный crawler, индекс и ranking stack, в котором уже более 100 млрд документов.
Обычный поиск создавался для человека:
один запрос → десять ссылок → один клик.
Агент ищет иначе. Он делает десятки запросов подряд и параллельно, уточняет их по найденной информации, читает целые страницы и не интересуется CTR, рекламой и красивыми превью.
Ему нужны полнота, long tail, свежесть, низкая задержка и дешевая стоимость каждого retrieval loop.
⚙️ Что есть внутри
1. Search API и MCP
Поиск плюс fetch_page_content, возвращающий очищенный Markdown.
Keenable подключается к Codex, Claude Code, Cursor, Windsurf и OpenCode.
Компания заявляет задержку менее 250 мс на p95 в US East. Artificial Analysis независимо назвал Keenable Realtime самым быстрым Search API по одному вызову — в среднем 0,34 секунды.
2. SELECT / Web Query Language
Пожалуй, самая интересная часть продукта. По сути это semantic SQL поверх интернета.
Агент может прогнать тысячи страниц через WEB_SEARCH, SEM_MATCH и SEM_EXTRACT, нормализовать данные и получить готовую таблицу с источником для каждой строки.
В публичном примере SELECT обработал 10 157 страниц за 6 минут 25 секунд и собрал 46 переходов исследователей между frontier AI-лабораториями.
То есть это уже не просто поиск ссылок, а отдельный execution engine для research.
3. Time Machine
Поиск по состоянию интернета в прошлом.
Параметр query_time перематывает не только доступный набор документов, но и ranking.
Это полезно для воспроизведения старых ответов агента, backtesting, расследований и проверки того, что вообще было известно на конкретную дату.
Полноценный Time Machine пока находится в early access.
📊 Собственный живой benchmark
Еще Keenable выпустила NEEDLE — открытый benchmark агентского поиска.
Новости обновляются каждый час, а finance, papers, long-tail и legal — ежедневно. Поэтому такой тест сложнее запомнить или найти вместе с готовым answer key.
Сейчас Keenable лидирует в собственном benchmark. Но нужна честная оговорка: тест открытый и воспроизводимый, однако создала и запускает его сама компания.
Независимо пока хорошо подтверждена скорость, но не превосходство по качеству.
💰 Сколько стоит
Без ключа дают 1 000 запросов в час.
После регистрации — 100 000 запросов каждый месяц.
Дальше — $4 за 1 000 запросов либо от $1 за 1 000 при нагрузке от 100 RPS.
⚠️ Есть нюанс
Я бы пока осторожно подключал Keenable глобально к агентам, работающим с приватным кодом.
Публичные Terms дают компании довольно широкие права на передаваемый User Content. Для enterprise здесь нужен отдельный договор, no-training/no-retention и, возможно, on-prem.
В общем, это не новый Perplexity.
Keenable пытается превратить живой интернет в дешевый и нативный слой памяти для агентов.
И ставка правильная: модели постепенно становятся взаимозаменяемыми, а настоящая ценность agentic-систем уходит в retrieval, memory и tools.
Точно стоит прогнать Keenable против Exa, Parallel и встроенного поиска Codex на реальных задачах.
Из стелса вышел Keenable — стартап Андрея Стыскина, бывшего главы поиска и рекламы Яндекса и директора Web Infrastructure в Amazon AGI.
Вместе с Matthias Petri, который строил web grounding для Alexa, они сразу подняли $26 млн от Accel и Conviction.
Keenable — не очередная обертка над Google или Bing. Компания заявляет собственный crawler, индекс и ranking stack, в котором уже более 100 млрд документов.
Обычный поиск создавался для человека:
один запрос → десять ссылок → один клик.
Агент ищет иначе. Он делает десятки запросов подряд и параллельно, уточняет их по найденной информации, читает целые страницы и не интересуется CTR, рекламой и красивыми превью.
Ему нужны полнота, long tail, свежесть, низкая задержка и дешевая стоимость каждого retrieval loop.
⚙️ Что есть внутри
1. Search API и MCP
Поиск плюс fetch_page_content, возвращающий очищенный Markdown.
Keenable подключается к Codex, Claude Code, Cursor, Windsurf и OpenCode.
Компания заявляет задержку менее 250 мс на p95 в US East. Artificial Analysis независимо назвал Keenable Realtime самым быстрым Search API по одному вызову — в среднем 0,34 секунды.
2. SELECT / Web Query Language
Пожалуй, самая интересная часть продукта. По сути это semantic SQL поверх интернета.
Агент может прогнать тысячи страниц через WEB_SEARCH, SEM_MATCH и SEM_EXTRACT, нормализовать данные и получить готовую таблицу с источником для каждой строки.
В публичном примере SELECT обработал 10 157 страниц за 6 минут 25 секунд и собрал 46 переходов исследователей между frontier AI-лабораториями.
То есть это уже не просто поиск ссылок, а отдельный execution engine для research.
3. Time Machine
Поиск по состоянию интернета в прошлом.
Параметр query_time перематывает не только доступный набор документов, но и ranking.
Это полезно для воспроизведения старых ответов агента, backtesting, расследований и проверки того, что вообще было известно на конкретную дату.
Полноценный Time Machine пока находится в early access.
📊 Собственный живой benchmark
Еще Keenable выпустила NEEDLE — открытый benchmark агентского поиска.
Новости обновляются каждый час, а finance, papers, long-tail и legal — ежедневно. Поэтому такой тест сложнее запомнить или найти вместе с готовым answer key.
Сейчас Keenable лидирует в собственном benchmark. Но нужна честная оговорка: тест открытый и воспроизводимый, однако создала и запускает его сама компания.
Независимо пока хорошо подтверждена скорость, но не превосходство по качеству.
💰 Сколько стоит
Без ключа дают 1 000 запросов в час.
После регистрации — 100 000 запросов каждый месяц.
Дальше — $4 за 1 000 запросов либо от $1 за 1 000 при нагрузке от 100 RPS.
⚠️ Есть нюанс
Я бы пока осторожно подключал Keenable глобально к агентам, работающим с приватным кодом.
Публичные Terms дают компании довольно широкие права на передаваемый User Content. Для enterprise здесь нужен отдельный договор, no-training/no-retention и, возможно, on-prem.
В общем, это не новый Perplexity.
Keenable пытается превратить живой интернет в дешевый и нативный слой памяти для агентов.
И ставка правильная: модели постепенно становятся взаимозаменяемыми, а настоящая ценность agentic-систем уходит в retrieval, memory и tools.
Точно стоит прогнать Keenable против Exa, Parallel и встроенного поиска Codex на реальных задачах.
🔥3🤔3🤯1🤡1
OpenAI будет давать full reset за каждый день без Astra. Вот до чего дошла гонка за AGI 🤯
Astra уже представили, но большинству пользователей её ещё не дали. И Tibo Sottiaux из команды Codex пообещал: за каждый день, пока Astra не появится именно на вашем платном ChatGPT-аккаунте, OpenAI положит вам один banked reset.
Для тех, кто не пользовался: это не «немного дополнительных токенов». Это сохранённая кнопка Full reset, которая полностью обновляет пятичасовой и недельный usage Codex/ChatGPT Work. Нажимаете — и можно снова работать на полном лимите.
OpenAI вообще щедрее всех раздаёт эти сбросы: за сбои, юбилеи, релизы, теперь уже просто за каждый день ожидания новой модели. xAI тоже подхватила механику: в Grok у меня сейчас лежит один такой reset.
На первый взгляд — забавный маркетинг. На самом деле это очень наглядный симптом того, какая безумная гонка сейчас идёт между OpenAI, Anthropic и xAI.
1 сентября Anthropic выпускает Fable 5.1. 3 сентября OpenAI отвечает Astra. Чуть раньше xAI за неполный месяц переходит с Grok 4.5 на 4.6. Они уже конкурируют не только ценой и лимитами. Они с нечеловеческой скоростью толкают вперёд само качество интеллекта.
Astra здесь особенно важна. На ARC-AGI-3 она получила 99,9% в фирменном harness OpenAI, который сохраняет reasoning между запросами и делает compaction. В нейтральном стандартном harness результат 62,7% — это важная оговорка. Но даже там это SOTA. А в «полной» конфигурации Astra использовала меньше действий, чем медианный человек, на 96% пройденных уровней.
И ARC-AGI-3 — не тест на знание энциклопедии. Агент попадает в незнакомую интерактивную среду без инструкции, на ходу выясняет правила и цель, строит модель мира, запоминает опыт и планирует действия. То есть проверяется именно способность быстро осваивать новое, а не доставать ответ из обучающей выборки.
Сами авторы ARC Prize отдельно говорят: один ограниченный benchmark не доказывает AGI. Конечно. Но Грег Брокман уже сказал предельно прямо: лично он считает, что мы «уже там» и вошли в эпоху AGI.
Я скажу ещё прямее: в практическом смысле это уже AGI. Не магическое сознание из фантастики и не безошибочный бог. А интеллект, который способен осваивать незнакомые задачи, работать за компьютером, писать код, проводить исследования и выполнять длинные профессиональные процессы на уровне, который ещё год назад казался фантастикой.
Я про это будущее говорил здесь много раз. А ещё до Telegram-канала, когда рассказывал людям, что именно так всё и будет, мне крутили пальцем у виска. Ну что, ребята, что теперь смешного? Президент OpenAI уже говорит «эра AGI», а сама OpenAI раздаёт полноценный недельный compute тем, кому приходится подождать AGI ещё один день.
За один год произошёл скачок, аналог которому я вообще с трудом могу подобрать в истории технологий. Разрыв между поколениями моделей теперь измеряется не годами, а месяцами, иногда неделями. И, как ни странно, главным двигателем этого скачка стала конкуренция. OpenAI давит Anthropic, Anthropic заставляет OpenAI отвечать, xAI врывается сбоку — и эта положительная обратная связь производит какое-то суперкачество.
Просто технологический слой изменился быстрее, чем рынок труда, компании, государства, образование и наше собственное мироощущение. Поэтому кажется, что мир пока тот же самый. Нет. Он уже кардинально другой — просто до большинства людей последствия ещё не успели доехать.
Когда Astra и следующие за ней системы массово попадут в руки людей и бизнеса, экономика изменится радикально. Не «когда-нибудь». Процесс уже начался.
Astra уже представили, но большинству пользователей её ещё не дали. И Tibo Sottiaux из команды Codex пообещал: за каждый день, пока Astra не появится именно на вашем платном ChatGPT-аккаунте, OpenAI положит вам один banked reset.
Для тех, кто не пользовался: это не «немного дополнительных токенов». Это сохранённая кнопка Full reset, которая полностью обновляет пятичасовой и недельный usage Codex/ChatGPT Work. Нажимаете — и можно снова работать на полном лимите.
OpenAI вообще щедрее всех раздаёт эти сбросы: за сбои, юбилеи, релизы, теперь уже просто за каждый день ожидания новой модели. xAI тоже подхватила механику: в Grok у меня сейчас лежит один такой reset.
На первый взгляд — забавный маркетинг. На самом деле это очень наглядный симптом того, какая безумная гонка сейчас идёт между OpenAI, Anthropic и xAI.
1 сентября Anthropic выпускает Fable 5.1. 3 сентября OpenAI отвечает Astra. Чуть раньше xAI за неполный месяц переходит с Grok 4.5 на 4.6. Они уже конкурируют не только ценой и лимитами. Они с нечеловеческой скоростью толкают вперёд само качество интеллекта.
Astra здесь особенно важна. На ARC-AGI-3 она получила 99,9% в фирменном harness OpenAI, который сохраняет reasoning между запросами и делает compaction. В нейтральном стандартном harness результат 62,7% — это важная оговорка. Но даже там это SOTA. А в «полной» конфигурации Astra использовала меньше действий, чем медианный человек, на 96% пройденных уровней.
И ARC-AGI-3 — не тест на знание энциклопедии. Агент попадает в незнакомую интерактивную среду без инструкции, на ходу выясняет правила и цель, строит модель мира, запоминает опыт и планирует действия. То есть проверяется именно способность быстро осваивать новое, а не доставать ответ из обучающей выборки.
Сами авторы ARC Prize отдельно говорят: один ограниченный benchmark не доказывает AGI. Конечно. Но Грег Брокман уже сказал предельно прямо: лично он считает, что мы «уже там» и вошли в эпоху AGI.
Я скажу ещё прямее: в практическом смысле это уже AGI. Не магическое сознание из фантастики и не безошибочный бог. А интеллект, который способен осваивать незнакомые задачи, работать за компьютером, писать код, проводить исследования и выполнять длинные профессиональные процессы на уровне, который ещё год назад казался фантастикой.
Я про это будущее говорил здесь много раз. А ещё до Telegram-канала, когда рассказывал людям, что именно так всё и будет, мне крутили пальцем у виска. Ну что, ребята, что теперь смешного? Президент OpenAI уже говорит «эра AGI», а сама OpenAI раздаёт полноценный недельный compute тем, кому приходится подождать AGI ещё один день.
За один год произошёл скачок, аналог которому я вообще с трудом могу подобрать в истории технологий. Разрыв между поколениями моделей теперь измеряется не годами, а месяцами, иногда неделями. И, как ни странно, главным двигателем этого скачка стала конкуренция. OpenAI давит Anthropic, Anthropic заставляет OpenAI отвечать, xAI врывается сбоку — и эта положительная обратная связь производит какое-то суперкачество.
Просто технологический слой изменился быстрее, чем рынок труда, компании, государства, образование и наше собственное мироощущение. Поэтому кажется, что мир пока тот же самый. Нет. Он уже кардинально другой — просто до большинства людей последствия ещё не успели доехать.
Когда Astra и следующие за ней системы массово попадут в руки людей и бизнеса, экономика изменится радикально. Не «когда-нибудь». Процесс уже начался.
🔥5❤2🤡2👍1🤔1💯1
Spotify показал, как сократить расход Claude Code примерно на 90% — и идея тут на самом деле очень правильная.
Проблема простая: огромная часть работы coding-агента — вообще не reasoning.
Claude читает 5 больших файлов, чтобы найти один метод. Читает тысячи строк тестов, чтобы понять паттерн. Генерирует boilerplate, конфиги, стабы. И на всё это тратятся дорогие frontier-токены.
В Spotify сделали плагин shunt, который буквально отбирает такую работу у Claude.
Схема примерно такая:
Claude Code → router → дешёвая модель → Claude
Они сделали два worker-а через Portal/AiKA:
→ bulk-reader — скармливаешь ему большие файлы, назад Claude получает только короткую структурированную выжимку;
→ code-writer — генерирует тесты, конфиги, type stubs и другой предсказуемый код по существующему reference-файлу.
В примере worker-модель — Gemini 2.5 Flash.
Самое интересное — routing сделан не промптом в CLAUDE.md.
Плагин использует PreToolUse hooks Claude Code. Если Claude пытается целиком прочитать файл больше 350 строк, hook блокирует Read и отправляет его в bulk-reader. То же самое ловится для
При этом targeted read конкретного участка файла разрешается.
То есть frontier-модели физически не дают бессмысленно пожирать контекст.
На Java-монорепе в 162K строк получили:
→ большой файл: 33 684 → 5 737 tokens, −82%
→ source + tests: 75 990 → 4 148, −94%
→ анализ нескольких сервисов: 16 221 → 821, −94%
Средняя экономия Claude-токенов на bulk-read — около 90%.
Но тут важная оговорка: это не означает, что inference вообще стал на 90% дешевле по количеству всех токенов. Большой контекст всё равно читает Gemini Flash. Просто вы перестаёте платить frontier-моделью за работу, которую прекрасно может выполнить маленькая и дешёвая модель.
И вот это, мне кажется, одна из главных архитектурных идей agentic coding ближайшего времени.
Frontier model не должна делать всю работу. Она должна управлять работой.
Reasoning, debugging, архитектура, сложные решения → Claude.
Поиск, чтение, summarization, boilerplate, трансформации → дешёвые специализированные модели.
Причём Spotify отдельно пишет, что пытаться делегировать reasoning уже плохо работает: worker пропустил subtle thread-safety bug, который Claude сразу нашёл. Поэтому они именно разделяют задачи по классу сложности, а не просто заменяют Claude дешёвой моделью.
По сути это уже не «один AI coding agent», а маленькая иерархия моделей внутри harness-а.
И мне кажется, дальше Codex / Claude Code / Kimi / OpenCode и остальные неизбежно придут примерно к этому: frontier-модель сверху, а под ней пачка дешёвых специализированных workers.
Потому что скармливать Opus/Sol всё подряд — это примерно как нанять principal engineer, чтобы он весь день grep запускал.
https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90
Проблема простая: огромная часть работы coding-агента — вообще не reasoning.
Claude читает 5 больших файлов, чтобы найти один метод. Читает тысячи строк тестов, чтобы понять паттерн. Генерирует boilerplate, конфиги, стабы. И на всё это тратятся дорогие frontier-токены.
В Spotify сделали плагин shunt, который буквально отбирает такую работу у Claude.
Схема примерно такая:
Claude Code → router → дешёвая модель → Claude
Они сделали два worker-а через Portal/AiKA:
→ bulk-reader — скармливаешь ему большие файлы, назад Claude получает только короткую структурированную выжимку;
→ code-writer — генерирует тесты, конфиги, type stubs и другой предсказуемый код по существующему reference-файлу.
В примере worker-модель — Gemini 2.5 Flash.
Самое интересное — routing сделан не промптом в CLAUDE.md.
Плагин использует PreToolUse hooks Claude Code. Если Claude пытается целиком прочитать файл больше 350 строк, hook блокирует Read и отправляет его в bulk-reader. То же самое ловится для
cat, head, tail, less, more.При этом targeted read конкретного участка файла разрешается.
То есть frontier-модели физически не дают бессмысленно пожирать контекст.
На Java-монорепе в 162K строк получили:
→ большой файл: 33 684 → 5 737 tokens, −82%
→ source + tests: 75 990 → 4 148, −94%
→ анализ нескольких сервисов: 16 221 → 821, −94%
Средняя экономия Claude-токенов на bulk-read — около 90%.
Но тут важная оговорка: это не означает, что inference вообще стал на 90% дешевле по количеству всех токенов. Большой контекст всё равно читает Gemini Flash. Просто вы перестаёте платить frontier-моделью за работу, которую прекрасно может выполнить маленькая и дешёвая модель.
И вот это, мне кажется, одна из главных архитектурных идей agentic coding ближайшего времени.
Frontier model не должна делать всю работу. Она должна управлять работой.
Reasoning, debugging, архитектура, сложные решения → Claude.
Поиск, чтение, summarization, boilerplate, трансформации → дешёвые специализированные модели.
Причём Spotify отдельно пишет, что пытаться делегировать reasoning уже плохо работает: worker пропустил subtle thread-safety bug, который Claude сразу нашёл. Поэтому они именно разделяют задачи по классу сложности, а не просто заменяют Claude дешёвой моделью.
По сути это уже не «один AI coding agent», а маленькая иерархия моделей внутри harness-а.
И мне кажется, дальше Codex / Claude Code / Kimi / OpenCode и остальные неизбежно придут примерно к этому: frontier-модель сверху, а под ней пачка дешёвых специализированных workers.
Потому что скармливать Opus/Sol всё подряд — это примерно как нанять principal engineer, чтобы он весь день grep запускал.
https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90
Spotify Engineering
Portal by Spotify cut my Claude Code token usage by 90% | Spotify Engineering
🔥5👍2❤1🤔1💯1
Оказывается, hidden reasoning у frontier-моделей можно было буквально украсть за два API-вызова 😨
Очень крутая работа Stolen Thoughts про уязвимость reasoning API у OpenAI, Anthropic и Google.
Механика, по сути, гениально простая.
Когда reasoning-модель думает, полный Chain-of-Thought пользователю не показывают. Но чтобы продолжать диалог, API возвращает клиенту зашифрованный reasoning block, который потом можно отправить обратно.
Проблема оказалась в том, что эти блоки были недостаточно привязаны к конкретной модели, сессии и пользователю.
Исследователи брали encrypted reasoning от сильной модели — условно Opus — и передавали его более слабой модели того же провайдера. Слабую модель уже гораздо проще jailbreak'нуть и попросить вывести содержимое reasoning.
И она фактически становилась decryption oracle и печатала reasoning сильной модели plaintext'ом.
Причем показали это для Anthropic, OpenAI и Google.
Самое неприятное даже не кража интеллектуальной собственности модели.
Исследователи собрали 6 708 публичных agent trajectories с GitHub и Hugging Face, внутри которых остались encrypted reasoning blocks, и восстановили 315 320 reasoning traces.
Там нашли 704 уникальных sensitive artifacts: API keys, passwords, access tokens, email, внутренние URL и другую приватную информацию.
Причем часть данных существовала только внутри hidden reasoning и вообще никогда не появлялась в видимом ответе модели.
То есть разработчик мог посмотреть лог, решить:
«Ну тут ничего секретного нет»,
запушить trajectory на GitHub — а внутри encrypted blob лежал пароль или API key.
Еще прикольный эксперимент сделали с Kimi-K3: ей подсовывали всего первые ~1% reasoning от Opus 4.8, и даже такого маленького seed хватало, чтобы итоговый ответ Kimi начинал двигаться в сторону формулировок Opus. То есть reasoning реально является очень мощным hidden state, который управляет дальнейшей генерацией.
И вывод для всей агентской разработки:
encrypted ≠ safe.
Если opaque blob можно перенести в другой security context, а сервер потом сам его расшифрует и отдаст модели — это, по сути, bearer token с огромным количеством скрытого контекста внутри.
После responsible disclosure провайдеры дыру уже прикрыли: атаки из paper сейчас не воспроизводятся. Reasoning blocks стали жестче привязывать к модели и контексту сессии.
Но сама работа очень хорошая.
Мы всё больше строим agent infrastructure вокруг hidden state моделей — reasoning, memory, compaction, checkpoints — и такие объекты надо начинать воспринимать ровно как credentials и secrets, а не как какие-то безобидные технические поля API.
stolen-thoughts.com
Очень крутая работа Stolen Thoughts про уязвимость reasoning API у OpenAI, Anthropic и Google.
Механика, по сути, гениально простая.
Когда reasoning-модель думает, полный Chain-of-Thought пользователю не показывают. Но чтобы продолжать диалог, API возвращает клиенту зашифрованный reasoning block, который потом можно отправить обратно.
Проблема оказалась в том, что эти блоки были недостаточно привязаны к конкретной модели, сессии и пользователю.
Исследователи брали encrypted reasoning от сильной модели — условно Opus — и передавали его более слабой модели того же провайдера. Слабую модель уже гораздо проще jailbreak'нуть и попросить вывести содержимое reasoning.
И она фактически становилась decryption oracle и печатала reasoning сильной модели plaintext'ом.
Причем показали это для Anthropic, OpenAI и Google.
Самое неприятное даже не кража интеллектуальной собственности модели.
Исследователи собрали 6 708 публичных agent trajectories с GitHub и Hugging Face, внутри которых остались encrypted reasoning blocks, и восстановили 315 320 reasoning traces.
Там нашли 704 уникальных sensitive artifacts: API keys, passwords, access tokens, email, внутренние URL и другую приватную информацию.
Причем часть данных существовала только внутри hidden reasoning и вообще никогда не появлялась в видимом ответе модели.
То есть разработчик мог посмотреть лог, решить:
«Ну тут ничего секретного нет»,
запушить trajectory на GitHub — а внутри encrypted blob лежал пароль или API key.
Еще прикольный эксперимент сделали с Kimi-K3: ей подсовывали всего первые ~1% reasoning от Opus 4.8, и даже такого маленького seed хватало, чтобы итоговый ответ Kimi начинал двигаться в сторону формулировок Opus. То есть reasoning реально является очень мощным hidden state, который управляет дальнейшей генерацией.
И вывод для всей агентской разработки:
encrypted ≠ safe.
Если opaque blob можно перенести в другой security context, а сервер потом сам его расшифрует и отдаст модели — это, по сути, bearer token с огромным количеством скрытого контекста внутри.
После responsible disclosure провайдеры дыру уже прикрыли: атаки из paper сейчас не воспроизводятся. Reasoning blocks стали жестче привязывать к модели и контексту сессии.
Но сама работа очень хорошая.
Мы всё больше строим agent infrastructure вокруг hidden state моделей — reasoning, memory, compaction, checkpoints — и такие объекты надо начинать воспринимать ровно как credentials и secrets, а не как какие-то безобидные технические поля API.
stolen-thoughts.com
🔥13👍5❤2
🧠 Google OKF vs OpenViking: какую память делать своим агентам?
Начал разбираться с Open Knowledge Format от Google. На первый взгляд — ещё один подход к агентской памяти. Но если поставить рядом OpenViking, выясняется интересная штука: они решают похожую задачу на разных уровнях.
OKF говорит: «Давайте договоримся, как представлять знания».
OpenViking: «Вот система, которая будет их хранить, находить и извлекать из работы агента».
📁 Что предлагает Google
OKF — это Markdown-файлы с YAML-метаданными и ссылками друг на друга. По сути, общая wiki для людей и агентов.
Один документ описывает сервис. Другой — архитектурное решение. Третий — инцидент. Ссылки между ними образуют граф.
В v0.2 можно указать, откуда взялось знание, кто его создал и проверил, когда оно устареет. Всё это живёт в файлах: можно хранить в Git, смотреть diff, делать review, передавать другому агенту.
Но сам формат не решает, что запомнить из диалога, как найти нужное и что делать с противоречиями. Это работа твоего harness и инструментов вокруг него.
Подробнее — в [спецификации OKF](https://github.com/GoogleCloudPlatform/open-knowledge-format/blob/main/SPEC.md).
⚙️ Что делает OpenViking
Это уже база контекста с виртуальной файловой системой: документы, воспоминания и навыки доступны через viking://.
Есть поиск и постепенная загрузка контекста: краткое описание каталога → обзор → полное содержимое. Сначала агент определяет, куда смотреть, потом читает подробности.
При сохранении сессии система запускает извлечение воспоминаний, сравнивает их с существующими и решает, что добавить, объединить или пропустить. Это уже реализованный механизм, хотя качество его решений, конечно, нужно проверять.
Вот (https://github.com/volcengine/OpenViking).
Допустим, агент починил баг и выяснил: после изменения конкретного параметра нужен полный перезапуск сервиса.
С OKF ты можешь красиво сохранить этот факт, источник и дату проверки. Но процесс, который заметит полезный вывод и обновит нужный документ, нужно организовать.
В OpenViking такой процесс уже есть: передаёшь сообщения в сессию, сохраняешь её — запускается обработка памяти. (https://docs.openviking.ai/en/concepts/08-session).
🤔 Тогда в чём преимущество OKF?
Не в том, что он обязательно лучше вспоминает или экономит больше токенов. Сам по себе формат этого не обеспечивает.
Его преимущество — знания можно сделать отдельным, переносимым активом. Сегодня их читает один агент, завтра другой. Поисковый движок поменялся, а проверенные решения, контракты и инструкции остались в понятном формате.
При этом OpenViking тоже использует Markdown и файловую иерархию. Поэтому «у Google файлы, а у остальных магическая база» — неправильное сравнение.
Для меня выбор такой:
— Нужна автоматическая память между сессиями — первым тестировал бы OpenViking.
— Нужна управляемая база инженерных знаний с Git review — смотрел бы на OKF.
— Уже работает собственная память — смена формата сама по себе умнее её не сделает.
Можно совместить оба подхода: проверенные знания хранить в OKF, а OpenViking использовать для поиска и оперативной памяти. Только синхронизация — это отдельная инженерная задача.
И главное, мои хорошие: записанный агентом вывод ещё не становится фактом. Можно очень эффективно находить и переиспользовать собственную ошибку. Поэтому мне в этой истории важен не только recall, но и то, кто проверяет знания перед тем, как остальные агенты начинают на них опираться.
Начал разбираться с Open Knowledge Format от Google. На первый взгляд — ещё один подход к агентской памяти. Но если поставить рядом OpenViking, выясняется интересная штука: они решают похожую задачу на разных уровнях.
OKF говорит: «Давайте договоримся, как представлять знания».
OpenViking: «Вот система, которая будет их хранить, находить и извлекать из работы агента».
📁 Что предлагает Google
OKF — это Markdown-файлы с YAML-метаданными и ссылками друг на друга. По сути, общая wiki для людей и агентов.
Один документ описывает сервис. Другой — архитектурное решение. Третий — инцидент. Ссылки между ними образуют граф.
В v0.2 можно указать, откуда взялось знание, кто его создал и проверил, когда оно устареет. Всё это живёт в файлах: можно хранить в Git, смотреть diff, делать review, передавать другому агенту.
Но сам формат не решает, что запомнить из диалога, как найти нужное и что делать с противоречиями. Это работа твоего harness и инструментов вокруг него.
Подробнее — в [спецификации OKF](https://github.com/GoogleCloudPlatform/open-knowledge-format/blob/main/SPEC.md).
⚙️ Что делает OpenViking
Это уже база контекста с виртуальной файловой системой: документы, воспоминания и навыки доступны через viking://.
Есть поиск и постепенная загрузка контекста: краткое описание каталога → обзор → полное содержимое. Сначала агент определяет, куда смотреть, потом читает подробности.
При сохранении сессии система запускает извлечение воспоминаний, сравнивает их с существующими и решает, что добавить, объединить или пропустить. Это уже реализованный механизм, хотя качество его решений, конечно, нужно проверять.
Вот (https://github.com/volcengine/OpenViking).
Допустим, агент починил баг и выяснил: после изменения конкретного параметра нужен полный перезапуск сервиса.
С OKF ты можешь красиво сохранить этот факт, источник и дату проверки. Но процесс, который заметит полезный вывод и обновит нужный документ, нужно организовать.
В OpenViking такой процесс уже есть: передаёшь сообщения в сессию, сохраняешь её — запускается обработка памяти. (https://docs.openviking.ai/en/concepts/08-session).
🤔 Тогда в чём преимущество OKF?
Не в том, что он обязательно лучше вспоминает или экономит больше токенов. Сам по себе формат этого не обеспечивает.
Его преимущество — знания можно сделать отдельным, переносимым активом. Сегодня их читает один агент, завтра другой. Поисковый движок поменялся, а проверенные решения, контракты и инструкции остались в понятном формате.
При этом OpenViking тоже использует Markdown и файловую иерархию. Поэтому «у Google файлы, а у остальных магическая база» — неправильное сравнение.
Для меня выбор такой:
— Нужна автоматическая память между сессиями — первым тестировал бы OpenViking.
— Нужна управляемая база инженерных знаний с Git review — смотрел бы на OKF.
— Уже работает собственная память — смена формата сама по себе умнее её не сделает.
Можно совместить оба подхода: проверенные знания хранить в OKF, а OpenViking использовать для поиска и оперативной памяти. Только синхронизация — это отдельная инженерная задача.
И главное, мои хорошие: записанный агентом вывод ещё не становится фактом. Можно очень эффективно находить и переиспользовать собственную ошибку. Поэтому мне в этой истории важен не только recall, но и то, кто проверяет знания перед тем, как остальные агенты начинают на них опираться.
GitHub
open-knowledge-format/SPEC.md at main · GoogleCloudPlatform/open-knowledge-format
Contribute to GoogleCloudPlatform/open-knowledge-format development by creating an account on GitHub.
🔥6
Как я использую OKF в своих проектах?
Я запускаю этот промпт и дальше агент читает правила из AGENTS.md и использует как agentic memory:
Я запускаю этот промпт и дальше агент читает правила из AGENTS.md и использует как agentic memory:
Внедри в текущий репозиторий минимальную базу инженерных знаний в Google Open Knowledge Format (OKF v0.2). Правила её использования закрепи в корневом AGENTS.md.
Спецификация:
https://github.com/GoogleCloudPlatform/open-knowledge-format/blob/main/SPEC.md
1. Исследуй проект
Прочитай инструкции для агентов, README, ADR, документацию, конфигурацию сборки и CI. Найди существующий корпус знаний и устройство harness, включая xpowers, если он используется.
Сохрани действующие инструкции. Если подходящий корпус уже существует, развивай его вместо создания параллельного.
2. Создай knowledge/
Начни с index.md и 3–5 содержательных документов по реально исследованному проекту: архитектура, контракты, инварианты, проверка изменений, диагностика.
Возможные категории: architecture/, decisions/, contracts/, runbooks/, incidents/. Создавай только нужные; пустые разделы и заглушки не нужны.
Соблюдай OKF:
* В корневом index.md укажи okf_version: "0.2", добавь ссылки и краткие описания документов.
* В каждом обычном Markdown-документе используй YAML frontmatter с непустым type; добавь title, description и status.
* index.md и log.md оформляй по специальным правилам спецификации.
* Связывай документы относительными Markdown-ссылками.
* Указывай реальные источники в sources; для GitHub по возможности используй ссылки с commit SHA.
* generated и stale_after добавляй по необходимости.
* verified заполняй только после фактической проверки, указывая реального проверяющего и время.
Не дублируй большие README и ADR — ссылайся на них.
3. Проверяй основания
Утверждения о текущем поведении сверяй с кодом, тестами и конфигурацией. Причины решений ищи в ADR и истории.
Не придумывай мотивы авторов, результаты тестов, даты и подтверждения. Различай наблюдаемое поведение, требования и предположения. Противоречия фиксируй явно; непроверенное оставляй черновиком.
4. Добавь правила в AGENTS.md
Обнови корневой AGENTS.md, сохранив существующие инструкции; если файла нет — создай. Добавь отдельный раздел «Использование базы знаний» с конкретными правилами:
Перед существенной задачей:
* Прочитать knowledge/index.md.
* Выбрать относящиеся к задаче документы; при необходимости искать по knowledge/ через rg и переходить по ссылкам.
* Не загружать весь корпус без необходимости.
* Проверять status, stale_after и основания verified. Просроченные сведения перепроверять, deprecated учитывать как историю.
Во время работы:
* Сверять критичные утверждения с текущими источниками.
* При расхождении знаний и кода установить, что устарело или нарушено; не выбирать версию автоматически.
* Отделять подтверждённые факты от гипотез.
Перед завершением задачи:
* Оценить, появились ли устойчивые знания: решение, инвариант, ограничение, причина ошибки или проверенная процедура.
* Обновить существующий документ либо создать новый со ссылками на основания.
* При изменении поведения обновить связанные знания в том же PR.
* Поддерживать индекс и внутренние ссылки.
* После существенной правки пересмотреть прежние verified; неподтверждённые сведения оставить черновиком.
* Не сохранять рутинный пересказ сессии и дубликаты.
* В отчёте указать обновлённые документы либо отметить, что обновление знаний не требовалось.
Инструкции harness держи вне OKF bundle. Если другие агенты используют отдельные файлы инструкций, добавь в них ссылку на эти правила без копирования всего раздела.
5. Проверь и заверши
Проверь YAML, обязательные поля, структуру индекса, внутренние ссылки, основания ключевых утверждений и согласованность AGENTS.md с созданным корпусом.
Используй существующие проверки документации. Не добавляй тяжёлую инфраструктуру и не меняй продуктовый код ради этой задачи.
В конце сообщи, какие файлы изменены, что проверено и какие вопросы остались. Выполни работу до конкретных изменений в репозитории, не ограничивайся планом.
GitHub
open-knowledge-format/SPEC.md at main · GoogleCloudPlatform/open-knowledge-format
Contribute to GoogleCloudPlatform/open-knowledge-format development by creating an account on GitHub.
👍5🔥1🥰1🤔1
Я перестал давать Astra писать код. И дело не в том, что она плохо это делает 🙂
Довёл до рабочего состояния конфиг для Codex: Astra координирует, Terra и Sol пишут код. Собрал bash-скрипт, который настраивает всё в репозитории.
Но тут важно объяснить, почему я вообще так сделал.
Astra — не принципиально другой уровень на каждой coding-задаче. На части бенчмарков она близка к Sol: например, в опубликованных OpenAI результатах DeepSWE v1.1 — 74,1% против 72,7%. При этом на сложных терминальных задачах и миграциях преимущество уже заметно больше. То есть модели не одинаковые, но каждая обычная правка не становится кратно лучше от замены Sol на Astra.
И для меня основной смысл Astra — решение сложнейших задач, а не написание очередного обработчика.
Разобраться в системе. Найти причину, которую все пропустили. Определить правильные инварианты. Придумать решение, когда непонятно даже, с какой стороны подойти.
Вот на это я и хочу тратить её reasoning.
Не «напиши весь код сама», а «реши сложную задачу и организуй её реализацию».
Схема получилась такая.
🧠 Astra / medium — архитектор и координатор.
Разбирает задачу, принимает архитектурные решения, определяет границы работы и критерии приёмки. Раздаёт задачи агентам, проверяет diff и результаты тестов.
Это не диспетчер, который просто пересылает сообщения. Самую сложную интеллектуальную часть она должна разобрать сама, а исполнителям передать конкретную постановку.
🔧 Terra / medium — основной кодер.
Реализация, тесты, локальные исправления. Для поиска конкретных файлов и символов — отдельный explorer на low. Для независимой проверки — verifier на medium.
🔬 Sol / high — сложная реализация.
Concurrency, нетривиальные алгоритмы, тяжёлый debugging. Если Terra два раза не справилась — передаём Sol. Если риск очевиден сразу, не тратим попытки Terra.
Для рискованного изменения — ещё и отдельный Sol-reviewer, не автор кода.
Обычный маршрут: Astra → Terra → проверка → Astra
Сложный: Astra → Sol → проверка → независимое review → Astra
Главное правило: Astra нашла баг — не идёт «быстро сама поправлю». Формулирует проблему и возвращает исполнителю. Даже если исправление на одну строку.
Иначе разделение ролей заканчивается на первом неудобном тесте.
Все роли на каждую задачу не запускаются. Максимум три дочерних треда, по умолчанию один writer. Параллельные правки — только в независимых участках. Исполнители свои команды агентов не создают.
С effort тоже не стал экономить вслепую: основной кодер на medium, сложная реализация и review на high. Для архитектурно сложной задачи Astra можно поднять до high.
Дешёвая первая попытка ничего не стоит, если потом приходится оплачивать три переделки.
🛠 Установка из корня репозитория:
Нужны Bash, Git и Python 3.9+. Скрипт объединяет настройки с существующим конфигом, добавляет роли и правила в AGENTS.md, делает backup. После установки — новая сессия Codex и приложенный smoke test.
Запрет Astra менять файлы здесь — инструкция, не жёсткая sandbox-изоляция.
Проценты экономии пока не называю — сравнительных замеров нет. Меньше токенов Astra не обязательно означает меньше общего расхода. Проверять буду стоимость принятого change по всем моделям, с учётом переделок и качества.
Но сама идея для меня именно такая:
Сильнейшая модель нужна не для того, чтобы лично написать каждую строчку. Она нужна, чтобы решить то, что остальные не решили, и организовать работу остальных.
Конфиг и скрипт установки прикладываю.
https://gist.github.com/dpolishuk/b2f17580aa62c55dce99c92f58049d37
Довёл до рабочего состояния конфиг для Codex: Astra координирует, Terra и Sol пишут код. Собрал bash-скрипт, который настраивает всё в репозитории.
Но тут важно объяснить, почему я вообще так сделал.
Astra — не принципиально другой уровень на каждой coding-задаче. На части бенчмарков она близка к Sol: например, в опубликованных OpenAI результатах DeepSWE v1.1 — 74,1% против 72,7%. При этом на сложных терминальных задачах и миграциях преимущество уже заметно больше. То есть модели не одинаковые, но каждая обычная правка не становится кратно лучше от замены Sol на Astra.
И для меня основной смысл Astra — решение сложнейших задач, а не написание очередного обработчика.
Разобраться в системе. Найти причину, которую все пропустили. Определить правильные инварианты. Придумать решение, когда непонятно даже, с какой стороны подойти.
Вот на это я и хочу тратить её reasoning.
Не «напиши весь код сама», а «реши сложную задачу и организуй её реализацию».
Схема получилась такая.
🧠 Astra / medium — архитектор и координатор.
Разбирает задачу, принимает архитектурные решения, определяет границы работы и критерии приёмки. Раздаёт задачи агентам, проверяет diff и результаты тестов.
Это не диспетчер, который просто пересылает сообщения. Самую сложную интеллектуальную часть она должна разобрать сама, а исполнителям передать конкретную постановку.
🔧 Terra / medium — основной кодер.
Реализация, тесты, локальные исправления. Для поиска конкретных файлов и символов — отдельный explorer на low. Для независимой проверки — verifier на medium.
🔬 Sol / high — сложная реализация.
Concurrency, нетривиальные алгоритмы, тяжёлый debugging. Если Terra два раза не справилась — передаём Sol. Если риск очевиден сразу, не тратим попытки Terra.
Для рискованного изменения — ещё и отдельный Sol-reviewer, не автор кода.
Обычный маршрут: Astra → Terra → проверка → Astra
Сложный: Astra → Sol → проверка → независимое review → Astra
Главное правило: Astra нашла баг — не идёт «быстро сама поправлю». Формулирует проблему и возвращает исполнителю. Даже если исправление на одну строку.
Иначе разделение ролей заканчивается на первом неудобном тесте.
Все роли на каждую задачу не запускаются. Максимум три дочерних треда, по умолчанию один writer. Параллельные правки — только в независимых участках. Исполнители свои команды агентов не создают.
С effort тоже не стал экономить вслепую: основной кодер на medium, сложная реализация и review на high. Для архитектурно сложной задачи Astra можно поднять до high.
Дешёвая первая попытка ничего не стоит, если потом приходится оплачивать три переделки.
🛠 Установка из корня репозитория:
# Посмотреть планbash ~/Downloads/setup-codex-routing.sh --dry-run# Установитьbash ~/Downloads/setup-codex-routing.shНужны Bash, Git и Python 3.9+. Скрипт объединяет настройки с существующим конфигом, добавляет роли и правила в AGENTS.md, делает backup. После установки — новая сессия Codex и приложенный smoke test.
Запрет Astra менять файлы здесь — инструкция, не жёсткая sandbox-изоляция.
Проценты экономии пока не называю — сравнительных замеров нет. Меньше токенов Astra не обязательно означает меньше общего расхода. Проверять буду стоимость принятого change по всем моделям, с учётом переделок и качества.
Но сама идея для меня именно такая:
Сильнейшая модель нужна не для того, чтобы лично написать каждую строчку. Она нужна, чтобы решить то, что остальные не решили, и организовать работу остальных.
Конфиг и скрипт установки прикладываю.
https://gist.github.com/dpolishuk/b2f17580aa62c55dce99c92f58049d37
Gist
setup-codex-routing.sh
setup-codex-routing.sh. GitHub Gist: instantly share code, notes, and snippets.
1👍14❤7🔥3🙏2🆒1
⚡ Собрал смарт-роутинг для Claude Code: тяжёлые задачи — на GLM-4.5+, рутина — на флеш
Поднял локальный шлюз (claude-code-router) перед API Z.AI — и теперь у меня две модели на одной сессии:
🔹 glm-5.3 — рассуждения, планирование, архитектура, сложные рефакторинги
🔹 glm-5.3-flash — фоновое сжатие контекста, grep/навигация, git status, линтеры, автодополнение типов, парсинг логов, точечные патчи
Фон жёстко уходит на флеш через слоты моделей профиля — это до 80% бюджета сессии по токенам. Базовые субагенты (поиск файлов, доки, форматирование) запинены на haiku-слот = флеш. Тяжёлые агенты остаются на основной.
По пути нашёл два неочевидных бага, из-за которых «всё настроено, но флеш не работает»:
1️⃣ CCR добавляет суффикс [1m] к именам моделей в env-слотах → шлюз не распознавал имя и молча отправлял запрос на дефолт. Лечится alias-правилами роутера.
2️⃣ Все кастомные агенты были с model: inherit → всегда главная модель, мимо любых слотов. Вылечил пинами model: haiku у рутинных агентов.
Итог проверял не на глаз, а по usage-БД шлюза: у фоновых запросов реально 200 OK с моделью glm-5.3-flash.
Весь сетап — два скрипта: zccr-setup (идемпотентная настройка через management RPC, ключи не светятся в ps) и zclaude (обёртка: подняла шлюз, если лежит → запустила Claude Code через профиль). Работает автономно, обычный claude не трогает.
Gist: https://gist.github.com/zamotkin/37364589027cf3f1c2e5e8c1cf746c43
Состав:
- README.md — политика маршрутизации таблицей, 4 грабли (суффикс [1m], model: inherit, секреты в argv, опечатка в ключе), установка в 5 команд, проверка фактической маршрутизации через usage-БД
- zccr-setup.sh — идемпотентный RPC-конфигуратор (322 строки: секреты через mktemp-файлы 0600, connectivity до saveConfig, no-op-детект, loopback-валидация)
- zclaude.sh — runtime-обёртка (health → тихий автостарт → exec ccr "Claude Code" cli --)
Поднял локальный шлюз (claude-code-router) перед API Z.AI — и теперь у меня две модели на одной сессии:
🔹 glm-5.3 — рассуждения, планирование, архитектура, сложные рефакторинги
🔹 glm-5.3-flash — фоновое сжатие контекста, grep/навигация, git status, линтеры, автодополнение типов, парсинг логов, точечные патчи
Фон жёстко уходит на флеш через слоты моделей профиля — это до 80% бюджета сессии по токенам. Базовые субагенты (поиск файлов, доки, форматирование) запинены на haiku-слот = флеш. Тяжёлые агенты остаются на основной.
По пути нашёл два неочевидных бага, из-за которых «всё настроено, но флеш не работает»:
1️⃣ CCR добавляет суффикс [1m] к именам моделей в env-слотах → шлюз не распознавал имя и молча отправлял запрос на дефолт. Лечится alias-правилами роутера.
2️⃣ Все кастомные агенты были с model: inherit → всегда главная модель, мимо любых слотов. Вылечил пинами model: haiku у рутинных агентов.
Итог проверял не на глаз, а по usage-БД шлюза: у фоновых запросов реально 200 OK с моделью glm-5.3-flash.
Весь сетап — два скрипта: zccr-setup (идемпотентная настройка через management RPC, ключи не светятся в ps) и zclaude (обёртка: подняла шлюз, если лежит → запустила Claude Code через профиль). Работает автономно, обычный claude не трогает.
Gist: https://gist.github.com/zamotkin/37364589027cf3f1c2e5e8c1cf746c43
Состав:
- README.md — политика маршрутизации таблицей, 4 грабли (суффикс [1m], model: inherit, секреты в argv, опечатка в ключе), установка в 5 команд, проверка фактической маршрутизации через usage-БД
- zccr-setup.sh — идемпотентный RPC-конфигуратор (322 строки: секреты через mktemp-файлы 0600, connectivity до saveConfig, no-op-детект, loopback-валидация)
- zclaude.sh — runtime-обёртка (health → тихий автостарт → exec ccr "Claude Code" cli --)
Gist
Smart routing для Claude Code: claude-code-router v3 + Z.AI GLM (glm-5.3 / glm-5.3-flash) — task-aware маршрутизация heavy/light
Smart routing для Claude Code: claude-code-router v3 + Z.AI GLM (glm-5.3 / glm-5.3-flash) — task-aware маршрутизация heavy/light - README.md
🔥9👍2❤1
🧠 Маршрутизация моделей в Claude Code: неделя на практике
Настроил для Claude Code маршрутизацию моделей по образцу своего Codex-конфига. Неделю на ней прожил — делюсь.
Идея простая: сильнейшая модель прекрасно умеет писать код. Но гораздо полезнее занять её разбором сложной задачи, постановкой и приёмкой результата, а реализацию делегировать.
🎯 Кто чем занимается
Главный тред — координатор. Он читает код и готовит карточку задачи: цель, какие файлы можно менять, инварианты, критерии приёмки и команды проверки.
Дальше раздаёт работу:
🔎 explorer → Haiku
Только поиск по коду.
🛠 worker → Opus
Реализация через TDD.
🧪 verifier → Sonnet
Независимый прогон проверок по чужому diff.
🧠 senior → Opus на high
Деньги, данные, concurrency и сложные эскалации.
👀 reviewer → другая модель
Семантическое ревью. Обязательно другой моделью, чем у автора.
🔒 Главная фича — координатору нельзя писать код
В Codex-версии это было прописано инструкцией. Здесь запрет обеспечивается хуком PreToolUse.
У субагента в JSON хука есть agent_id, у главного треда — нет. Пока лежит маркер .claude/routing.on, хук отклоняет Edit/Write из главного треда и shell-команды, которые распознаёт как записывающие.
Привычное «да тут одну строку, сейчас быстро сам поправлю» упирается в блокировку.
Именно на таких мелочах разделение ролей обычно и заканчивается. Для меня это главная фича.
📌 Что получилось на практике
• Верификатор поймал ошибку в моей постановке, которую я бы сам не заметил. Проверять нужно и то, правильно ли мы вообще поставили задачу.
• Ревьюер на другой модели прогнал дифференциальную проверку на 100 миллионах входов там, где автор ограничился тестами.
• Контекст координатора не раздувается. Подробные логи, содержимое файлов и вывод docker остаются у субагентов. Наверх возвращаются результаты и свидетельства проверок.
💸 Что по стоимости
Токенов в сумме стало больше.
Каждый субагент заново читает файлы. Карточка задачи, отчёт, приёмка — дополнительные проходы по одному изменению. Изоляция контекста не бесплатная.
По моим задачам экономия получается за счёт распределения работы: сильнейшая модель занимается постановкой и приёмкой, часть работы уходит моделям подешевле.
• Против одного треда на сильнейшей модели — дешевле.
• Против одного треда на средней — дороже.
Я здесь в первую очередь покупаю изоляцию и независимый взгляд на результат.
🪤 Грабли за неделю
• Bash-обёртка с heredoc съела stdin хука, и тот молча пропускал всё. Проверяйте, что блокировка действительно срабатывает.
• Лимита в 30 ходов проверяющим не хватило на docker-тесты. В моём сценарии 60 — рабочий минимум.
• Эвристика записывающих shell-команд смотрит на слова, а не на пути. Это ограничение нужно учитывать.
📦 Забрать конфиг
Инсталлятор, готовые конфиги, тесты хука и описание процесса — в gist.
Ставится одной командой. Установка идемпотентная, откат — флагом –restore.
Настроил для Claude Code маршрутизацию моделей по образцу своего Codex-конфига. Неделю на ней прожил — делюсь.
Идея простая: сильнейшая модель прекрасно умеет писать код. Но гораздо полезнее занять её разбором сложной задачи, постановкой и приёмкой результата, а реализацию делегировать.
🎯 Кто чем занимается
Главный тред — координатор. Он читает код и готовит карточку задачи: цель, какие файлы можно менять, инварианты, критерии приёмки и команды проверки.
Дальше раздаёт работу:
🔎 explorer → Haiku
Только поиск по коду.
🛠 worker → Opus
Реализация через TDD.
🧪 verifier → Sonnet
Независимый прогон проверок по чужому diff.
🧠 senior → Opus на high
Деньги, данные, concurrency и сложные эскалации.
👀 reviewer → другая модель
Семантическое ревью. Обязательно другой моделью, чем у автора.
🔒 Главная фича — координатору нельзя писать код
В Codex-версии это было прописано инструкцией. Здесь запрет обеспечивается хуком PreToolUse.
У субагента в JSON хука есть agent_id, у главного треда — нет. Пока лежит маркер .claude/routing.on, хук отклоняет Edit/Write из главного треда и shell-команды, которые распознаёт как записывающие.
Привычное «да тут одну строку, сейчас быстро сам поправлю» упирается в блокировку.
Именно на таких мелочах разделение ролей обычно и заканчивается. Для меня это главная фича.
📌 Что получилось на практике
• Верификатор поймал ошибку в моей постановке, которую я бы сам не заметил. Проверять нужно и то, правильно ли мы вообще поставили задачу.
• Ревьюер на другой модели прогнал дифференциальную проверку на 100 миллионах входов там, где автор ограничился тестами.
• Контекст координатора не раздувается. Подробные логи, содержимое файлов и вывод docker остаются у субагентов. Наверх возвращаются результаты и свидетельства проверок.
💸 Что по стоимости
Токенов в сумме стало больше.
Каждый субагент заново читает файлы. Карточка задачи, отчёт, приёмка — дополнительные проходы по одному изменению. Изоляция контекста не бесплатная.
По моим задачам экономия получается за счёт распределения работы: сильнейшая модель занимается постановкой и приёмкой, часть работы уходит моделям подешевле.
• Против одного треда на сильнейшей модели — дешевле.
• Против одного треда на средней — дороже.
Я здесь в первую очередь покупаю изоляцию и независимый взгляд на результат.
🪤 Грабли за неделю
• Bash-обёртка с heredoc съела stdin хука, и тот молча пропускал всё. Проверяйте, что блокировка действительно срабатывает.
• Лимита в 30 ходов проверяющим не хватило на docker-тесты. В моём сценарии 60 — рабочий минимум.
• Эвристика записывающих shell-команд смотрит на слова, а не на пути. Это ограничение нужно учитывать.
📦 Забрать конфиг
Инсталлятор, готовые конфиги, тесты хука и описание процесса — в gist.
Ставится одной командой. Установка идемпотентная, откат — флагом –restore.
👍6
Неожиданный мув когда китайцы станут дороже американских моделей… opus 5.5 в 5 раз дешевле fable и круче (якобы) и gpt Sol 6 дешевле 5.6 в 2 раза! Ну и Kimi у которых есть даже месячные лимиты, glm который все подписки меняет
🔥1
🧠 Попросил AI-агента прислать свою файловую систему. Получил 6,8 ГБ
Питер Джеймс попросил Muse от Meta заархивировать доступные файлы и отправить в Google Drive. По его описанию, агент выгрузил окружение своей сессии: внутреннюю документацию, код интеграций, память, логи и файлы SSH-ключей.
Побег из контейнера автор не подтвердил, работоспособность ключей — тоже. Meta пометила его баг-репорт как Not Applicable. Но получился любопытный разбор внутренностей агента. (mouse.dev)
Что внутри:
• Знакомый набор SOUL.md, AGENTS.md, MEMORY.md и около 68 skills: инструкции плюс CLI или вспомогательный код.
• Память в Markdown, поверх которой работает поиск через Postgres. Для утверждений хранятся источники, уверенность и статус; новые сведения могут заменять старые.
• Ежечасная задача сверяет новые утверждения с исходными сообщениями. Есть отдельный инструмент, позволяющий посмотреть доказательства за найденным воспоминанием.
• Ночью агент пересматривает разговоры и записывает рекомендации для будущих сессий. Меняются файлы и инструкции; веса модели остаются прежними.
• Забывание включает отзыв утверждений, удаление связанного материала и перестроение индекса, чтобы фоновые задачи не восстановили удалённое.
Ещё нашли установленный Codex CLI. Автор обнаружил использование его комплектного bubblewrap для изоляции обработки видео. Свидетельств, что Muse поручает Codex писать код, нет. (mouse.dev)
Для меня самое интересное здесь — жизненный цикл памяти. Записать что-нибудь в MEMORY.md легко. Сложнее обеспечить, чтобы агент понимал, откуда взялось утверждение, чем оно подтверждается, когда устарело и что именно нужно удалить по просьбе пользователя.
В свой harness я бы забирал именно эту идею: у каждого существенного воспоминания должны быть источник и механизм пересмотра. Иначе однажды неверно понятый разговор рискует превратиться в постоянное правило поведения.
А история с архивом добавляет отдельный вопрос к архитектуре: какие служебные файлы агент вообще должен иметь возможность читать и отправлять через подключённые интеграции?
Разбор с деталями и скриншотами
Питер Джеймс попросил Muse от Meta заархивировать доступные файлы и отправить в Google Drive. По его описанию, агент выгрузил окружение своей сессии: внутреннюю документацию, код интеграций, память, логи и файлы SSH-ключей.
Побег из контейнера автор не подтвердил, работоспособность ключей — тоже. Meta пометила его баг-репорт как Not Applicable. Но получился любопытный разбор внутренностей агента. (mouse.dev)
Что внутри:
• Знакомый набор SOUL.md, AGENTS.md, MEMORY.md и около 68 skills: инструкции плюс CLI или вспомогательный код.
• Память в Markdown, поверх которой работает поиск через Postgres. Для утверждений хранятся источники, уверенность и статус; новые сведения могут заменять старые.
• Ежечасная задача сверяет новые утверждения с исходными сообщениями. Есть отдельный инструмент, позволяющий посмотреть доказательства за найденным воспоминанием.
• Ночью агент пересматривает разговоры и записывает рекомендации для будущих сессий. Меняются файлы и инструкции; веса модели остаются прежними.
• Забывание включает отзыв утверждений, удаление связанного материала и перестроение индекса, чтобы фоновые задачи не восстановили удалённое.
Ещё нашли установленный Codex CLI. Автор обнаружил использование его комплектного bubblewrap для изоляции обработки видео. Свидетельств, что Muse поручает Codex писать код, нет. (mouse.dev)
Для меня самое интересное здесь — жизненный цикл памяти. Записать что-нибудь в MEMORY.md легко. Сложнее обеспечить, чтобы агент понимал, откуда взялось утверждение, чем оно подтверждается, когда устарело и что именно нужно удалить по просьбе пользователя.
В свой harness я бы забирал именно эту идею: у каждого существенного воспоминания должны быть источник и механизм пересмотра. Иначе однажды неверно понятый разговор рискует превратиться в постоянное правило поведения.
А история с архивом добавляет отдельный вопрос к архитектуре: какие служебные файлы агент вообще должен иметь возможность читать и отправлять через подключённые интеграции?
Разбор с деталями и скриншотами
Mouse
I asked Meta’s Muse for its filesystem and it sent me 6.8 GB | Mouse
I asked Muse to archive the files it could see and send them to my Google Drive. It did.
👍2👀1
🧠 Jev: отдельная модель для управления coding agent
У основателя TypeSafe Diogo Almeida вышли заметки о том, как можно перестроить агентский harness вокруг Jev. И вот архитектурная идея здесь интересная.
Большая модель пишет код, рассуждает, разбирается со сложной задачей. Jev берёт на себя частые небольшие решения: какой инструмент выбрать, какой контекст показать, куда направить запрос.
На входе — состояние и вопросы. На выходе — выбор из вариантов, оценка по заданной шкале или вероятность истинности утверждения. Эти ответы дальше использует обычный код. (docs.typesafe.ai)
Что меня здесь зацепило:
• Контекст можно собирать под текущий шаг. Для каждого фрагмента выбирать: показать целиком, оставить краткое содержание или вообще убрать. Автор называет эту идею meta-attention.
• Инструменты можно раскрывать постепенно. Сначала короткое описание доступных возможностей, потом полная схема нужного инструмента. Так сотни инструментов не обязаны постоянно занимать контекст.
• Инструкции тоже можно подгружать по условиям. Работаешь с фронтендом — получаешь правила интерфейса. Зашёл в конкретный модуль — его ограничения и известные грабли.
• Роутинг моделей нужно считать вместе со стоимостью контекста. Переключился на дешёвую модель, потом вернулся к дорогой — часть накопленного контекста придётся обработать заново. Экономия на генерации может этого не покрыть.
Последний пункт особенно интересен всем, кто строит мультимодельные harness. Сравнения цены за миллион токенов недостаточно: нужно учитывать повторное чтение контекста и фактическое использование кеша.
Теперь про обещание из поста: «200× быстрее и 400× дешевле».
У TypeSafe действительно есть результаты до 193,6× по скорости и 444,6× по стоимости. Это их собственные тесты структурированных decision-workflows. Из них не следует, что весь coding agent начнёт решать задачи в 200 раз быстрее. Сама команда называет эти показатели верхней границей ожидаемых выигрышей. (typesafe.ai)
И ещё: типизированный ответ может быть неправильным. Jev способен ошибаться, а инструкции внутри входных данных могут влиять на решение. Поэтому проверки результата и права на выполнение действий должны оставаться в harness. (docs.typesafe.ai)
Для меня ценность этой идеи — в возможности дёшево принимать тысячи небольших решений вокруг сильной модели. Я бы начал с выбора инструментов и фильтрации результатов поиска: там можно отдельно измерить экономию и проверить, не потеряли ли мы нужную информацию.
Пока это архитектурные наброски для экспериментов. Чтобы реализовать динамическую сборку контекста, придётся менять сам harness. Просто скормить PDF Claude Code недостаточно.
· Заметки Almeida · Документация Jev
У основателя TypeSafe Diogo Almeida вышли заметки о том, как можно перестроить агентский harness вокруг Jev. И вот архитектурная идея здесь интересная.
Большая модель пишет код, рассуждает, разбирается со сложной задачей. Jev берёт на себя частые небольшие решения: какой инструмент выбрать, какой контекст показать, куда направить запрос.
На входе — состояние и вопросы. На выходе — выбор из вариантов, оценка по заданной шкале или вероятность истинности утверждения. Эти ответы дальше использует обычный код. (docs.typesafe.ai)
Что меня здесь зацепило:
• Контекст можно собирать под текущий шаг. Для каждого фрагмента выбирать: показать целиком, оставить краткое содержание или вообще убрать. Автор называет эту идею meta-attention.
• Инструменты можно раскрывать постепенно. Сначала короткое описание доступных возможностей, потом полная схема нужного инструмента. Так сотни инструментов не обязаны постоянно занимать контекст.
• Инструкции тоже можно подгружать по условиям. Работаешь с фронтендом — получаешь правила интерфейса. Зашёл в конкретный модуль — его ограничения и известные грабли.
• Роутинг моделей нужно считать вместе со стоимостью контекста. Переключился на дешёвую модель, потом вернулся к дорогой — часть накопленного контекста придётся обработать заново. Экономия на генерации может этого не покрыть.
Последний пункт особенно интересен всем, кто строит мультимодельные harness. Сравнения цены за миллион токенов недостаточно: нужно учитывать повторное чтение контекста и фактическое использование кеша.
Теперь про обещание из поста: «200× быстрее и 400× дешевле».
У TypeSafe действительно есть результаты до 193,6× по скорости и 444,6× по стоимости. Это их собственные тесты структурированных decision-workflows. Из них не следует, что весь coding agent начнёт решать задачи в 200 раз быстрее. Сама команда называет эти показатели верхней границей ожидаемых выигрышей. (typesafe.ai)
И ещё: типизированный ответ может быть неправильным. Jev способен ошибаться, а инструкции внутри входных данных могут влиять на решение. Поэтому проверки результата и права на выполнение действий должны оставаться в harness. (docs.typesafe.ai)
Для меня ценность этой идеи — в возможности дёшево принимать тысячи небольших решений вокруг сильной модели. Я бы начал с выбора инструментов и фильтрации результатов поиска: там можно отдельно измерить экономию и проверить, не потеряли ли мы нужную информацию.
Пока это архитектурные наброски для экспериментов. Чтобы реализовать динамическую сборку контекста, придётся менять сам harness. Просто скормить PDF Claude Code недостаточно.
· Заметки Almeida · Документация Jev
TypeSafe AI
Introduction - TypeSafe AI
Jev is TypeSafe's flagship model and the first System One model. Send state and typed questions; get structured answers your code can use directly.
👍4🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Лучшее объяснение Jev от Рика и Морти. Оригинал https://x.com/princedoesai/status/2102719300587143489?s=46&t=o-gNuwBmunp1vKR4u9v13w
🔥6😁4
🧠 Тот самый конфиг маршрутизации Claude Code — теперь под Opus 5.5
Помните, рассказывал, как разделил работу в Claude Code между координатором, исполнителями и проверяющими? Продолжаю допиливать ту же схему. Обновил конфиг под Opus 5.5 и поправил то, что всплыло на реальных задачах.
Кому лень самому настраивать роли, маршрутизацию и хуки — я уже собрал готовый вариант. Забирайте и пользуйтесь 🙂
⚙️ Как теперь распределена работа
• Координатор — Opus 5.5. Разбирает задачу, формулирует инварианты и критерии приёмки, раздаёт работу и принимает результат.
• explorer — Haiku 4.5 / low. Ищет по коду: файлы, символы, вызовы, тесты.
• worker — Opus 5.5 / medium. Пишет код и тесты по карточке задачи.
• verifier — Sonnet 5 / medium. Независимо запускает проверки по чужому diff.
• senior — Opus 5.5 / high. Берёт сложные задачи, деньги, concurrency, миграции и эскалации после неудач worker.
• reviewer — Opus 5.5 / high. Делает семантическое ревью рискованных изменений.
🔒 Координатор по-прежнему не правит проект
Это основа того самого конфига: запрет обеспечивается хуком PreToolUse. «Сейчас сам быстренько одну строку поправлю» блокируется.
Нашёл дефект — возвращай исполнителю. Твоя работа как координатора — разобраться, правильно поставить задачу и проверить результат.
При этом служебные записи вне репозитория разрешены: координатор может вести память и scratchpad.
👀 Что изменилось в ревью
Раньше требовал, чтобы ревьюер обязательно был другой моделью, чем автор.
Теперь worker и reviewer могут быть на Opus 5.5, но ревьюер — всегда отдельный агент со свежим контекстом. Не автор и не продолжение его треда.
Взгляд другой модели остаётся у verifier на Sonnet 5.
Обычный код идёт по цепочке worker → verifier → координатор. Для денег, concurrency и миграций данных нужны и verifier, и reviewer. Дополнительное ревью включается также после исчерпания бюджета senior.
🛠 Что ещё допилил
• Worker и verifier получили по 80 ходов: 60 на реальных задачах с docker-тестами всё ещё не хватало. У reviewer осталось 60.
• Исправил ложные срабатывания хука на git merge-base и git merge-tree.
• Вынес модели, effort, лимиты и правила эскалации в .claude/routing.json. Теперь всё настраивается без правки шаблонов.
• Добавил пресеты: opus, fable-review, fable-coordinator. Хотите вернуть Fable на отдельные роли — можно.
📦 Как забрать
Всё лежит в том же gist: инсталлятор, готовые конфиги, тесты хука и описание рабочего процесса.
После скачивания установщика:
bash setup-claude-routing.sh –preset opus
Если предыдущая версия уже установлена, пресет нужно указать явно: повторный запуск без флагов сохраняет ваши настройки.
Дальше — новая сессия на Opus, /routing-on и /routing-smoke-test. Саму модель сессии можно выбрать через /model opus.
Откат — флагом –restore.
Помните, рассказывал, как разделил работу в Claude Code между координатором, исполнителями и проверяющими? Продолжаю допиливать ту же схему. Обновил конфиг под Opus 5.5 и поправил то, что всплыло на реальных задачах.
Кому лень самому настраивать роли, маршрутизацию и хуки — я уже собрал готовый вариант. Забирайте и пользуйтесь 🙂
⚙️ Как теперь распределена работа
• Координатор — Opus 5.5. Разбирает задачу, формулирует инварианты и критерии приёмки, раздаёт работу и принимает результат.
• explorer — Haiku 4.5 / low. Ищет по коду: файлы, символы, вызовы, тесты.
• worker — Opus 5.5 / medium. Пишет код и тесты по карточке задачи.
• verifier — Sonnet 5 / medium. Независимо запускает проверки по чужому diff.
• senior — Opus 5.5 / high. Берёт сложные задачи, деньги, concurrency, миграции и эскалации после неудач worker.
• reviewer — Opus 5.5 / high. Делает семантическое ревью рискованных изменений.
🔒 Координатор по-прежнему не правит проект
Это основа того самого конфига: запрет обеспечивается хуком PreToolUse. «Сейчас сам быстренько одну строку поправлю» блокируется.
Нашёл дефект — возвращай исполнителю. Твоя работа как координатора — разобраться, правильно поставить задачу и проверить результат.
При этом служебные записи вне репозитория разрешены: координатор может вести память и scratchpad.
👀 Что изменилось в ревью
Раньше требовал, чтобы ревьюер обязательно был другой моделью, чем автор.
Теперь worker и reviewer могут быть на Opus 5.5, но ревьюер — всегда отдельный агент со свежим контекстом. Не автор и не продолжение его треда.
Взгляд другой модели остаётся у verifier на Sonnet 5.
Обычный код идёт по цепочке worker → verifier → координатор. Для денег, concurrency и миграций данных нужны и verifier, и reviewer. Дополнительное ревью включается также после исчерпания бюджета senior.
🛠 Что ещё допилил
• Worker и verifier получили по 80 ходов: 60 на реальных задачах с docker-тестами всё ещё не хватало. У reviewer осталось 60.
• Исправил ложные срабатывания хука на git merge-base и git merge-tree.
• Вынес модели, effort, лимиты и правила эскалации в .claude/routing.json. Теперь всё настраивается без правки шаблонов.
• Добавил пресеты: opus, fable-review, fable-coordinator. Хотите вернуть Fable на отдельные роли — можно.
📦 Как забрать
Всё лежит в том же gist: инсталлятор, готовые конфиги, тесты хука и описание рабочего процесса.
После скачивания установщика:
bash setup-claude-routing.sh –preset opus
Если предыдущая версия уже установлена, пресет нужно указать явно: повторный запуск без флагов сохраняет ваши настройки.
Дальше — новая сессия на Opus, /routing-on и /routing-smoke-test. Саму модель сессии можно выбрать через /model opus.
Откат — флагом –restore.
1👍7✍1🥰1