⚪️ GLM 5.2 релиз
На фоне обсуждения новости о блокировке Фубли (американское правительство по соображениям безопасности приказало антропикам не предоставлять доступ к последнй модели иностранным гражданам, а антропик не имеет возможности фильтра по гражданству, пока, - и отрубило доступ всем) - новый релиз выглядит интересным.
Блога про 5.2 с бенчмарками пока нету, буду дополнять пост как появится.
Из интересного: появился контекст на 1m токенов. Уровень размышлений - или high, или max.
🔗 Как правильно апгрейдить в СС на 5.2: https://docs.z.ai/devpack/latest-model
——
Upd 1️⃣ : Наконец то опубликован блог с бенчами про глм 5.2. Отличный и подробный блог. Бенчи, как водятся, достойные
В чат модель тоже добавлена.
🔗 Блог : https://z.ai/blog/glm-5.2
🔗 Анонс: https://x.com/Zai_org/status/2066938937344495629
(ц) в интересное время живём!
На фоне обсуждения новости о блокировке Фубли (американское правительство по соображениям безопасности приказало антропикам не предоставлять доступ к последнй модели иностранным гражданам, а антропик не имеет возможности фильтра по гражданству, пока, - и отрубило доступ всем) - новый релиз выглядит интересным.
Блога про 5.2 с бенчмарками пока нету, буду дополнять пост как появится.
Из интересного: появился контекст на 1m токенов. Уровень размышлений - или high, или max.
🔗 Как правильно апгрейдить в СС на 5.2: https://docs.z.ai/devpack/latest-model
——
Upd 1️⃣ : Наконец то опубликован блог с бенчами про глм 5.2. Отличный и подробный блог. Бенчи, как водятся, достойные
В чат модель тоже добавлена.
🔗 Блог : https://z.ai/blog/glm-5.2
🔗 Анонс: https://x.com/Zai_org/status/2066938937344495629
(ц) в интересное время живём!
🔥18👍11
⚪️ Кешбек токенами
Интересную новость прочитал, не мог не поделиться:
🔗 Новость: https://t.me/ai_machinelearning_big_data/10317
В Китае вводят кешбек токенами Кими. Причем, госбанк, что немного необычно - это же вроде консервативные организации.
Вижу несколько выводов:
• ИИ становится частью "большой" экономики
• ИИ довольно близко к государству, раз госбанки в теме, и явно носит стратегический характер
В общем, к сожалению, времена "дикого" развития ИИ, похоже, подходят к концу. Ждем ИИ "по госуслугам", и прочие фокусы регулирования - с некоторой печалью.
(ц) хроники интересного времени
Интересную новость прочитал, не мог не поделиться:
🔗 Новость: https://t.me/ai_machinelearning_big_data/10317
В Китае вводят кешбек токенами Кими. Причем, госбанк, что немного необычно - это же вроде консервативные организации.
Вижу несколько выводов:
• ИИ становится частью "большой" экономики
• ИИ довольно близко к государству, раз госбанки в теме, и явно носит стратегический характер
В общем, к сожалению, времена "дикого" развития ИИ, похоже, подходят к концу. Ждем ИИ "по госуслугам", и прочие фокусы регулирования - с некоторой печалью.
(ц) хроники интересного времени
❤6😢6🔥3
⚪️ OpenRouter Fusion
Интересную штуку сделали OpenRouter - Fusion называется. Работает так: есть "модель" openrouter/fusion который выглядит как обычная модель. Внутри вы настраиваете основную модель, которая генерирует итоговый ответ, а также "панель моделей". Рутер именно такой термин использует, а по мне он весьма смешной, "модели на панели". Но альтернативы которые я слышал - это "ансамбль" моделей (весьма отдает фрактальным промптингом), ну или "совет" моделей. Хорошего русского прижившегося термина нету. Пусть будет "панель".
В панель вы можете включить несколько моделей, по умолчагнию - три штуки, максимум - 8. Они получают задание от вашей главной модели через вызов тула openrouter:fusion, можно сделать вызов обязательным.
Тул openrouter:fusion исполняется так: fan out агентный запрос, параллельно каждая модель из панели выполняет запрос, ей выданы инструменты openrouter:web_search , openrouter:web_fetch, дан бюджет на количество ходов и вызовов тулов, установлен ризонинг и температура. Рекурсию делать нельзя.
потом делаем fan in на модель-судью. Судья НЕ ПРОСТО делает синтез ответа - он возвращает структурированный ответ: в чем модели согласились, где были спорные моменты, инсайты из ответов каждой модели и слепые зоны, которрые остались не покрыты никем. Также возвращаются полны еиндивидуальные ответы. Я бы сказал, что это ответ не судьи, а структурированный отчет.
🔗 Попробовать плейграунд: https://openrouter.ai/fusion
🔗 Почитать про fusion "модель": https://openrouter.ai/docs/guides/routing/routers/fusion-router
🔗 Серверный тул fusion : https://openrouter.ai/docs/guides/features/server-tools/fusion
Итак, опенроутер изобрел мульти-модель. Т акими темпами они еще и до мульти-семплинга дойдут, и до фокусной аспектной проработки. Но - не все сразу, да?)
Результаты: на мой взгляд, охренительно. Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro (fusion) дают результаты чуть хуже Falbe 5 solo (замеры на DRACO deep research benchmark by Perplexity) - график на картинке КДПВ.
🔗 Про бенчмарк: https://arxiv.org/abs/2602.11685
Ценник очевиден: 1 модель синтезирует ответ, 3 модели дают ответы в панели, 1 модель судит. Итого х5 цены! но при текущей разнице фронтира и китов - панель китов на 50% дешевле фубли выходила.
Мне понравилась идея прятать систему за модулью через роутер. Задумался))
(ц) оч интересно
@deksden_notes
Интересную штуку сделали OpenRouter - Fusion называется. Работает так: есть "модель" openrouter/fusion который выглядит как обычная модель. Внутри вы настраиваете основную модель, которая генерирует итоговый ответ, а также "панель моделей". Рутер именно такой термин использует, а по мне он весьма смешной, "модели на панели". Но альтернативы которые я слышал - это "ансамбль" моделей (весьма отдает фрактальным промптингом), ну или "совет" моделей. Хорошего русского прижившегося термина нету. Пусть будет "панель".
В панель вы можете включить несколько моделей, по умолчагнию - три штуки, максимум - 8. Они получают задание от вашей главной модели через вызов тула openrouter:fusion, можно сделать вызов обязательным.
Тул openrouter:fusion исполняется так: fan out агентный запрос, параллельно каждая модель из панели выполняет запрос, ей выданы инструменты openrouter:web_search , openrouter:web_fetch, дан бюджет на количество ходов и вызовов тулов, установлен ризонинг и температура. Рекурсию делать нельзя.
потом делаем fan in на модель-судью. Судья НЕ ПРОСТО делает синтез ответа - он возвращает структурированный ответ: в чем модели согласились, где были спорные моменты, инсайты из ответов каждой модели и слепые зоны, которрые остались не покрыты никем. Также возвращаются полны еиндивидуальные ответы. Я бы сказал, что это ответ не судьи, а структурированный отчет.
🔗 Попробовать плейграунд: https://openrouter.ai/fusion
🔗 Почитать про fusion "модель": https://openrouter.ai/docs/guides/routing/routers/fusion-router
🔗 Серверный тул fusion : https://openrouter.ai/docs/guides/features/server-tools/fusion
Итак, опенроутер изобрел мульти-модель. Т акими темпами они еще и до мульти-семплинга дойдут, и до фокусной аспектной проработки. Но - не все сразу, да?)
Результаты: на мой взгляд, охренительно. Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro (fusion) дают результаты чуть хуже Falbe 5 solo (замеры на DRACO deep research benchmark by Perplexity) - график на картинке КДПВ.
🔗 Про бенчмарк: https://arxiv.org/abs/2602.11685
Ценник очевиден: 1 модель синтезирует ответ, 3 модели дают ответы в панели, 1 модель судит. Итого х5 цены! но при текущей разнице фронтира и китов - панель китов на 50% дешевле фубли выходила.
Мне понравилась идея прятать систему за модулью через роутер. Задумался))
(ц) оч интересно
@deksden_notes
1🔥25👍10❤4
Forwarded from ABI
Обновление bash-скрипта для кастомизации статус-бара в Antigravity CLI. 🚀
Интерфейс там консольный (TUI), поэтому раскрасить вывод ANSI-кодами не вышло, зато получилось аккуратно вытащить через jq всю самую важную стату из JSON-плейлоада:
🤖 Текущую модель и тир подписки
🔄 Статус агента (idle, etc.)
📉 Детальный расход токенов (Контекст ↓ / Вывод ↑)
📊 Процент использования контекстного окна
Теперь перед глазами всегда понятно, сколько контекста сожрала сессия и сколько еще осталось, всё в одну компактную строку. Видно все модели и лимиты 5h/1w.
Закинул исходник в Gist, кому актуально для работы с LLM — забирайте:
https://gist.github.com/ABIvan-Tech/1c979e29a378a67b88a313dfaee18464
#opensource
Интерфейс там консольный (TUI), поэтому раскрасить вывод ANSI-кодами не вышло, зато получилось аккуратно вытащить через jq всю самую важную стату из JSON-плейлоада:
🤖 Текущую модель и тир подписки
🔄 Статус агента (idle, etc.)
📉 Детальный расход токенов (Контекст ↓ / Вывод ↑)
📊 Процент использования контекстного окна
Теперь перед глазами всегда понятно, сколько контекста сожрала сессия и сколько еще осталось, всё в одну компактную строку. Видно все модели и лимиты 5h/1w.
Закинул исходник в Gist, кому актуально для работы с LLM — забирайте:
https://gist.github.com/ABIvan-Tech/1c979e29a378a67b88a313dfaee18464
#opensource
👍14🔥2
thegod shop - магазин по продаже подписок на нейросети по самым дешевым ценам!
✨ Gemini Pro 18m. - от 99р.
⭐️ Kiro Pro+ (12k cred.) - от 500р.
🤖 Super Grok - от 200р.
💬 Chat GPT Plus - от 240р.
зачем переплачивать когда можно взять тут за копейки?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤4👀4
Media is too big
VIEW IN TELEGRAM
⚪️ Kimi Code 2.7 ⚡️HIGHSPEED⚡️
Релиз анонсирвоанной при запуске фичи - х6 скорость. На практике получается от 150 до 260 tps в зависимости от сложности / размера задачи
Доступ раскатывают участникам Kimi Beta Program, в API, и для Kimi Business. Для обычного Kimi Code Plan пока нету - записывайтесь в Beta программу.
200 tps - это, конечно, другой опыт.
Ценники на апи - в табличке в комментах ⬇️ (х2)
@deksden_notes
Релиз анонсирвоанной при запуске фичи - х6 скорость. На практике получается от 150 до 260 tps в зависимости от сложности / размера задачи
Доступ раскатывают участникам Kimi Beta Program, в API, и для Kimi Business. Для обычного Kimi Code Plan пока нету - записывайтесь в Beta программу.
200 tps - это, конечно, другой опыт.
Ценники на апи - в табличке в комментах ⬇️ (х2)
@deksden_notes
🔥19👍3⚡3❤1
⚪️ Xiaomi MiMo UltraSpeed
Тут вторая новость про высокоскоростную генерацию - вот Сяоми предлагает бэту своего высокоскоростного решения. Анонсировано 1000 tps - это прям оч быстро.
интересная тенденция!
🔗 Записть тут : https://platform.xiaomimimo.com/ultraspeed
🔗 Промик живет тут в карусели, первый слайд: https://mimo.mi.com/docs/en-US/quick-start/summary/welcome
@deksden_notes
Тут вторая новость про высокоскоростную генерацию - вот Сяоми предлагает бэту своего высокоскоростного решения. Анонсировано 1000 tps - это прям оч быстро.
интересная тенденция!
🔗 Записть тут : https://platform.xiaomimimo.com/ultraspeed
🔗 Промик живет тут в карусели, первый слайд: https://mimo.mi.com/docs/en-US/quick-start/summary/welcome
@deksden_notes
👍4
⚪️ Расценки для Claude -p / Agents SDK
Мы все помним как в мае антропики всех "обрадовали" что с 15 июня програмное использование их агента - Claude -p или Agents SDK (который поверх claude -p) будет расцениваться по апи ценам с баланса счета over usage.
Это автоматически убивает все продукты, построенные сверху SDK.
15 июня, на секундочку, настало ВЧЕРА. ТАК ВОТ! "Фраер сдал назад"!
Антропики ТИХО разослали клиентам рассылочку, что передумали, и использврание claude -p / Agents SDK по-прежнему будет идти с подписки.
Если вы клиент - посомтрите почту!
Хорошая новость, так то! Но то, что она так "тихо" анаонсирована - вызывает какие то смутные подозрения про будущее.
(ц) Посмотрим
@deksden_notes
Мы все помним как в мае антропики всех "обрадовали" что с 15 июня програмное использование их агента - Claude -p или Agents SDK (который поверх claude -p) будет расцениваться по апи ценам с баланса счета over usage.
Это автоматически убивает все продукты, построенные сверху SDK.
15 июня, на секундочку, настало ВЧЕРА. ТАК ВОТ! "Фраер сдал назад"!
Антропики ТИХО разослали клиентам рассылочку, что передумали, и использврание claude -p / Agents SDK по-прежнему будет идти с подписки.
Если вы клиент - посомтрите почту!
Хорошая новость, так то! Но то, что она так "тихо" анаонсирована - вызывает какие то смутные подозрения про будущее.
(ц) Посмотрим
@deksden_notes
👏9🔥4
Forwarded from A M
если интересно, то можно расшарить пост -
Провел небольшой A/B-тест моделей Spark, mini и 5.5-medium на реальной задаче обогащения базы своего теннисного сайта.
Зачем: у нас большой объем data scraping и обработки фактов, и хотелось понять, можно ли снизить расход токенов за счет дешевых subagents без потери качества. Как известно, у Spark отдельные лимиты и в теории выглядит очень привлекательно использовать его для простых data scraping задач.
Задача была такая: извлечь source-backed данные с официальных страниц академий: контакты, цены, лагеря/программы, затем сохранить raw JSONL для строгой проверки перед добавлением в базу.
Итог: Spark не подходит как дефолтный worker для такого workflow.
Почему:
Хрупкий в длинных тредах
Spark один раз упал на скрытом ограничении контекста/инструментов, и его пришлось перезапускать с fork_context=false. Для автономных batch-задач это риск.
Слабая дисциплина схемы
Все модели немного отклонялись от заданного формата, но Spark чаще уходил от нужной vocabulary для type/status. Его выход нельзя считать готовым к выдаче в базу.
Плохо подходит для broad discovery
Spark нормален, если есть точный URL и очень маленькая задача: например, “достань email и телефон с этой страницы”. Но он слабее, когда надо ходить по ссылкам, отличать официальный сайт от third-party, разбирать неоднозначные цены или отделять настоящие academy facts от общей информации о клубе/кортах.
Экономия токенов может исчезнуть на QA
Если main agent потом тратит много времени на исправление слабого extraction, отклонение vague facts и починку malformed JSONL, выгода от дешевой модели быстро уменьшается.
Текущий routing после теста:
Spark — только для очень маленьких exact-URL, text-only задач или bounded QA. Короткий prompt, fork_context=false.
5.5-mini — дефолтный worker для обычных небольших batch-задач, если official URLs уже известны.
5.5 medium — для сложных случаев: non-English pages, PDFs, несколько связанных официальных страниц, booking/form gates, contact repair, ambiguity.
Главный вывод: дешевые subagents должны генерировать только raw candidates. Main agent все равно делает строгую нормализацию, duplicate checks, helper dry-run и только потом promotion.
То есть Spark не бесполезен, но как general scraping/research agent он ОЧЕНЬ слабый. Это узкий инструмент для простого extraction, а не надежный enrichment worker.
Провел небольшой A/B-тест моделей Spark, mini и 5.5-medium на реальной задаче обогащения базы своего теннисного сайта.
Зачем: у нас большой объем data scraping и обработки фактов, и хотелось понять, можно ли снизить расход токенов за счет дешевых subagents без потери качества. Как известно, у Spark отдельные лимиты и в теории выглядит очень привлекательно использовать его для простых data scraping задач.
Задача была такая: извлечь source-backed данные с официальных страниц академий: контакты, цены, лагеря/программы, затем сохранить raw JSONL для строгой проверки перед добавлением в базу.
Итог: Spark не подходит как дефолтный worker для такого workflow.
Почему:
Хрупкий в длинных тредах
Spark один раз упал на скрытом ограничении контекста/инструментов, и его пришлось перезапускать с fork_context=false. Для автономных batch-задач это риск.
Слабая дисциплина схемы
Все модели немного отклонялись от заданного формата, но Spark чаще уходил от нужной vocabulary для type/status. Его выход нельзя считать готовым к выдаче в базу.
Плохо подходит для broad discovery
Spark нормален, если есть точный URL и очень маленькая задача: например, “достань email и телефон с этой страницы”. Но он слабее, когда надо ходить по ссылкам, отличать официальный сайт от third-party, разбирать неоднозначные цены или отделять настоящие academy facts от общей информации о клубе/кортах.
Экономия токенов может исчезнуть на QA
Если main agent потом тратит много времени на исправление слабого extraction, отклонение vague facts и починку malformed JSONL, выгода от дешевой модели быстро уменьшается.
Текущий routing после теста:
Spark — только для очень маленьких exact-URL, text-only задач или bounded QA. Короткий prompt, fork_context=false.
5.5-mini — дефолтный worker для обычных небольших batch-задач, если official URLs уже известны.
5.5 medium — для сложных случаев: non-English pages, PDFs, несколько связанных официальных страниц, booking/form gates, contact repair, ambiguity.
Главный вывод: дешевые subagents должны генерировать только raw candidates. Main agent все равно делает строгую нормализацию, duplicate checks, helper dry-run и только потом promotion.
То есть Spark не бесполезен, но как general scraping/research agent он ОЧЕНЬ слабый. Это узкий инструмент для простого extraction, а не надежный enrichment worker.
👍10
Forwarded from A M
В нашем тесте mini выглядит заметно эффективнее 5.5-medium для типовых extraction-задач, но не как полная замена.
Практический вывод:
mini лучше по cost/performance, когда:
известен официальный URL;
задача простая: контакты, email, phone, social, базовые pricing/program facts;
страницы на английском или простые по структуре;
не нужно много reasoning.
5.5-medium лучше, когда:
сайт неочевидный или надо искать новый официальный URL;
есть PDF, booking portal, формы, логин-гейты;
страница не на английском;
надо отличить реальную академию от клуба/кортов/мерча;
mini вернул мало, расплылся или дал сомнительные факты.
По качеству:
mini дал достаточно хорошие raw candidates, которые main agent мог проверить и нормализовать. Он намного надежнее Spark и обычно дешевле/быстрее, чем medium.
По риску:
mini все еще нельзя пускать напрямую в базу. Он может:
принять court booking price за program pricing;
не заметить, что цена устарела;
не отличить camp от generic junior page;
дать слабый status/type.
Итоговая оценка:
mini должен быть default worker для 70-80% обычного enrichment batch, а 5.5-medium надо держать как escalation model для сложных/ambiguous случаев. Это, вероятно, лучший баланс между ценой, скоростью и качеством.
Практический вывод:
mini лучше по cost/performance, когда:
известен официальный URL;
задача простая: контакты, email, phone, social, базовые pricing/program facts;
страницы на английском или простые по структуре;
не нужно много reasoning.
5.5-medium лучше, когда:
сайт неочевидный или надо искать новый официальный URL;
есть PDF, booking portal, формы, логин-гейты;
страница не на английском;
надо отличить реальную академию от клуба/кортов/мерча;
mini вернул мало, расплылся или дал сомнительные факты.
По качеству:
mini дал достаточно хорошие raw candidates, которые main agent мог проверить и нормализовать. Он намного надежнее Spark и обычно дешевле/быстрее, чем medium.
По риску:
mini все еще нельзя пускать напрямую в базу. Он может:
принять court booking price за program pricing;
не заметить, что цена устарела;
не отличить camp от generic junior page;
дать слабый status/type.
Итоговая оценка:
mini должен быть default worker для 70-80% обычного enrichment batch, а 5.5-medium надо держать как escalation model для сложных/ambiguous случаев. Это, вероятно, лучший баланс между ценой, скоростью и качеством.
Forwarded from A M
Продолжение после реального A/B-теста 5.5-low vs 5.5-medium.
Прогнали обе модели на одинаковом sample из 8 академий, без promotion в базу. Цель была не “кто написал больше строк”, а кто дает больше реально полезных source-backed candidates при меньшей нагрузке на QA.
Короткий итог: 5.5-low полезна, но не как замена mini и не как замена medium.
Она занимает узкую middle-tier позицию.
Что показал тест:
5.5-low
- лучше держится на простых exact-URL задачах;
- дает более чистые contact/program rows;
- меньше расползается в лишние рассуждения;
- выглядит дешевле по QA для простых страниц;
- но пропускает более сложные источники: PDFs, linked pages, padel/pricing details, неоднозначные программы.
То есть 5.5-low хороша, когда надо быстро извлечь очевидные факты с уже известной официальной страницы.
5.5-medium
- нашла больше materially useful facts;
- лучше справилась с pricing, PDF, padel и более сложными linked sources;
- полезнее там, где нужна интерпретация;
- но output был менее promotion-ready;
- требовала больше нормализации и main-agent QA.
То есть medium лучше как reasoning/research модель, но ее нельзя использовать как “просто дешевый extractor”: она может дать больше ценности, но и больше шума.
Главный вывод по workflow
5.5-low не заменяет mini, потому что mini все еще остается default для массового простого extraction, если official URL уже известен.
Но 5.5-low можно добавить как промежуточный слой:
- mini — обычный default worker для простых known-URL batches;
- 5.5-low — когда задача чуть сложнее mini, но еще не требует полноценного reasoning;
- 5.5-medium — когда есть PDF, non-English, booking gates, pricing ambiguity, multiple official pages, contact repair или слабый результат от mini/low.
Практическое правило после теста:
Использовать 5.5-low для:
- exact official URL;
- contact + simple program extraction;
- простых англоязычных страниц;
- bounded QA;
- случаев, где Spark слишком слабый, а medium избыточна.
Не использовать 5.5-low для:
- broad discovery;
- dead URL / rebrand repair;
- pricing через booking portals;
- PDF-heavy pages;
- non-English pages;
- финального решения по ambiguous facts.
И важное: ни 5.5-low, ни 5.5-medium нельзя считать promotion-ready. Обе модели должны писать только raw JSONL candidates. Main agent дальше делает strict normalization, duplicate checks, pricing filters и helper dry-run.
Финальная рекомендация:
5.5-low стоит добавить в routing, но как narrow middle tier. Она экономит QA на простых задачах, но medium все еще нужен для сложных случаев, где low просто не достает часть ценных фактов.
Прогнали обе модели на одинаковом sample из 8 академий, без promotion в базу. Цель была не “кто написал больше строк”, а кто дает больше реально полезных source-backed candidates при меньшей нагрузке на QA.
Короткий итог: 5.5-low полезна, но не как замена mini и не как замена medium.
Она занимает узкую middle-tier позицию.
Что показал тест:
5.5-low
- лучше держится на простых exact-URL задачах;
- дает более чистые contact/program rows;
- меньше расползается в лишние рассуждения;
- выглядит дешевле по QA для простых страниц;
- но пропускает более сложные источники: PDFs, linked pages, padel/pricing details, неоднозначные программы.
То есть 5.5-low хороша, когда надо быстро извлечь очевидные факты с уже известной официальной страницы.
5.5-medium
- нашла больше materially useful facts;
- лучше справилась с pricing, PDF, padel и более сложными linked sources;
- полезнее там, где нужна интерпретация;
- но output был менее promotion-ready;
- требовала больше нормализации и main-agent QA.
То есть medium лучше как reasoning/research модель, но ее нельзя использовать как “просто дешевый extractor”: она может дать больше ценности, но и больше шума.
Главный вывод по workflow
5.5-low не заменяет mini, потому что mini все еще остается default для массового простого extraction, если official URL уже известен.
Но 5.5-low можно добавить как промежуточный слой:
- mini — обычный default worker для простых known-URL batches;
- 5.5-low — когда задача чуть сложнее mini, но еще не требует полноценного reasoning;
- 5.5-medium — когда есть PDF, non-English, booking gates, pricing ambiguity, multiple official pages, contact repair или слабый результат от mini/low.
Практическое правило после теста:
Использовать 5.5-low для:
- exact official URL;
- contact + simple program extraction;
- простых англоязычных страниц;
- bounded QA;
- случаев, где Spark слишком слабый, а medium избыточна.
Не использовать 5.5-low для:
- broad discovery;
- dead URL / rebrand repair;
- pricing через booking portals;
- PDF-heavy pages;
- non-English pages;
- финального решения по ambiguous facts.
И важное: ни 5.5-low, ни 5.5-medium нельзя считать promotion-ready. Обе модели должны писать только raw JSONL candidates. Main agent дальше делает strict normalization, duplicate checks, pricing filters и helper dry-run.
Финальная рекомендация:
5.5-low стоит добавить в routing, но как narrow middle tier. Она экономит QA на простых задачах, но medium все еще нужен для сложных случаев, где low просто не достает часть ценных фактов.
🔥7👍4❤1
⚪️ Software Factory
Тут Factory.ai (авторы droid, довольно крутого агента) разродился интро-постом о том, что мы переходим от индивидуальных агентов к автоматизации полного SDLC через Software Factories. Предлагает услуги их построить!
Это ровно то, о чем мы на одном из созвонов говорили - про полный SDLC, и что это сильно отличается от ИИ-разработки. Разработка - это все таки часть бизнеса, еще может оказаться, что и не самая большая! Автоматизация только ее - это формирвоание бутылочных горлышек по цепочке дальше.
▶️ Фэктори правильно все этапы пишет:
• signal in: хотелка пользователя
• triage: проработка хотелки, снятие неопределенностей, устранение Gaps
• plan: делаем подробный план реализации
• code: реализация
• test: тестируем (я сценариями прежде всего тетсирую)
• review: почему после тестов? нелогично; я делаю тесты ДО ревью, чтобы код корректный был, и ревью по цепочке с тестами бегает; а вот сценарии фичи - после смотрим, чтобы типа окончательный вариант;
• ship: у меня тут разделено - есть отдельно release (это выпуск версии, то есть паковка определенного набора фич в версию) и deploy (деплой - это выпуск некоего артефакта на определенный Stage, или в репозиторий, или в магаз); есть совмещенный флоу publish - это когда разделить не получается выпуск версии и делой на stage;
• monitor, automate: я хз как именно они за деплоями следят - у меня это индивидуально в паре проектов автоматизировано (в квн моем, например) через агента-администратора системы, он мне отчеты шлет как оно там поживает;
• software out: ну - концептуально тоже мне не понятно; оно у меня out когда я деплой сделал;
В общем, тема знакомая)) концепция не новая - мы про такое еще со времен Code Machine отслеживаем, всякие такие гравицапы (Auto Claude, например). Просто лишний раз убеждаешься, что тенденция усмотрена верно, жизнь туда и развивается.
Мне понравилось как сделана визуализация дашборда на их фабрике! Скрин в комменты кину для понимания. ⬇️
▶️ Надо будет упереь для своего dd-flow. Я как раз все свои этапы снабдил html-отчетами, и щас вот дашборд надо красивый вкрутить)) Спасибо за inspiration
🔗 Пост в бложик : https://factory.ai/news/software-factory
❓ Вы что то подобное делаете?
@deksden_notes
Тут Factory.ai (авторы droid, довольно крутого агента) разродился интро-постом о том, что мы переходим от индивидуальных агентов к автоматизации полного SDLC через Software Factories. Предлагает услуги их построить!
Это ровно то, о чем мы на одном из созвонов говорили - про полный SDLC, и что это сильно отличается от ИИ-разработки. Разработка - это все таки часть бизнеса, еще может оказаться, что и не самая большая! Автоматизация только ее - это формирвоание бутылочных горлышек по цепочке дальше.
▶️ Фэктори правильно все этапы пишет:
• signal in: хотелка пользователя
• triage: проработка хотелки, снятие неопределенностей, устранение Gaps
• plan: делаем подробный план реализации
• code: реализация
• test: тестируем (я сценариями прежде всего тетсирую)
• review: почему после тестов? нелогично; я делаю тесты ДО ревью, чтобы код корректный был, и ревью по цепочке с тестами бегает; а вот сценарии фичи - после смотрим, чтобы типа окончательный вариант;
• ship: у меня тут разделено - есть отдельно release (это выпуск версии, то есть паковка определенного набора фич в версию) и deploy (деплой - это выпуск некоего артефакта на определенный Stage, или в репозиторий, или в магаз); есть совмещенный флоу publish - это когда разделить не получается выпуск версии и делой на stage;
• monitor, automate: я хз как именно они за деплоями следят - у меня это индивидуально в паре проектов автоматизировано (в квн моем, например) через агента-администратора системы, он мне отчеты шлет как оно там поживает;
• software out: ну - концептуально тоже мне не понятно; оно у меня out когда я деплой сделал;
В общем, тема знакомая)) концепция не новая - мы про такое еще со времен Code Machine отслеживаем, всякие такие гравицапы (Auto Claude, например). Просто лишний раз убеждаешься, что тенденция усмотрена верно, жизнь туда и развивается.
Мне понравилось как сделана визуализация дашборда на их фабрике! Скрин в комменты кину для понимания. ⬇️
▶️ Надо будет упереь для своего dd-flow. Я как раз все свои этапы снабдил html-отчетами, и щас вот дашборд надо красивый вкрутить)) Спасибо за inspiration
🔗 Пост в бложик : https://factory.ai/news/software-factory
❓ Вы что то подобное делаете?
@deksden_notes
🔥11❤6
⚪️ Codex Referal Reset
Как вы знаете, Кодекс ввел систему рефералок, - если по вашей ссылке регистрируется пользователь, вам и ему дают ресет.
▶️ Так как у меня много аккаунтов, я решил не брать плюс подписку на очередной аккаунт "из старых", а сделать новый аккаунт, благо доменов то у меня много! )) Аккаунты я делаю на свои домены, но вместо почты завожу алиас на simplelogin.io (там у меня премиум) куда у меня эти домены подключены.
Зарегавшись в chatgpt.com, я вернулся в кодекс.апп и оттуда на этот новый аккаунт отправил рефералку.
▶️ Не забываем на chagpt.com для новых аккаунтов включить для аккаунта passkey / 2fa. Я забыл, и у меня просила авторизацию через телефон (благо у меня этих ваших esim с номерами верификации щас полно). Надо будет еще раз попробовать - но уже со включенным 2fa/passkey, есть мнение, что в этом случае может НЕ просить верификацию, но не факт, надо проверять.
Тут надо сделать выход из своего аккаунта в кодекс.апп. На всякий случай взял с почты реферальную ссылку, и по ней перешел - она открывает кодекс.апп. Там вошел в новый аккаунт, и в чате поздоровался с кодексом. В этот момент ресет пришел)
▶️ В общем, для нового аккаунта все сработало: ресет дали и моему аккаунту, с которого я реферал делал, и новому (даже free) аккаунту! Понятно, что тратить ресет на free аккаунте довольно неразумно, надо будет его апнуть до Плюса.
▶️ Не на всех аккаунтах включилась возможность отправлять инвайты. Наверное, это только честно купленные аккаунты - но я не отслеживал закономерность. Имейте ввиду.
——
Upd 1️⃣ : проверил - нет, для новых аккаунтов 2fa/passkey не спасает от требования верификации - скорее всего, это защита от фрода.
И еще наблюдение: логин и логаут из кодекс.апп инвалидирует сессии в CPA / web.
@deksden_notes
Как вы знаете, Кодекс ввел систему рефералок, - если по вашей ссылке регистрируется пользователь, вам и ему дают ресет.
▶️ Так как у меня много аккаунтов, я решил не брать плюс подписку на очередной аккаунт "из старых", а сделать новый аккаунт, благо доменов то у меня много! )) Аккаунты я делаю на свои домены, но вместо почты завожу алиас на simplelogin.io (там у меня премиум) куда у меня эти домены подключены.
Зарегавшись в chatgpt.com, я вернулся в кодекс.апп и оттуда на этот новый аккаунт отправил рефералку.
▶️ Не забываем на chagpt.com для новых аккаунтов включить для аккаунта passkey / 2fa. Я забыл, и у меня просила авторизацию через телефон (благо у меня этих ваших esim с номерами верификации щас полно). Надо будет еще раз попробовать - но уже со включенным 2fa/passkey, есть мнение, что в этом случае может НЕ просить верификацию, но не факт, надо проверять.
Тут надо сделать выход из своего аккаунта в кодекс.апп. На всякий случай взял с почты реферальную ссылку, и по ней перешел - она открывает кодекс.апп. Там вошел в новый аккаунт, и в чате поздоровался с кодексом. В этот момент ресет пришел)
▶️ В общем, для нового аккаунта все сработало: ресет дали и моему аккаунту, с которого я реферал делал, и новому (даже free) аккаунту! Понятно, что тратить ресет на free аккаунте довольно неразумно, надо будет его апнуть до Плюса.
▶️ Не на всех аккаунтах включилась возможность отправлять инвайты. Наверное, это только честно купленные аккаунты - но я не отслеживал закономерность. Имейте ввиду.
——
Upd 1️⃣ : проверил - нет, для новых аккаунтов 2fa/passkey не спасает от требования верификации - скорее всего, это защита от фрода.
И еще наблюдение: логин и логаут из кодекс.апп инвалидирует сессии в CPA / web.
@deksden_notes
1🔥8❤3
⚪️ HTML отчеты - небольшой апдейт
Я уже говорил про тему с HTML отчетами
🔗 Вот оригинальный пост про подход: https://t.me/deksden_notes/837
Я их использую на каждый этап своих флоу, стараюсь что то важное показать, и, желательно, как то посимпатичнее, графиком там разбавить, или табличками.
▶️ Делаю просто: есть html шаблон, данные он берет из json, а этап флоу должен только сформировать этот json - не нужно каждый раз агенту упражняться с html, да и формат выходит консистентнее. Шаблоны - в доп материалах промпта (скилла)
▶️ Еще момент: агент, конечно, напишет в своем заключении по этапу что сделал такой то отчет. Но это надо кликнуть - а ведь еще удобнее, когда отчет просто сразу видно. Я сделал блок в промпт, чтобы оно работало почти везде - я использую CMUX сейчас, в нем есть скилл Cmux Browser: если он доступен, отчет откроется в CMUX. Если нет - использую скилл Agents Browser.
Вы можете аналогичным образом прописывать браузер вашей ADE, встроенные браузеры сейчас почти у всех - от кодекс апп, до курсора.
❓ Пользуете такое для UX разработки? Или только отладку фронта?
@deksden_notes
Я уже говорил про тему с HTML отчетами
🔗 Вот оригинальный пост про подход: https://t.me/deksden_notes/837
Я их использую на каждый этап своих флоу, стараюсь что то важное показать, и, желательно, как то посимпатичнее, графиком там разбавить, или табличками.
▶️ Делаю просто: есть html шаблон, данные он берет из json, а этап флоу должен только сформировать этот json - не нужно каждый раз агенту упражняться с html, да и формат выходит консистентнее. Шаблоны - в доп материалах промпта (скилла)
▶️ Еще момент: агент, конечно, напишет в своем заключении по этапу что сделал такой то отчет. Но это надо кликнуть - а ведь еще удобнее, когда отчет просто сразу видно. Я сделал блок в промпт, чтобы оно работало почти везде - я использую CMUX сейчас, в нем есть скилл Cmux Browser: если он доступен, отчет откроется в CMUX. Если нет - использую скилл Agents Browser.
Вы можете аналогичным образом прописывать браузер вашей ADE, встроенные браузеры сейчас почти у всех - от кодекс апп, до курсора.
❓ Пользуете такое для UX разработки? Или только отладку фронта?
@deksden_notes
Telegram
DEKSDEN notes
⚪️ Агентные флоу - отчеты
▶️ У меня в работе часто используются агентные флоу. Это именно то, что запускают оркестраторы, да.
И по результатам работы этих флоу агенты, как водится, отчитываются.
▶️ Мне категорически не нравится как отчитывается кодекс:…
▶️ У меня в работе часто используются агентные флоу. Это именно то, что запускают оркестраторы, да.
И по результатам работы этих флоу агенты, как водится, отчитываются.
▶️ Мне категорически не нравится как отчитывается кодекс:…
1❤6👍3✍2
Forwarded from Alexey Demochko
Привет :) Обещал упаковать красиво плагин для Фигмы
🧩 Figma AI Bridge — опенсорсный мост между Figma Desktop и ИИ-агентами.
В чем боль? Скармливать LLM сырой JSON из Figma — гиблое дело. Он гигантский, шумный и мгновенно сжирает контекст модели. А настраивать ради банальной верстки одного экрана Figma API, Dev Mode MCP, токены и всю эту инфру — откровенный оверкилл.
Figma AI Bridge решает это элегантно и полностью локально:
🔹 Плагин в Figma собирает только суть: макеты, тексты, структуру, стили и превью.
🔹 Локальный сервер упаковывает это в аккуратный handoff-бандл в папке out/.
🔹 Ваш ИИ-агент (Codex, Cursor и др.) читает не мусорный дамп на сотни тысяч строк, а понятный набор: prompt.md, page-map.md, preview.png и design-context.json.
🔹 Никаких REST API, платного Dev Mode и возни с access-токенами.
Внутри коробки: режимы Page Extract, Links Batch и Selection, плюс готовые CLI-команды для валидации, саммари и нарезки задач для агентов.
Суть: дать ИИ ровно то, что нужно для реализации интерфейса, не забивая ему мозги мусором. Меньше шума и ручной подготовки = больше шансов получить верстку, которая реально похожа на макет. ⚙️
Если автоматизируете фронтенд через агентов, этот репозиторий закрывает огромную дыру в пайплайне.
Github: https://github.com/Kacep91/figma-ai-bridge
#opensource #figma #codex #frontend #design
🧩 Figma AI Bridge — опенсорсный мост между Figma Desktop и ИИ-агентами.
В чем боль? Скармливать LLM сырой JSON из Figma — гиблое дело. Он гигантский, шумный и мгновенно сжирает контекст модели. А настраивать ради банальной верстки одного экрана Figma API, Dev Mode MCP, токены и всю эту инфру — откровенный оверкилл.
Figma AI Bridge решает это элегантно и полностью локально:
🔹 Плагин в Figma собирает только суть: макеты, тексты, структуру, стили и превью.
🔹 Локальный сервер упаковывает это в аккуратный handoff-бандл в папке out/.
🔹 Ваш ИИ-агент (Codex, Cursor и др.) читает не мусорный дамп на сотни тысяч строк, а понятный набор: prompt.md, page-map.md, preview.png и design-context.json.
🔹 Никаких REST API, платного Dev Mode и возни с access-токенами.
Внутри коробки: режимы Page Extract, Links Batch и Selection, плюс готовые CLI-команды для валидации, саммари и нарезки задач для агентов.
Суть: дать ИИ ровно то, что нужно для реализации интерфейса, не забивая ему мозги мусором. Меньше шума и ручной подготовки = больше шансов получить верстку, которая реально похожа на макет. ⚙️
Если автоматизируете фронтенд через агентов, этот репозиторий закрывает огромную дыру в пайплайне.
Github: https://github.com/Kacep91/figma-ai-bridge
#opensource #figma #codex #frontend #design
GitHub
GitHub - Kacep91/figma-ai-bridge: Local Figma Desktop plugin and localhost bridge for AI-ready design handoff bundles, without…
Local Figma Desktop plugin and localhost bridge for AI-ready design handoff bundles, without Figma API, Dev Mode MCP, or access tokens. - Kacep91/figma-ai-bridge
2❤12🔥7