⚪️ Кешбек токенами


Интересную новость прочитал, не мог не поделиться:

🔗 Новость: https://t.me/ai_machinelearning_big_data/10317

В Китае вводят кешбек токенами Кими. Причем, госбанк, что немного необычно - это же вроде консервативные организации.

Вижу несколько выводов:
• ИИ становится частью "большой" экономики
• ИИ довольно близко к государству, раз госбанки в теме, и явно носит стратегический характер

В общем, к сожалению, времена "дикого" развития ИИ, похоже, подходят к концу. Ждем ИИ "по госуслугам", и прочие фокусы регулирования - с некоторой печалью.

(ц) хроники интересного времени

⚪️ 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

⚪️ Kimi Code 2.7 ⚡️HIGHSPEED⚡️


Релиз анонсирвоанной при запуске фичи - х6 скорость. На практике получается от 150 до 260 tps в зависимости от сложности / размера задачи

Доступ раскатывают участникам Kimi Beta Program, в API, и для Kimi Business. Для обычного Kimi Code Plan пока нету - записывайтесь в Beta программу.

200 tps - это, конечно, другой опыт.

Ценники на апи - в табличке в комментах ⬇️ (х2)

@deksden_notes

⚪️ Xiaomi MiMo UltraSpeed


Тут вторая новость про высокоскоростную генерацию - вот Сяоми предлагает бэту своего высокоскоростного решения. Анонсировано 1000 tps - это прям оч быстро.

интересная тенденция!

🔗 Записть тут : https://platform.xiaomimimo.com/ultraspeed

🔗 Промик живет тут в карусели, первый слайд: https://mimo.mi.com/docs/en-US/quick-start/summary/welcome


@deksden_notes

⚪️ Расценки для Claude -p / Agents SDK


Мы все помним как в мае антропики всех "обрадовали" что с 15 июня програмное использование их агента - Claude -p или Agents SDK (который поверх claude -p) будет расцениваться по апи ценам с баланса счета over usage.

Это автоматически убивает все продукты, построенные сверху SDK.

15 июня, на секундочку, настало ВЧЕРА. ТАК ВОТ! "Фраер сдал назад"!

Антропики ТИХО разослали клиентам рассылочку, что передумали, и использврание claude -p / Agents SDK по-прежнему будет идти с подписки.

Если вы клиент - посомтрите почту!

Хорошая новость, так то! Но то, что она так "тихо" анаонсирована - вызывает какие то смутные подозрения про будущее.

(ц) Посмотрим

@deksden_notes

если интересно, то можно расшарить пост -

Провел небольшой 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.

В нашем тесте 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 случаев. Это, вероятно, лучший баланс между ценой, скоростью и качеством.

Продолжение после реального 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 просто не достает часть ценных фактов.

⚪️ 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

⚪️ Codex Referal Reset


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

▶️ Так как у меня много аккаунтов, я решил не брать плюс подписку на очередной аккаунт "из старых", а сделать новый аккаунт, благо доменов то у меня много! )) Аккаунты я делаю на свои домены, но вместо почты завожу алиас на simplelogin.io (там у меня премиум) куда у меня эти домены подключены.

Зарегавшись в chatgpt.com, я вернулся в кодекс.апп и оттуда на этот новый аккаунт отправил рефералку.

▶️ Не забываем на chagpt.com для новых аккаунтов включить для аккаунта passkey / 2fa. Я забыл, и у меня просила авторизацию через телефон (благо у меня этих ваших esim с номерами верификации щас полно). Надо будет еще раз попробовать - но уже со включенным 2fa/passkey, есть мнение, что в этом случае может НЕ просить верификацию, но не факт, надо проверять.

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

▶️ В общем, для нового аккаунта все сработало: ресет дали и моему аккаунту, с которого я реферал делал, и новому (даже free) аккаунту! Понятно, что тратить ресет на free аккаунте довольно неразумно, надо будет его апнуть до Плюса.

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

——
Upd 1️⃣ : проверил - нет, для новых аккаунтов 2fa/passkey не спасает от требования верификации - скорее всего, это защита от фрода.

И еще наблюдение: логин и логаут из кодекс.апп инвалидирует сессии в CPA / web.


@deksden_notes

⚪️ HTML отчеты - небольшой апдейт


Я уже говорил про тему с HTML отчетами

🔗 Вот оригинальный пост про подход: https://t.me/deksden_notes/837

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

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

▶️ Еще момент: агент, конечно, напишет в своем заключении по этапу что сделал такой то отчет. Но это надо кликнуть - а ведь еще удобнее, когда отчет просто сразу видно. Я сделал блок в промпт, чтобы оно работало почти везде - я использую CMUX сейчас, в нем есть скилл Cmux Browser: если он доступен, отчет откроется в CMUX. Если нет - использую скилл Agents Browser.

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

❓ Пользуете такое для UX разработки? Или только отладку фронта?

@deksden_notes

Привет :) Обещал упаковать красиво плагин для Фигмы



🧩 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