LLM под капотом

Ачивка! ChatGPT обычный (не Codex!) идет самостоятельно исследовать и пилить агента для ECOM1. В небе над Берлином. Сейчас отправлю ему Claude Chat в помощь, чтобы под ногами путался.

Кому верить - Fable 5.1 или Astra 6? В этот четверг на двухчасовом воркшопе в Берлине (KanDDDinsky) я хочу попробовать упоротейшую вещь. Я хочу попробовать организовать незнакомцев (которые ни разу не AI инженеры и BitGN в глаза не видели) и их агентов в небольшую исследовательскую R&D лабу за два часа. Мы попытаемся совместно порешать задачки ECOM1 и открыть или придумать что-то новое за два часа. Причем ресурсы у группы будут ограничены - небольшая пачка ключей от OpenRouter, их собственные API ключи и подписки. Ну и доступ к POS MCP для координации. Все говорят, про создание AI Native компаний, оцифровку процессов и включение агентов с людьми в эту работу. Но пока мало кто говорит о том, чтобы это делать с нуля за два часа с группой из малознакомых людей и их разномастных агентов. Ну и не просто создать, а попробовать получить какой-то результат. Надо исправлять! Я понятия не имею, чем закончится подобный эксперимент. Fable 5.1 считает, что подготовить такое и провести - “Not realistic”. Astra говорит, что “Realistic as a tightly scoped workshop, but the preparation margin is thin”. Кому из них верить? Что бы ни/не получилось - потом расскажу. Ваш, @llm_under_hood 🤗

График моих экспериментов вокруг Personal OS с самого начала Список экспериментов есть тут. Началось все после декабря 2025 года, когда модели дозрели до того, чтобы кодексу можно было поручать достаточно долгие AI Coding задачи. Никто не замечает никакого тренда? Ваш, @llm_under_hood 🤗

Скилы или дерево документов? Alexey S провел небольшое сравнительное исследование подходов skills vs tree docs для кодовых проектов. Вот отчет, которым он сегодня поделился в группе летнего вебинара по AI Coding (выделение болдом - мое): Сравнил подход tree docs vs skills для нескольких маленьких проектов и для большого (fastapi). Сравнивал точность ответов и вызов подразумеваемых вопросом скиллов / доков при ответе на вопрос. tree docs побеждает буквально везде (и в клоде, и в кодексе). Также для клода выяснилось две неприятные особенности - когда вопросы утилитарного характера он напрочь забывает про скиллы и сразу лезет в код часто (в доках этого эффекта нет), зато с tree docs он тратит на 30 процентов больше токенов (в codex этого нет - налог на использование клод - судя по всему, перемудрили с тем, как размечают кэш). для маленьких проектов все отлично работает, по мере роста кодовой базы tree docs начинает выигрывать все заметнее > а tree docs самописный или утилита готовая? самописный, как в вебинаре - инструкция делать tree docs в AGENTS.md и инструкция как называть файлы чтобы из названия было понятно, про что они Еще неприятный момент с клодом - выяснилось, что он у тулов обрезает описания в контексте. Судя по всему там бюджет 1% от макст контекстного окна на скиллы - все что не влезает получает только название скила, без описания. При этом заранее непонятно, какие обрежутся - на скриншоте они по алфавиту, а обрезаны по какому-то другому признаку Progressive disclosure через tree docs подключается одной инструкцией в AGENTS.md:

Always run `tree docs` at the beginning to get an overview of durable documents. Before changing documentation read `document_writing.md`.

Пример document_writing.md скину в комментарии. Можете посмотреть сами и попробовать повторить исследование на своих проектах! Ваш, @llm_under_hood 🤗

Мы получили Claude Startups для BitGN! Anthropic - молодцы. До этого момента я не рассматривал Claude в качестве платформы для бизнеса, ибо Codex работает замечательно. А вот теперь есть пачка Team Premium подписок, которые можно применить к хорошему делу. Лимиты не должны простаивать! И вот теперь я сижу разбираюсь, как секурно подключить наш codemode сервер всем в команде под аккаунты Claude) Ваш, @llm_under_hood 🤗

Progressive Disclosure для MCP/API - экономия токенов в ~99% Я вчера писал про 12 итерацию эксперимента с Personal OS, где я упаковал весь интерфейс для работы агентов и людей с версионированными документами (аналог своего GitHub + markdown) в две команды для CLI/MCP: (1) start “task name” - начинает сессию и получает описание текущего SDK (2) run “Python script” Это позволило упаковать сложный функционал работы с документами, версиями в SDK. Агент начинает новую сессию, получает текущий SDK, видит его возможности и начинает писать код для выполнения задач. Код выполняется на сервере в песочнице (настоящей, а не контейнер) с ограничениями пользователя. Это позволило перестать, наконец, делать новый деплой серверов API-шек и всех клиентов на каждое улучшение тулзов. Я смог прогнать пяток экспериментов по оптимизации SDK (более удобные функции) и сократил время праздношатания агентов в два раза. А потом Дима @kuchin (спасибо тебе!) скинул ссылку на Cloudflare Code Mode, где сделали что-то подобное, только масштабом сильно больше - им надо было паковать 1M-2M токенов описывающих их 2549 AI tools. Благодаря progressive disclosure и Code Mode + SDK они смогли уменьшить расход токенов для типичных задач агентов этак раз в 1000, а число инструментов сократить до двух. И вот тут я понял, что с таким подходом у нас не просто появилась среда, которая чуть улучшает подход с shared git repo + markdown и позволяет людям с агентами быстро обмениваться информацией без риска что-то безвозвратно потерять. Теперь же можно в этот SDK вшивать процессы по работе с информацией в компании не словами, а кодом (например - как создавать инвойсы, где их хранить, откуда брать статистику, как версионировать), выкатывая новые версии SDK на лету (они подхватываются новыми сессиями агентов). И все это без опасения, что контекст моделек переполнится. Благодаря progressive disclosure, он как был в 1000 токенов, так и останется, даже если SDK вырастет до двух с половиной тысяч инструментов, как у Cloudflare. Теперь только остается осознать все открывающиеся возможности. Ваш, @llm_under_hood 🤗

Я мигрировал Personal OS с git repo на server-side RAG с песочницей История экспериментов с Personal OS: (1) первый эксперимент с Git+Obsidian - 8 февраля 2026 (2) Описание структуры Personal OS - 27 февраля (3) сравнение с LLM Wiki Karpathy - 5 апреля (4) субличность Марка - 23 Мая Эксперимент 12. Yggdrasil В Personal OS набралось полторы тысячи документов. Вчера я почти все с диска и перенес на сервер. Новый сервер - это самописный файловый сервер с отслеживанием версий. Он выполняет почти все мои хотелки из прошлого (кроме типизированных документов, ибо больше не важно) Основные различия по сравнению с git + Obsidian: (1) не нужно чехарды с git командами при работе. (2) в отличие от Notion и аналогов - изменения глобально версионированы (а не по файлам отдельно). Можно откатить изменение агента, даже если он поменял тысячу файлов в разных workspaces одновременно (3) у всех участников поиск работает одинаково (4) оно сразу заточено под одновременную работу нескольких человек с их агентами над общими материалами. Под капотом - golang + SQLite + CAS + MCP API 2.0 + CLI (ставится сразу в системную папку для Codex-a) + Borg Backup на удаленный сервер. Первые впечатления - стало проще работать с файлами. Можно отправить агента завести себе workspace, не задумываясь про git push/pull итп. И можно не держать в голове текущее состояние git папок при работе. Если агент сказал, что сохранил транскрипт разговора с выжимкой, значит он уже лежит там и доступен всем. Про конфликты от одновременной работы можно не беспокоиться, откаты изменений есть. Но в минус - агенты находят документы быстрее, но стали дольше копошиться с их изменением. Оказывается, когда файлы лежат где-то там, их нельзя так просто взять и изменить. У Sol 6.1 уходило 6 c половиной минут на то, чтобы отработать такой запрос: > hey, capture that latest exchange with Aigiz into Bragi (continuing our last conversation)... (Под капотом Марк должен подключиться к серверу, найти нужный workspace, понять принципы организации capture/distill/arks, подшить куда надо, немного перелопачивая файл на 70kb, собрать изменение и смерджить его) Поэтому пришлось поставить ряд экспериментов в поиске tool calling интерфейса, который бы позволил кодексу решать эту RAG задачу быстрее. Самое забавное, что этот интерфейс оказался питоном. Вместо того, чтобы тягать файлы c сервера туда-сюда (удачи со случаем, когда мы делаем replace по папке), агент пишет маленький скрипт, который отправляется на сервер и в изолированной песочнице работает с изменениями в рамках сессии там. То есть не нужно мучаться с придумыванием оптимальных инструментов для MCP/API/CLI, когда можно сказать “писать питон вот сюда, вот тебе описание SDK”. В итоге теперь аналогичная задача выполняется Sol 6.1 без лишних танцев с бубнами за три с половиной минуты. Причем половина времени тратится на RAG задачи, а вторая - на написание текста. Заодно я смог выкинуть из MCP API и CLI все инструменты и команды кроме двух - start (начать новую сессию/commit и получить в контекст описание текущего SDK) и run (запустить питон на сервере). В общем, если у вас у какой-то AI Native системы получается сложный интерфейс с кучей API-шек и инструментов - попробуйте просто дать агентам Python, благо инструментов для этого есть море, от jails до Firecracker VM. Ваш, @llm_under_hood 🤗

BitGN ECOM2 будет в ноябре, а песочницу откроем в октябре Напомню, что это соревнование, где нужно построить лучшего агента, способного решать задачи в симуляторе. Можно будет и нужно пользоваться уроками и лучшими агентами предыдущих соревнований (см Insights). Задачи мы берем на основе реальных кейсов, лучшие архитектуры взлетают в лидербордах, а их создатели обычно потом подробно про них рассказывают. Причем агенты получаются настолько хорошие, что их потом разбирают на части и запускают в международных банках. А за их участниками потом охотятся с целью нанять или получить консультацию. Ветераны этого коммьюнити знают все эти истории 🤗 В ECOM2 будет два принципиальных отличия от предыдущих соревнований. Во-первых, запускать агента мы будем с виртуальным кошельком (за токены надо платить), чтобы был стимул оптимизировать агентов под баланс эффективности и стоимости (отлаживаете со своим OpenRouter ключом, а на соревнование предоставляем кошелек). Во-вторых, запускать агентов будем в обучающей среде BitGN Mesh. Она создается для того, чтобы было удобно запускать агентов, отлаживать их и делиться результатами. Ну и так проще посчитать расход токенов. А еще там можно делать веселые вещи вроде запуска семейств агентов, пересылок между ними сообщений и перевода кредитов. Причем агент может отправить кредитов или сообщение любому агенту, даже не обязательно в своем аккаунте. Агент может накодить себе инструментов или нового агента и начать рулить ими. Возможно, экономика агентов - это будущее. Во всяком случае, деньги туда вкладываются немаленькие. Поэтому мы делаем BitGN ECOM2 про экономику агентов со средой, где это будущее можно пощупать, поиграть, потренироваться и поучиться! NB: Кошельки в соревновании будут виртуальные (игровые). Песочницу открою во второй половине октября, чтобы у вас были время и возможность сломать все, что только возможно - заранее, а не как это было в PAC1. Кому такое интересно?) Ваш, @llm_under_hood 🤗

Самая классная фишка современности - многие достижения других можно копировать. Пару дней назад утром я посмотрел сам OpenAI Dev Days Keynote (чего и вам советовал). Они там, помимо всяких продуктовых фич, упоминают все те космические технологии, которые у них используются в разработке. Коллаборация с агентами, долгие исследования, самостоятельность. А у меня пока только есть мой Codex с персональным ассистентом в виде Obsidian реп c markdown файламив гите. Ну и приложение-клон миро. Но так было до просмотра OpenAI Dev Days. Но в тот же день на одном вдохновении после просмотре получилось дать Марку/Кодексу возможность ходить и одновременно со мной работать над досками (мой эквивалент Miro). Если что-то меняем одновременно, то конфликт ловит он)) Для этого сделал API в приложении и к нему допилил CLI по принципам, на которых работают CLI инструменты в BitGN А потом отправил исследовать проблему запуска тысяч агентов для BitGN ECOM2. Отправная точка - Firecracker VM с COW memory snapshotting и отслеживанием дель на базе dirty pages от базового образа. Агент ведет исследования в Codex, параллельно загружая на доску свои эксперименты, графики и выводы. Эта доска помогает мне быть в курсе и заодно служит ему структурированной памятью, которую я могу менять. Если интересно - могу скинуть скриншоты досок в комментарии. В итоге этих эуспериментов получается уже интересная концепция песочницы для ECOM2, где я могу не переживать, что у меня запустят параллельно 100000 агентов и уронят все сервера (запускать столько можно, а уронить уже будет сложнее). И заодно становится проще демонстрировать принципы построения агентных архитектур для бизнеса. Но самый главный посыл - можно внимательно смотреть на достижения топовых компаний и копировать их фишки у себя. Ваш, @llm_under_hood 🤗

Как вы думаете, справится Codex c такой задачей? Вот я сейчас запустил задачу, где прошу написать Codex минимальный прототип песочницы для агентов с интегрированной экономикой с нуля (кошелек, плата за LLM и выдача денег за решение задач). Нужно использовать FirecrackerVM c кастомными образами, vsock соединение из виртуалки через sidecar, доказать работу suspend/resume. Сказал, что может это делать на домашнем сервере. Справится ли с первого раза, и сколько на это уйдет времени? Ваш, @llm_under_hood 🤗

Обязательно смотрим OpenAI DevDays сами! Те выжимки, которые есть в куче каналов - фокусируются чисто на инженерных примочках и пропускают кучу интересных нюансов. Скажем - OpenAI упрощает выкатку приложений в свой marketplace и позволяет компаниям оплачивать эти приложения из своих существующих бюджетов на OpenAI. Это же прямой доступ к куче корпоративных бюджетов! Ну и плюс видно, как OpenAI создает себе новый рынок. Или про то, что Decisions API уже внедряется у них в Computer Use для значительного ускорения (значит, это направление будут и дальше развивать). Или что dots / Codex / Agents API - это один и тот же тип агента. Жду не дождусь, когда смогу запустить Personal OS в облаке под dots инфраструктурой. Я пересмотрел сегодня утром, вдохновившись настроем и мелкими нюансами, которые проскальзывают в выступлениях. А потом сделал впервые для себя такую фишку. Мне Codex недавно написал свой аналог Miro для работы с диаграммками, схемами и слайдами - Wire. Это нативное MacOS приложение, с API (для одновременной работы) и CLI. Сегодня, пока планировал режим BitGN Sandbox для ECOM2, я обсуждал его в Codex с Марком плюс набрасывал схему в Wire. А потом сказал агенту - глянуть на схему своими глазами и предложить изменения. Агент подключился напрямую к приложению (без Computer Use - т.е. быстрее и без перетягивания экрана), высказал поправки и рядом набросал новую схемку. И все это пока я в кодексе делал что-то другое. По ощущениям это напоминает старое доброе парное программирование. Только гораздо быстрее) Теперь подобный режим работы буду встраивать во все новые приложения из коробки! Ваш, @llm_under_hood 🤗

Что нового в разработке продуктов с LLM под капотом? Раньше я много писал про кейсы продуктов с LLM под капотом (вот тут есть оглавление с разбором архитектур) Я плотно поработал с этими кейсами несколько лет подряд, записивал истории успехов и провалов команд, структурировал, а дальше вы все знаете. Потом эти кейсы отошли на второй план, т.к. принципиально новых и интересных задач у бизнеса (с практической внедряемостью) с тех пор не появлялось. Это все из-за того, что тормозят не технологии, а компании (чем крупнее и старше компания, тем медленнее она может меняться). Вчера меня спросили про старый тип кейса, на что я ответил, что все работает как и было расписано в курсе, ничего нового не появлялось. Ответ заставил меня задуматься

“Думал может какие то новые подходы появились про которые я не знаю)”

И в самом деле. Что-то же должно было поменяться. Вон, какой прогресс в LLM-ках. А как бы я делал кейс со спасением проекта сейчас в 2026 году? Что вообще поменялось в практических бизнес-внедрениях сейчас? Как можно лучше и быстрее решить эту задачу сегодня? Так вот. Архитектура решения и подходы не поменялись совсем. Все работает так же, как я описывал в истории в канале, рассказывал на выступлении KanDDDinsky или разбирал в курсе. Работающие архитектуры и их экономика остаются прежними: Quality is a trajectory, evals, Schema-Guided Reasoning, Feedback loops, hallucination triggers, переезды на недорогие модели и тому подобное. Но сегодня этот быстрый кейс можно было бы сделать гораздо быстрее. Не за 6 дней с командой из QA, а гораздо быстрее. С командой из пары человек. Просто потому, что меняется экономика того, как мы можем работать с информацией и прийти к результату. Если в прошлом году много всего нужно было делать вручную, то сегодня путь от постановки задачи до первого исследования можно пройти за 14 минут и 7 секунд. Этого времени мне не хватило, чтобы написать этот пост. Но зато вот General-purpose агент Codex GPT-6 (который только притворяется инструментом для AI Coding) подключился к архиву кейсов и сделал исследование о возможности извлечения данных для Heavy Duty Pressure Transducers, с PDF, скриптами и предварительно размеченными данными. Говорит, что дальше ему нужно полчаса моего времени как человеческого эксперта, а дальше он сам разметит eval dataset. Ну а пайплайн и эксперименты с моделями - это вообще ерунда. Главное, просит, в ключевые моменты feedback предоставлять. То есть в 2026 результат реализации проектов с LLM под капотом не поменялся. Это те же архитектуры, эвалы и подходы. Просто поменялась экономика (стало сильно дешевле, нужно меньше специалистов) и фокус внимания (голова меньше болит). Ваш, @llm_under_hood 🤗

Бенчмарк GPT-6.1 Sol - аналогичное качество за меньшие деньги А еще Sonnet 5.5 и Opus 5.5 Sol 6.1 на бенчмарках (на датасетах agentic trajectories из BitGN) по качеству примерно на уровне Sol 6.0 High, но заметно дешевле и немного быстрее. Прорыва по качеству нет, но есть небольшое и стабильное снижение стоимости за то же качество. Это немного сдвигает AI фронтир вправо. Почему Sol 6.1 Low работает чуть лучше High + Med - сложно сказать. У меня есть подозрение, что отключение reasoning благоприятно влияет на Schema-Guided Reasoning. Аналогичное, если помните, было с моделями вроде GPT-oss-120B, когда они только выходили и начинали дружить с constrained decoding. Я из интереса перезапустил бенчмарк 6.1 - ответы были точно такие же. Самое главное - если у вас используется SGR - попробуйте Sol 6.1 Low для экономии денег. Что же касается Sonnet 5.5. + Opus 5.5 - это две синие точки в самой глубине освоенного фронтира. Последние модели от Anthropic - абсолютные лидеры среди всех моделей в области числа fatal refusals (отказов выдавать ответ). Причем: (1) у Sonnet 5.5 был бы шанс подовинуть фронтир по скорости и качеству, если бы не эта особенность. (2) Opus 5 + Sonnet 5 еще работали нормально, а беда с моделями Anthropic началась после выхода Fable Кстати, зона покрытия фронтира - это прогресс развития моделей в области качества за деньги и качества при скорости с июля этого года. Состояние этого фронтира и отчет за июль 2026 (с большим числом подробностей про бенчмарк) мы опубликовали на сайте BitGN. Отчет на текущий момент тоже скоро планируется. Ваш, @llm_under_hood 🤗

Зачем изобретать велосипеды?

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

Это было комментарием на мое замечание, что я писал markdown редактор для себя. Давайте объясню зачем мне такое. Итак, я Ринат Абдуллин. 20+ лет работаю с кодом и с компаниями в EU/USA. Веду достаточно сложные и временами высоконагруженные продукты (про что пишу в этом канале, в блоге и рассылке), еще веду распределенный R&D в области AI агентов (вместе с потрясающим коммьюнити инженеров вокруг BitGN), иногда провожу курсы и тренинги. Для актуализации навыков и качественного преподавания мне нужно не просто разрабатывать сложные и высоконагруженные продукты. Для последнего вообще особо заморачиваться не нужно - просто берешь стабильные технологии старше пары лет и грабель горя не знаешь. Нет, тут надо еще следить за состоянием технологий прямо сейчас. Что они могут, где у них сильные места, а где слабые. Причем следить нужно не теоретически, почитывая каналы и статьи, а на практике. Это позволяет интернализовать навыки, пропускать их через призму своего опыта и перекладывать все самое важное на учебный материал. Поэтому у меня есть концепция Katas - упражнений, которые позволяют отточить навыки и мастерство. А в случае с быстро изменяющимися технологиями заодно и сверить часы с реальностью - не упустил ли я что-то еще. Термин “ката” берет свое начало из боевых искусств, где нужно тысячи раз медленно отрабатывать какой-то навык, чтобы отладить его и довести до автоматизма. Это обязательная часть совершенствования как ученика, так и мастера. Подход применим и к IT. Например, в TimeToAct я вел katas в области Domain-Driven Design, симуляций и Machine Learning. Эти упражнения начались как внутреннее обучение в компании, чтобы прокачивать какие-то навыки, а потом мы их открыли для всех. Люди просто начали присылать свои решения и требовать еще задания (ибо каты делаются как маленькие упражнения, на которые не нужно много времени). Причем это было в эру до ChatGPT, когда все еще нужно было печатать код вручную. Написание своего markdown редактора или эквивалента Miro (по очень конкретным требованиям) - это мой вариант katas для AI Native coding. Он позволяет отточить навык на последних технологиях без существенных затрат времени. Заодно и проверяю снова и снова, а как быстро можно натянуть актуальные принципы разработки на "замусоренное" решением, что работает лучше с последней версией модели, а что хуже. И когда меня спросят в лайве "А правда, что GPT-6 Astra - это мусор?" или "А что самое важное для AI Native проекта в сентябре 2026 года?" - я смогу ответить системно, просто и обоснованно. Ну а то, что в процессе продвигается вперед R&D в области разработки и personal productivity - это приятный бонус. Ваш, @llm_under_hood 🤗

Семь месяцев работы с Codex-ом в одном графике Это иллюстрация из моего поста про последние семь месяцев работы. Я там упоминаю все вещи и эксперименты, которые стали частью повседневной жизни. Провалившихся экспериментов, конечно, было сильно больше. Их я не упоминаю, т.к. стоимость эксперимента сейчас заметно снизилась. Вот прямо сейчас пишу себе свой markdown writer, ибо есть у меня одна очередная идея. Ваш, @llm_under_hood 🤗

Период полураспада софта - 3 месяца Я сейчас возвращаюсь к сайту BitGN, чтобы начать подготовку к соревнованию ECOM2 (agentic economy), добавить место для публикации LLM бенчмарков и в целом обновить дизайн. В этот код я давно не ходил, и он ну очень дремучий - эпохи где-то до декабря 2025 года, когда Codex расцвел. Современным стандартам AI Native разработки совсем не соответствует. Агенты спотыкаются часто (даже Astra), предлагают ерунду, прямо за ручку надо держать. А потом я восстановил хронологию и сильно удивился. Я же ушел из TimeToAct в феврале этого года, чтобы начать делать платформу для бенчмарков агентов. Этой весной мы с COLIBRIX провели два соревнования, с тех пор 2.8M задач выполнено агентами на платформе. И выходит, что возраст кода BitGN не “вечность” - а всего 7 месяцев от начала разработки. Причем в последний раз я туда активно ходил всего три месяца назад. За это время настолько улучшилось как качество современных AI code агентов, так и наше понимание об их эффективном использовании, что проекты быстро начинают казаться постаревшими. В общем, если кажется, что софт теперь стареет быстрее - это иллюзия. Код как преспокойно лежал себе в Git-e, так и лежит там. Это просто так быстро улучшаются наши ожидания о работе с AI Coding агентами. Ваш, @llm_under_hood 🤗

У вас == лично, или в компании

GPT-6 Sol и Luna - бенчмарк цены, качества и скорости А еще Opus 5.5 и Astra 6 (medium). Все это - на нашем датасете BitGN запусков агентов в бизнес-задачах. Серая линия на графиках - старый фронтир моделей от июля (соотношение точности к цене и качеству). Захваченная розовая территория - насколько новые модели смогли пододвинуть этот фронтир вперед с июля. Сначала отдельно похвалю Kimi K3, которая заняла второе место по точности, пусть и оказалась слишком медленной и дорогой по сравнению с другими моделями. А вот GPT-6 фронтир пододвинули сильно. GPT-6 Sol (high) - в топах. А еще это первая модель, которая выбила все 100% на AI coding задачах. После ECOM2 наберем новых edge cases в бенчмарк. Более того, Sol - это не только самая лучшая модель за свои деньги, но и самая быстрая модель с таким качеством! GPT-6 Luna (high/med) пододвинули фронтир по стоимости. Astra 6 (medium) по сравнению с этими моделями плетется в хвосте (больно дорого и медленно) Claude Opus 5.5 на 26 месте, ибо модель нередко отказывается отвечать (API возвращает отказы). Но при этом два прокола безопасности через эту модель протащить удалось. В общем, Sol 6 и Luna 6 - новые рабочие лошадки. Можно смело переключать агентов на них. Но больше успехов конкретных моделей меня радует наглядный прогресс с июля в доступном качестве за все меньшие деньги. Ваш, @llm_under_hood 🤗

Доклад про DDD + AI в проектах (Berlin, 2025, EN) Не прошло и года с прошлого KanDDDinsky, как на YouTube выложили видео с моим выступлением с этой конференции: "When DDD Met AI: Practical Stories from Enterprise Trenches" Если во время записи кажется, что я периодически кошусь в одно место в зале - это не кажется. Там сидит Eric Evans, который обещал быть самым полным энтузиазма слушателем) Кстати, на KanDDDinsky в этом году (это будет 15 октября) я проведу двухчасовой hands-on на тему "Engineering trustworthy and testable AI agent". Кто-нибудь будет на этой конференции? А еще, кто-нибудь хочет устроить встречу LLM под капотом в Берлине вечером 14го или 15го октября? Ваш, @llm_under_hood 🤗

LLM Benchmark Jev - топ для простых задач Jev - это новая LLM модель, в которую встроили Schema-Guided Reasoning, превратив в гибкий классификатор по шаблону. Jev не может генерировать тексты, но может на лету выбирать из предложенных вариантов. Поэтому модель можно использовать в задачах вроде классификации входящей почты, проверки запросов на красные флаги. Главное - не делать задачу слишком сложной. А вот насколько сложные задачи сложны для Jev? Мне стало интересно, и я адаптировал агентский бенчмарк BitGN, выбрав оттуда те задачи, которые можно свести к задачам классификации. Это разовый бенчмарк, который создан исключительно для Jev, чтобы можно было примерно прикидывать его когнитивные способности - насколько сложные задачи можно давать на вход. Понятно, что Jev не сравниться с нормальными LLM по гибкости и мощности (там даже Loop/Cascade из SGR толком не сделаешь), но вот в качестве узкоспециализированного инструмента под ряд задач - это стоящий вариант. И получается очень приятная картина - Jev на 14 месте, причем работает очень быстро и стоит сущие копейки. В данном бенчмарке задачи за пределами возможностей Jev. А если давать ему задачи “по плечу”, то картина получается еще красивее. Айгиз написал статью для TimeToAct как раз про такие задачи. Будем ждать новых гибридных моделей, которые могут работать по SGR подходам. Причем делать это без двойной работы через JSON Schema + inference + constrained decoding (то есть работать быстрее и дешевле). Ваш, @llm_under_hood 🤗