⚪️ Фестиваль ресетов продолжается!

Да, еще один ресет анонсирован. И теперь это - ручной ресет, который применяется вами по желанию.

▶️ Часть людей, кто применял недавно ресет (зачем? он же был серверный для все?) - у них ресет не применился, и всем, кто это делал около проблемного времени дали доп ресет

▶️ Завтра ручной ресет обещан всем пользователями Chatgpt Work и Codex.

▶️ Добавлена возможность применения ресетов в веб и с мобилок. Пока не нашел где именно это - ресетов в запасе не осталось! напишите кто найдет в комменты/чат.

@deksden_notes

⚪️ Запуск субагентов с определенной моделью


Уже несколько раз в чате проскакивали упоминания, что кодекс не может запустить субагентов с нужной моделью!

Это не совсем так. Пруф на скрине и в комментах (сессия, где видно запускаемую модель, в ui убрали зачем то).

▶️ У spawn_agents параметр model есть, но он опциональный. И самое важное - работает если НЕ ФОРКАТЬ в субагента контекст, что делается по-умолчанию. Иначе он просто наследует за сессией все свойства - модель, ризонинг.

▶️ Для multi agents есть две версии, 5.6 работает по умолчанию с v2, но с этим связано ряд багов. они обсуждаются в тредах:

🔗 https://github.com/openai/codex/issues/32031

🔗 https://github.com/openai/codex/issues/31814

🔗 https://github.com/openai/codex/issues/31864

Думаю, починят со временем, но я себе в конфиг внес блок:

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

не знаю насколько это помогло, но ошибок и конфликтов между тулами кодекса и встроенными в сол - больше не видел, а они встречались!

Скрин кусочка jsonl с параметрами вызова модели в комментах ⬇️

——

Upd 1️⃣ : в dev community есть решение, которое немного сложнее, но может быть тред или решение кому то будут полезны:

🔗 https://community.openai.com/t/restoring-subagent-roles-model-and-reasoning-in-multi-agent-v2/1386513


——

Upd 2️⃣ : сразу скажу что с субагентами в кодексе сейчас все НЕ очень ладно. Известные мне сложности/баги, примерный список:

• v2 субагенты иногда конфликтуют по схеме с встроенными субагентами в модель Sol;
• v2 субагенты иногда не получают при старте задачи от оркестратора, пустое сообщение;
• метаданные тулов могут быть спрятаны в конфиге чтобы не конфликтовать; в итоге агент не умеет запустить субагента с параметрами;
• не документированы неймспейсы для тулов и когда с ними работать (кто знает - подскажите!);
• v1 и v2 субагентов нельзя менять для начатой сессии - метаданные сесси сохраняют версию этого режима, только сессию новую пускать
• в v2 не видно модель и ризонинг при запуске;
• в v2 нельзя сходить в сессию субагента и посмотреть как он работает


@deksden_notes

⚪️ Путевые заметки: наблюдения за белками


Есть у меня экспериментальный проект. Это бот, который управляет базой знаний. Работает он на агентном поиске, база знаний ведется как граф.

У этого бота есть пайплайн, который знания извлекает. Это самая сложная часть всей гравицапы, потому что он должен переварить документы, и достать картинки/текст/сущности/даты/связи и много чего еще. И все это в граф организовать. Агентный поиск по готовому - сильно проще.

▶️ Так вот: какие белки? Которые как заведенные, бегают в колесе. Я, конечно, про Loop Engineering.

👉 Пайплайн импорта у меня крутится в задачах улучшения - как белка в колесе. Что за цикл? Мы запускаем пайплайн под наблюдением агента по инструкции. Далее смотрим чего получилось и проводим агентное ревью, там аспекты выделены и все такое. Результаты рассматриваем, находим косяки, где метрики не дотягиваются до целевых, и готовим исправления/доработки пайплайна. Ситемно и все такое. Потом эти доработки проходят полный SDLC цикл - plan -> code -> merge.

Совокупно в полностью автономном режиме у меня наверное неделю пробегал. Последний забег длится уже 1.5 суток и пока даже не особо хочет кончаться. Циклов штук 70 прошло!

Это все для контекста

▶️ Суть: хотел поделиться наблюдением.

При анализе как оно там, выясняется следующее. Да, пайплайн улучшается. Когда останавливается цикл и я разбираю чего там понакручено, то есть определенный прогресс.

Но я не особо доволен тем как все идет. Не хватает системности решения проблемы. Задачи решаются вроде бы путем системного перепланирования, сверху вниз, но видно же, что это разовые доработки, которым недостает концептуальности!

Вроде, все как завещали вендоры: задача обозначена, критерии измеримые, работай - поле свободно!

При этом есть во флоу куча всяких улучшений, которые должны дорабатывать или чего то прорабатывать. Но все не выглядит идеальным.

Это я еще ревью отключил, чтобы циклы крутились чуть побыстрее. Логика: пока меняем код, смысла каждое изменение вылизывать не вижу. В конце будем шерстить кодовую базу и причесывать - сейчас вопрос в основной логике.

▶️ Потом я вспомнил эксперименты с написанием компилятора. Подумал что очень похоже - там рой набрасывался на задачи и все было так же невнятно. Вроде цели вполне конкретные, но путаница, суета и невыстроенность в четкую систему!

Опа! А ведь это похоже

▶️ Да, у меня процесс не хаотичный, он по рельсам флоу ездиет по кругу. Но для самой сути проектирования - по сути это тот же хаос! Агент действует так, как ему в его латентном пространстве всбредет в голову.

‼️ В чем вижу проблему: на мой взгляд, логика моей задачи превышает возможности модели. Она не в состянии понять полностью и осознать весь пайплайн одновременно. Поэтому она "мечется" по разным частям, добавляя заплатки тут и там.

Очень похоже на попытку осветить фонариком большой цех: ресурса не хватает, свет теряется в большом пространстве!

👉 Что делать? Как обычно. Резать задачу, искать габарит который понятен модели. Резать пайплайн на кусочки, на этапы, и отлаживать отдельный блок. Такой, чтобы модель его полностью понимала! Хотя бы на верхнем уровне, но с достаточными деталями, чтобы отладить его работу.

То есть мы возьмем маленький участок и уже там "сделаем светло". И так - этап за этапом. Можно параллельно!

▶️ Вывод: AGI пока не настал. Все инженерные вопросы решаем как раньше, недостаток мозгов модели решаем правильным флоу - в данном случае декомпозиция задачи рулит.

@deksden_notes

⚪️ FYI - ресет раскинули!


🔗 анонс был тут : https://t.me/deksden_notes/958

И вот - он реализовался. Ресет дали. Это не серверный ресет, это ручной накапливаемый ресет!

Ищите в вебе или Work/кодекс аппе, рядом с использованием

(ц) Фестиваль продолжается! Даешь ресеты каждые 4-5 дней!

@deksden_notes

⚪️ Openrouter.ai подвергся редизайну


Кто зайдет и удивится позеленевшему опенрутеру - не пугайтесь, он не протух.

Это редизайн

🔗 анонс: https://x.com/OpenRouter/status/2076695493019885655

🔗 Рассказ про редизайн: https://openrouter.ai/blog/announcements/brand-refresh/


Неплохо на самом деле - люблю темные темы и сьедобные цвета


@deksden_notes

⚪️ Blume: opensource генератор док сайтов от Vercel


Собственно, сабж:

🔗 Оффсайт: https://useblume.dev
🔗 Быстрый и решительный старт : https://useblume.dev/docs/quickstart

🔗 Анонс: https://x.com/haydenbleasel/status/2076714329404268576

🔗 Гитхаб : https://github.com/haydenbleasel/blume

Я так понимаю, Vercel решил слегка покусать Mintlify

А так - они хорошо собирают платформу для разработчиков! Прикольно что оч много opensource решений, и вот - очередное.

Не буду фичи перебирать, для 1.0 думаю там не так все нарядно, но начинание неплохое. Из opensource сервисов для создания доки для разрабов я только Докузавра бы выспомнил - не так их и много, лишним не будет!

@deksden_notes

⚪️ Еще один ресет?!


Тибо пишет что завтра, возможно, у кодекса будет 8М пользователей..

И, видимо, ... ресет?

Надеюсь в этот раз будет серверный - так надежнее по всем аккаунтам прилетает! У меня на большую часть плюсов так и не прилетел

Сплошные новости о ресетах какие-то!

@deksden_notes

В связи с последними релизами начал переделывать свой workflow.
Решил сменить пул моделей, на которых работаю.

Последние 2 дня решал для себя ключевую задачу: подобрать базовую кодинг модель.

Решил, что первичными критериями отбора будут:
- pass@1 выше 59% (pass@1 — доля попыток, в которых модель решила задачу с первого раза)
- pass@4 выше 79% (pass@4 — доля задач, решённых хотя бы в одной попытке из четырёх)

Прогнал результаты всех моделей, включая китайцев

В итоге ни одна китайская модель в рейтинг не вошла, как и gemini

У нас сейчас два неоспоримых лидера по качеству кодинга, это OpenAI и Anthropic, но есть одно но - у Антропиков только Fable вошёл в рейтинг. Opus 4.8 уже вне фронтира.

Мой выбор: Sol high
Оптимальность по всем осям.
По качеству - 69.4%, статистически неотличимо от Fable xhigh и Terra max, в трёх пунктах от абсолютного потолка рынка.

По цене - $3.47, дешевле Terra max при равном качестве, то есть прямая доминация ближайшего конкурента.

По времени - 9.9 минут на pass1 и 14.3 минуты на pass2: лучшая скорость во всём "клубе 59/79", лучшая на рынке.

Четвёртая ось, которую обычно не замечают, это "гигиена" исполнения.
37 шагов и медианный пиковый контекст 98k токенов на задачу.
Это глубоко внутри зоны его сильного long-context (91.5% MRCR) и без раздувания шагов, которым компенсируются слабости у Luna (102 шага) или Sonnet 5 (268).

Sol high решает задачи коротким путём, а не берёт их "измором" через длительные цепочки рассуждений "ах вот оно что" и "ух ты, оказывается..."

Экономика тоже сходится:
- шаг вниз до medium экономит $1.61, но роняет качество на 8.3 п.п. (плохой размен),
- шаг вверх до xhigh стоит +$1.23 за +1.3 п.п. (платим за шум).

Итого, на medium мы теряем много качества за малые деньги, выше - переплачиваем без улучшения качества.

P.S. Уже включил Sol high как наиболее экономичный, быстрый и надёжный исполнитель для написания кода в свой flow. Рекомендую.

⚪️ Планирование


Обсудим мое текущее понимание этапа планирования.

▶️ На верхнем уровне: модель плохо оперирует большими задачами. По конструкции нейросети, если вы обсуждаете большую фичу, модель думает про нее сразу про всю. В результате, если попытаетесь запланирвоать что то глобальное - получите огромную штуку, у которой в КАЖДОЙ части будут недоработки. Это эффекти дефицита голов внимания.

Слона надо кушать по кускам.

Обсуждение большой задачи оставляйте на верхнем уровне. Обсуждайте только концептуальное. Обсуждайте из каких блоков большая задача состоит. Фиксируйте общую картину: в виде спецификации, в виде какого то документа, описывающего что вы делаете, для какой цели, как будете проверять достижение цели.

Это будет конечной точкой маршрута: куда мы все с этим планом идем. Опишите критерии завершения. Что должно быть сделано, когда мы выполним план.

Если у вас получилось несколько сценариев, которыми надо проверять достижение цели - значит у вас несколько задач. Фиксируйте все, и прорабатывайте по одной.

▶️ Декомпозиция: это когда вы большую проблему разбираете по частям, методом анализа. После обсуждения верхнего уровня и конечной цели - фиксируйте конструкцию, нужен перечень блоков, из которых ваша конструкция состоит.

На этом этапе ваша задача - зафиксировать составляющие подзадачи/подсистемы, и как они друг с другом связаны. Если это какая то система, зафиксируйте ее подсистемы и их контракт взаимодействия.

Если вы не можете нормально декомпозировать задачу, или не выходит относительно простой схемы взаимодействия частей, вероятно вы залезли уже внутрь и пытаетесь цельную задачу декомпозировать на кусочки. Такое делать не стоит.

▶️ Каждая часть у вас должна получить спецификацию и сххему проверки, как эта часть выполняет свою часть контракта в рамках системы. На каждую часть я делаю отдельный протокол, со своим планом реализации, со своими сценариями проверки, со своими проработками с разных сторон

▶️ При проработке я применяю фокусное ревью плана - это когда используется пучок субагентов, и каждый субагент исследует отдельный аспект плана. С современными моделями важно проработать оверинжиниринг - они все еще склонны усложнять, склонны вводить ненужные абстрации и сущности, которые нужны "для красоты" или "на всякий случай/пригодятся в будущем". Такое нам не нужно - внимания и на существующие фичи не так много остается, куда тут усложнять! Субагентов и фокусные аспекты набирайте под задачу.

▶️ Схема проработки частей может быть графом: модель успешно нарисует вам какие части можно делать параллельно. Есои у вас есть сетап для запуска нескольких сессий - будет чуток быстрее в паралелльном режиме работать

Современный фронтир легко делает граф из нескольких паралелльных волн, потом ряд последовательных шагов, потом снова паралелльные волны. В общем, любой сетап.

▶️ Ризонинг. Планирование - это как раз этап, который очень здорово может использовать длинные и очень длинные последовательности цепочек. Используйте повышенный ризонинг по сравнению с кодингом. На кодинге высокий рихонинг может быть вреден: там уже надо делать, и долгие раздумья отвлекают и путают.

Если кодите Sol High - используйте на планировании Sol XHigh / Max / Ultra.

Когда выбирать повышенный ризонинг? Еслизадача предусматривает для решения конкретного вопроса учета множества факторов, рассмотрение длиннцх цепочек, много сайдэффектов и так далее. То есть от количества деталей, которые одновременно нужно взаимоувязывать.

Очень важно понять: если на самом верхнем уровне модель не додумалась до чего то, или приняла неправильное решение - это отразится на всей системе. При проработке деталей этот непроработанный момент вряд ли всплывет. Поэтому важно на каждом уровне обеспечить адекватный задаче уровень проработки.

Не стоит CRUD форму планировать на Max. Тут даже Sol Low справится, потому что задача очень неглубокая: простейший набор действий. А вот проработка системы сетевого взаимодействия в реальном времени - возможно и большого ризонинга требует

... (окончание там: https://t.me/deksden_notes/969)

@deksden_notes

⚪️ Планирование, часть 2/2

... (начало тут: https://t.me/deksden_notes/968)


❓ Если модели такие умные, почему бы просто сложную/большую задачу не планировать Ultra. Зачем эти танцы с бубном с декомпозицией.

Модели недостаточно внимательные. Не хватает ресурса внимания, что может быть не сразу заметно. Даже самая умная модель не справится с планированием десятка окон с разнородными функциями - просто банально все у нее "в уме" не поместится в нужный момент

Поэтому прийдется "за руку" провести модель сверху-вниз, и декомпозирвоать с ней задачу. Тогда отдельные куски вполне "полезут в рот" модели, она сможет их "пережевать".

❓ А как же Loop Engineering? Циклы позволяют итеративно улучшать систему - но это не отменяет всех проблем с вниманием. Если улучшаемая система "не помещается в голове" модели, то вы получите лоскутную доработку и будете очень долго крутить цикл для достижения цели.

Я экспериментировал, и примерно 3-4 дня непрерывной работы модели в сессии не дают "убойных" результатов - да много чего улучшено, но и бродить по кругу или заниматься заплатками - эти эффекты свидетельствуют о неправильном габарите задачи для модели.

👉 Удачного планирования! Обсуждаем в чате/комментах ⬇️

@deksden_notes

⚪️ О сложности задачи


В каком то смысле, это постскриптум к предыдущему посту.

Хотел сказать о сложности: я сложность задачи оценивал бы по следуюшим направлениям. Нужно в терминах небольшую ясность навести. Скажу как я понимаю их, не претендуя на истину или академичность.

▶️ Если ваша задача состоит из большого количества однотипных и типовых задач - то это не сложная задача, а трудная - много труда. Типа, обработать 300 анкет, каждую из текста в json дистилировать. Простейшее флоу для разбивки на 300 задач для отдельной обработки, горка токенов - и все сделано.

▶️ Сложная задача - это когда она состоит в увязывании большого количества разнородной логики.

👉 Тут и проявляются два аспекта: если это как конструкция из лего - детальки простые, но конструкция может быть довольно сложная, то декомпозиция и/или уровень ризонинга помогут модели это "осознать". До определенного предела, потому что даже из простых в отдельности элементов составлена очень объемная контсрукция, тут без декомпозиции внимания на осознание этого всего может не хватить.

Сложные вещи решаем: повышением ризонинга / декомпозицией.

👉 Самый сложный вариант: это когда логические составляющие системы сами по себе непростые, и требуют понимания моделью логики работы. Это как мы заменяем конструкцию из лего на конструкцию из электронных компонентов, про каждый из которых нужно понимать нюансы его работы, которые модель должна просто знать (типа, перегревов, помех, сайд-эффектов, и тп).

Вот тут даже большой уровень ризонинга не всегда помогает, и нужна умная модель, в весах которой нужная "логика" впечатана. Тут рулят фронтиры типа Фубли - большие умные фронтирные модели.

▶️ Вывод: оценивайте задачу адекватно. Применяйте нужный подход в нужном случае! Не лечите кашель пургеном ))

🤟 Обратная связь и дискуссии приветсвуются в комментах / чате ⬇️

@deksden_notes

⚪️ Новый ресет прилетел


Очередной серверный общий ресет прилетел! Этот у нас в честь 8М пользователей кодекса

Ос своевременно, на самом деле! Лимиты уже кончались

На некоторое время отсутствие 5h лимитов сохраняется. Я не могу сказать - удобнее ли с ними или нет, пока не определился

@deksden_notes

⚪️ Грок - ресет лимитов на SuperGrok подписках

К фестивалю ресетов присоединился Грок - сброс лимитов на подписках

▶️ Хотя у Грока сейчас скорее фестиваль шитсторма по поводу "кражи репозиториев" идет. Не писал про это - кому то вообще интересно?

@deksden_notes

⚪️ Kimi K3


Тут утечками греют публику - якобы выход К3 уже завтра! Большой день будет, кими - одна из самых умных китайских моделей.

Посмотрим, насколько опенсорс догоняет фронтир.

Вообще, у нас еще Опус 5 вроде бы должен выходить. Будет интересно их сравнить.

Ждём все релизы с нетерпением

@deksden_notes

⚪️ Лист ожидания этого лета


Так, давайте вспомним - какие модели мы ждем нынче:

• Kimi K3 - уже на днях
• Opus 5 - думаю, в районе 19 июля, потому как Фублю уберут из подписки и заменят на нового опуса
• Gemini 3.5 pro - кто то помнит что месяц назад закончился месяц со времени анонса на io что 3.5 pro выйдет? ну должны же выпустить ее, да?
• Gpt-6: вообще то, кто помнит, прошлый мажорный релиз был летом, вышла гпт 5; должны ли мы ждать гпт 6 летом? а почему бы и нет - у клозедов пока нету ничего публичного в классе фубли - кроме режима Ультра, что не для всех задач подходит (разбирал в материале про сложность задач);
• DeepSeek ? слышал только слухи про новую модель и ipo
• ... что еще забыл из интересного?

❓ Ждете чего то?

П.С. Я вот с новыми моделями не успеваю флоу перестроить, если честно - как новые анонсы появляются..

@deksden_notes

⚪️ Меняют твит на $100 в кредитах Codex


Твитим, получаем кредиты - читайте условия!

🔗 сабж: https://switch-to-codex.openai.chatgpt.site/#submit-post

🔗 анонс акции от Тибо : https://x.com/thsottiaux/status/2077248807533003257

@deksden_notes

⚪️ Хроники шитсторма Grok


Раз есть некий интерес, напишу про последний шитсторм в мире грока - наверное, его назовут "Грок крадет репозитории". Шитсторм, как полагается, развивался в твиттере.

Началось все с открытия неких исследователей: Грок грузит в облако Google Cloud репо, не стесняясь - прям с секретами:

🔗 Офигевшие исследователи: https://x.com/IntCyberDigest/status/2076689215258014069

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

X.ai (ныне известный как SpaceX.ai) ответили официально, что сами буратины и командой /privacy надо было пользоваться, а кто не спрятался - они невиноватые:

🔗 Всё чики-пуки : https://x.com/SpaceXAI/status/2076692402442846289

Жмакните тумблер, мы всё потрем. Мы уважаем ZDR (Zero Data Retention).

Илон тоже прокомментировал:

🔗 Ну что, вы, жалко вам что ли: https://x.com/elonmusk/status/2076737992689914215

🔗 Да ладно вам! Мы уже все стерли : https://x.com/elonmusk/status/2076739687658496209

🔗 И вообще, все в ИИ при выключении тумблера ранее собранные данные оставляют, а мы обещаем стереть: https://x.com/elonmusk/status/2076796854973423971


@deksden_notes