TGViewer
Channel Public Channel
AI Coder

AI Coder

@ai_coder_news

AI will not replace you, people who use AI will.
Open in Telegram
Subscribers
539
Photos
119
Videos
12
Links
327
Recent Posts 20 shown
Post #592 229
⚡ Собрал смарт-роутинг для Claude Code: тяжёлые задачи — на GLM-4.5+, рутина — на флеш

Поднял локальный шлюз (claude-code-router) перед API Z.AI — и теперь у меня две модели на одной сессии:

🔹 glm-5.3 — рассуждения, планирование, архитектура, сложные рефакторинги
🔹 glm-5.3-flash — фоновое сжатие контекста, grep/навигация, git status, линтеры, автодополнение типов, парсинг логов, точечные патчи

Фон жёстко уходит на флеш через слоты моделей профиля — это до 80% бюджета сессии по токенам. Базовые субагенты (поиск файлов, доки, форматирование) запинены на haiku-слот = флеш. Тяжёлые агенты остаются на основной.

По пути нашёл два неочевидных бага, из-за которых «всё настроено, но флеш не работает»:

1️⃣ CCR добавляет суффикс [1m] к именам моделей в env-слотах → шлюз не распознавал имя и молча отправлял запрос на дефолт. Лечится alias-правилами роутера.

2️⃣ Все кастомные агенты были с model: inherit → всегда главная модель, мимо любых слотов. Вылечил пинами model: haiku у рутинных агентов.

Итог проверял не на глаз, а по usage-БД шлюза: у фоновых запросов реально 200 OK с моделью glm-5.3-flash.

Весь сетап — два скрипта: zccr-setup (идемпотентная настройка через management RPC, ключи не светятся в ps) и zclaude (обёртка: подняла шлюз, если лежит → запустила Claude Code через профиль). Работает автономно, обычный claude не трогает.

Gist: https://gist.github.com/zamotkin/37364589027cf3f1c2e5e8c1cf746c43

Состав:
- README.md — политика маршрутизации таблицей, 4 грабли (суффикс [1m], model: inherit, секреты в argv, опечатка в ключе), установка в 5 команд, проверка фактической маршрутизации через usage-БД
- zccr-setup.sh — идемпотентный RPC-конфигуратор (322 строки: секреты через mktemp-файлы 0600, connectivity до saveConfig, no-op-детект, loopback-валидация)
- zclaude.sh — runtime-обёртка (health → тихий автостарт → exec ccr "Claude Code" cli --)
Gist Smart routing для Claude Code: claude-code-router v3 + Z.AI GLM (glm-5.3 / glm-5.3-flash) — task-aware маршрутизация heavy/light Smart routing для Claude Code: claude-code-router v3 + Z.AI GLM (glm-5.3 / glm-5.3-flash) — task-aware маршрутизация heavy/light - README.md
  • 🔥 8
  • 👍 2
  • ❤ 1
Post #591 286
Я перестал давать Astra писать код. И дело не в том, что она плохо это делает 🙂
Довёл до рабочего состояния конфиг для Codex: Astra координирует, Terra и Sol пишут код. Собрал bash-скрипт, который настраивает всё в репозитории.
Но тут важно объяснить, почему я вообще так сделал.
Astra — не принципиально другой уровень на каждой coding-задаче. На части бенчмарков она близка к Sol: например, в опубликованных OpenAI результатах DeepSWE v1.1 — 74,1% против 72,7%. При этом на сложных терминальных задачах и миграциях преимущество уже заметно больше. То есть модели не одинаковые, но каждая обычная правка не становится кратно лучше от замены Sol на Astra.
И для меня основной смысл Astra — решение сложнейших задач, а не написание очередного обработчика.
Разобраться в системе. Найти причину, которую все пропустили. Определить правильные инварианты. Придумать решение, когда непонятно даже, с какой стороны подойти.
Вот на это я и хочу тратить её reasoning.
Не «напиши весь код сама», а «реши сложную задачу и организуй её реализацию».
Схема получилась такая.
🧠 Astra / medium — архитектор и координатор.
Разбирает задачу, принимает архитектурные решения, определяет границы работы и критерии приёмки. Раздаёт задачи агентам, проверяет diff и результаты тестов.
Это не диспетчер, который просто пересылает сообщения. Самую сложную интеллектуальную часть она должна разобрать сама, а исполнителям передать конкретную постановку.
🔧 Terra / medium — основной кодер.
Реализация, тесты, локальные исправления. Для поиска конкретных файлов и символов — отдельный explorer на low. Для независимой проверки — verifier на medium.
🔬 Sol / high — сложная реализация.
Concurrency, нетривиальные алгоритмы, тяжёлый debugging. Если Terra два раза не справилась — передаём Sol. Если риск очевиден сразу, не тратим попытки Terra.
Для рискованного изменения — ещё и отдельный Sol-reviewer, не автор кода.
Обычный маршрут: Astra → Terra → проверка → Astra
Сложный: Astra → Sol → проверка → независимое review → Astra
Главное правило: Astra нашла баг — не идёт «быстро сама поправлю». Формулирует проблему и возвращает исполнителю. Даже если исправление на одну строку.
Иначе разделение ролей заканчивается на первом неудобном тесте.
Все роли на каждую задачу не запускаются. Максимум три дочерних треда, по умолчанию один writer. Параллельные правки — только в независимых участках. Исполнители свои команды агентов не создают.
С effort тоже не стал экономить вслепую: основной кодер на medium, сложная реализация и review на high. Для архитектурно сложной задачи Astra можно поднять до high.
Дешёвая первая попытка ничего не стоит, если потом приходится оплачивать три переделки.
🛠 Установка из корня репозитория:
# Посмотреть план
bash ~/Downloads/setup-codex-routing.sh --dry-run

# Установить
bash ~/Downloads/setup-codex-routing.sh
Нужны Bash, Git и Python 3.9+. Скрипт объединяет настройки с существующим конфигом, добавляет роли и правила в AGENTS.md, делает backup. После установки — новая сессия Codex и приложенный smoke test.
Запрет Astra менять файлы здесь — инструкция, не жёсткая sandbox-изоляция.
Проценты экономии пока не называю — сравнительных замеров нет. Меньше токенов Astra не обязательно означает меньше общего расхода. Проверять буду стоимость принятого change по всем моделям, с учётом переделок и качества.
Но сама идея для меня именно такая:
Сильнейшая модель нужна не для того, чтобы лично написать каждую строчку. Она нужна, чтобы решить то, что остальные не решили, и организовать работу остальных.
Конфиг и скрипт установки прикладываю.

https://gist.github.com/dpolishuk/b2f17580aa62c55dce99c92f58049d37
Gist setup-codex-routing.sh setup-codex-routing.sh. GitHub Gist: instantly share code, notes, and snippets.
  • 👍 13
  • ❤ 6
  • 🔥 2
  • 🙏 2
  • 🆒 1
Post #590 317
Как я использую OKF в своих проектах?

Я запускаю этот промпт и дальше агент читает правила из AGENTS.md и использует как agentic memory:

Внедри в текущий репозиторий минимальную базу инженерных знаний в Google Open Knowledge Format (OKF v0.2). Правила её использования закрепи в корневом AGENTS.md.

Спецификация:
https://github.com/GoogleCloudPlatform/open-knowledge-format/blob/main/SPEC.md

1. Исследуй проект

Прочитай инструкции для агентов, README, ADR, документацию, конфигурацию сборки и CI. Найди существующий корпус знаний и устройство harness, включая xpowers, если он используется.

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

2. Создай knowledge/

Начни с index.md и 3–5 содержательных документов по реально исследованному проекту: архитектура, контракты, инварианты, проверка изменений, диагностика.

Возможные категории: architecture/, decisions/, contracts/, runbooks/, incidents/. Создавай только нужные; пустые разделы и заглушки не нужны.

Соблюдай OKF:

* В корневом index.md укажи okf_version: "0.2", добавь ссылки и краткие описания документов.
* В каждом обычном Markdown-документе используй YAML frontmatter с непустым type; добавь title, description и status.
* index.md и log.md оформляй по специальным правилам спецификации.
* Связывай документы относительными Markdown-ссылками.
* Указывай реальные источники в sources; для GitHub по возможности используй ссылки с commit SHA.
* generated и stale_after добавляй по необходимости.
* verified заполняй только после фактической проверки, указывая реального проверяющего и время.

Не дублируй большие README и ADR — ссылайся на них.

3. Проверяй основания

Утверждения о текущем поведении сверяй с кодом, тестами и конфигурацией. Причины решений ищи в ADR и истории.

Не придумывай мотивы авторов, результаты тестов, даты и подтверждения. Различай наблюдаемое поведение, требования и предположения. Противоречия фиксируй явно; непроверенное оставляй черновиком.

4. Добавь правила в AGENTS.md

Обнови корневой AGENTS.md, сохранив существующие инструкции; если файла нет — создай. Добавь отдельный раздел «Использование базы знаний» с конкретными правилами:

Перед существенной задачей:

* Прочитать knowledge/index.md.
* Выбрать относящиеся к задаче документы; при необходимости искать по knowledge/ через rg и переходить по ссылкам.
* Не загружать весь корпус без необходимости.
* Проверять status, stale_after и основания verified. Просроченные сведения перепроверять, deprecated учитывать как историю.

Во время работы:

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

Перед завершением задачи:

* Оценить, появились ли устойчивые знания: решение, инвариант, ограничение, причина ошибки или проверенная процедура.
* Обновить существующий документ либо создать новый со ссылками на основания.
* При изменении поведения обновить связанные знания в том же PR.
* Поддерживать индекс и внутренние ссылки.
* После существенной правки пересмотреть прежние verified; неподтверждённые сведения оставить черновиком.
* Не сохранять рутинный пересказ сессии и дубликаты.
* В отчёте указать обновлённые документы либо отметить, что обновление знаний не требовалось.

Инструкции harness держи вне OKF bundle. Если другие агенты используют отдельные файлы инструкций, добавь в них ссылку на эти правила без копирования всего раздела.

5. Проверь и заверши

Проверь YAML, обязательные поля, структуру индекса, внутренние ссылки, основания ключевых утверждений и согласованность AGENTS.md с созданным корпусом.

Используй существующие проверки документации. Не добавляй тяжёлую инфраструктуру и не меняй продуктовый код ради этой задачи.

В конце сообщи, какие файлы изменены, что проверено и какие вопросы остались. Выполни работу до конкретных изменений в репозитории, не ограничивайся планом.
GitHub open-knowledge-format/SPEC.md at main · GoogleCloudPlatform/open-knowledge-format Contribute to GoogleCloudPlatform/open-knowledge-format development by creating an account on GitHub.
  • 👍 5
  • 🔥 1
  • 🥰 1
  • 🤔 1
Post #587 245
🧠 Google OKF vs OpenViking: какую память делать своим агентам?

Начал разбираться с Open Knowledge Format от Google. На первый взгляд — ещё один подход к агентской памяти. Но если поставить рядом OpenViking, выясняется интересная штука: они решают похожую задачу на разных уровнях.

OKF говорит: «Давайте договоримся, как представлять знания».
OpenViking: «Вот система, которая будет их хранить, находить и извлекать из работы агента».


📁 Что предлагает Google

OKF — это Markdown-файлы с YAML-метаданными и ссылками друг на друга. По сути, общая wiki для людей и агентов.

Один документ описывает сервис. Другой — архитектурное решение. Третий — инцидент. Ссылки между ними образуют граф.

В v0.2 можно указать, откуда взялось знание, кто его создал и проверил, когда оно устареет. Всё это живёт в файлах: можно хранить в Git, смотреть diff, делать review, передавать другому агенту.

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

Подробнее — в [спецификации OKF](https://github.com/GoogleCloudPlatform/open-knowledge-format/blob/main/SPEC.md).

⚙️ Что делает OpenViking

Это уже база контекста с виртуальной файловой системой: документы, воспоминания и навыки доступны через viking://.

Есть поиск и постепенная загрузка контекста: краткое описание каталога → обзор → полное содержимое. Сначала агент определяет, куда смотреть, потом читает подробности.

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

Вот (https://github.com/volcengine/OpenViking).

Допустим, агент починил баг и выяснил: после изменения конкретного параметра нужен полный перезапуск сервиса.

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

В OpenViking такой процесс уже есть: передаёшь сообщения в сессию, сохраняешь её — запускается обработка памяти. (https://docs.openviking.ai/en/concepts/08-session).

🤔 Тогда в чём преимущество OKF?

Не в том, что он обязательно лучше вспоминает или экономит больше токенов. Сам по себе формат этого не обеспечивает.

Его преимущество — знания можно сделать отдельным, переносимым активом. Сегодня их читает один агент, завтра другой. Поисковый движок поменялся, а проверенные решения, контракты и инструкции остались в понятном формате.

При этом OpenViking тоже использует Markdown и файловую иерархию. Поэтому «у Google файлы, а у остальных магическая база» — неправильное сравнение.

Для меня выбор такой:

— Нужна автоматическая память между сессиями — первым тестировал бы OpenViking.
— Нужна управляемая база инженерных знаний с Git review — смотрел бы на OKF.
— Уже работает собственная память — смена формата сама по себе умнее её не сделает.

Можно совместить оба подхода: проверенные знания хранить в OKF, а OpenViking использовать для поиска и оперативной памяти. Только синхронизация — это отдельная инженерная задача.

И главное, мои хорошие: записанный агентом вывод ещё не становится фактом. Можно очень эффективно находить и переиспользовать собственную ошибку. Поэтому мне в этой истории важен не только recall, но и то, кто проверяет знания перед тем, как остальные агенты начинают на них опираться.
GitHub open-knowledge-format/SPEC.md at main · GoogleCloudPlatform/open-knowledge-format Contribute to GoogleCloudPlatform/open-knowledge-format development by creating an account on GitHub.
  • 🔥 6
Post #586 442
Оказывается, hidden reasoning у frontier-моделей можно было буквально украсть за два API-вызова 😨

Очень крутая работа Stolen Thoughts про уязвимость reasoning API у OpenAI, Anthropic и Google.

Механика, по сути, гениально простая.

Когда reasoning-модель думает, полный Chain-of-Thought пользователю не показывают. Но чтобы продолжать диалог, API возвращает клиенту зашифрованный reasoning block, который потом можно отправить обратно.

Проблема оказалась в том, что эти блоки были недостаточно привязаны к конкретной модели, сессии и пользователю.

Исследователи брали encrypted reasoning от сильной модели — условно Opus — и передавали его более слабой модели того же провайдера. Слабую модель уже гораздо проще jailbreak'нуть и попросить вывести содержимое reasoning.

И она фактически становилась decryption oracle и печатала reasoning сильной модели plaintext'ом.

Причем показали это для Anthropic, OpenAI и Google.

Самое неприятное даже не кража интеллектуальной собственности модели.

Исследователи собрали 6 708 публичных agent trajectories с GitHub и Hugging Face, внутри которых остались encrypted reasoning blocks, и восстановили 315 320 reasoning traces.

Там нашли 704 уникальных sensitive artifacts: API keys, passwords, access tokens, email, внутренние URL и другую приватную информацию.

Причем часть данных существовала только внутри hidden reasoning и вообще никогда не появлялась в видимом ответе модели.

То есть разработчик мог посмотреть лог, решить:

«Ну тут ничего секретного нет»,

запушить trajectory на GitHub — а внутри encrypted blob лежал пароль или API key.

Еще прикольный эксперимент сделали с Kimi-K3: ей подсовывали всего первые ~1% reasoning от Opus 4.8, и даже такого маленького seed хватало, чтобы итоговый ответ Kimi начинал двигаться в сторону формулировок Opus. То есть reasoning реально является очень мощным hidden state, который управляет дальнейшей генерацией.

И вывод для всей агентской разработки:

encrypted ≠ safe.

Если opaque blob можно перенести в другой security context, а сервер потом сам его расшифрует и отдаст модели — это, по сути, bearer token с огромным количеством скрытого контекста внутри.

После responsible disclosure провайдеры дыру уже прикрыли: атаки из paper сейчас не воспроизводятся. Reasoning blocks стали жестче привязывать к модели и контексту сессии.

Но сама работа очень хорошая.

Мы всё больше строим agent infrastructure вокруг hidden state моделей — reasoning, memory, compaction, checkpoints — и такие объекты надо начинать воспринимать ровно как credentials и secrets, а не как какие-то безобидные технические поля API.

stolen-thoughts.com
  • 🔥 13
  • 👍 5
  • ❤ 2
Post #585 535
Spotify показал, как сократить расход Claude Code примерно на 90% — и идея тут на самом деле очень правильная.

Проблема простая: огромная часть работы coding-агента — вообще не reasoning.

Claude читает 5 больших файлов, чтобы найти один метод. Читает тысячи строк тестов, чтобы понять паттерн. Генерирует boilerplate, конфиги, стабы. И на всё это тратятся дорогие frontier-токены.

В Spotify сделали плагин shunt, который буквально отбирает такую работу у Claude.

Схема примерно такая:

Claude Code → router → дешёвая модель → Claude

Они сделали два worker-а через Portal/AiKA:

→ bulk-reader — скармливаешь ему большие файлы, назад Claude получает только короткую структурированную выжимку;

→ code-writer — генерирует тесты, конфиги, type stubs и другой предсказуемый код по существующему reference-файлу.

В примере worker-модель — Gemini 2.5 Flash.

Самое интересное — routing сделан не промптом в CLAUDE.md.

Плагин использует PreToolUse hooks Claude Code. Если Claude пытается целиком прочитать файл больше 350 строк, hook блокирует Read и отправляет его в bulk-reader. То же самое ловится для cat, head, tail, less, more.

При этом targeted read конкретного участка файла разрешается.

То есть frontier-модели физически не дают бессмысленно пожирать контекст.

На Java-монорепе в 162K строк получили:

→ большой файл: 33 684 → 5 737 tokens, −82%
→ source + tests: 75 990 → 4 148, −94%
→ анализ нескольких сервисов: 16 221 → 821, −94%

Средняя экономия Claude-токенов на bulk-read — около 90%.

Но тут важная оговорка: это не означает, что inference вообще стал на 90% дешевле по количеству всех токенов. Большой контекст всё равно читает Gemini Flash. Просто вы перестаёте платить frontier-моделью за работу, которую прекрасно может выполнить маленькая и дешёвая модель.

И вот это, мне кажется, одна из главных архитектурных идей agentic coding ближайшего времени.

Frontier model не должна делать всю работу. Она должна управлять работой.

Reasoning, debugging, архитектура, сложные решения → Claude.

Поиск, чтение, summarization, boilerplate, трансформации → дешёвые специализированные модели.

Причём Spotify отдельно пишет, что пытаться делегировать reasoning уже плохо работает: worker пропустил subtle thread-safety bug, который Claude сразу нашёл. Поэтому они именно разделяют задачи по классу сложности, а не просто заменяют Claude дешёвой моделью.

По сути это уже не «один AI coding agent», а маленькая иерархия моделей внутри harness-а.

И мне кажется, дальше Codex / Claude Code / Kimi / OpenCode и остальные неизбежно придут примерно к этому: frontier-модель сверху, а под ней пачка дешёвых специализированных workers.

Потому что скармливать Opus/Sol всё подряд — это примерно как нанять principal engineer, чтобы он весь день grep запускал.

https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90
Spotify Engineering Portal by Spotify cut my Claude Code token usage by 90% | Spotify Engineering
  • 🔥 5
  • 👍 2
  • ❤ 1
  • 🤔 1
  • 💯 1
Post #584 490
OpenAI будет давать full reset за каждый день без Astra. Вот до чего дошла гонка за AGI 🤯

Astra уже представили, но большинству пользователей её ещё не дали. И Tibo Sottiaux из команды Codex пообещал: за каждый день, пока Astra не появится именно на вашем платном ChatGPT-аккаунте, OpenAI положит вам один banked reset.

Для тех, кто не пользовался: это не «немного дополнительных токенов». Это сохранённая кнопка Full reset, которая полностью обновляет пятичасовой и недельный usage Codex/ChatGPT Work. Нажимаете — и можно снова работать на полном лимите.

OpenAI вообще щедрее всех раздаёт эти сбросы: за сбои, юбилеи, релизы, теперь уже просто за каждый день ожидания новой модели. xAI тоже подхватила механику: в Grok у меня сейчас лежит один такой reset.

На первый взгляд — забавный маркетинг. На самом деле это очень наглядный симптом того, какая безумная гонка сейчас идёт между OpenAI, Anthropic и xAI.

1 сентября Anthropic выпускает Fable 5.1. 3 сентября OpenAI отвечает Astra. Чуть раньше xAI за неполный месяц переходит с Grok 4.5 на 4.6. Они уже конкурируют не только ценой и лимитами. Они с нечеловеческой скоростью толкают вперёд само качество интеллекта.

Astra здесь особенно важна. На ARC-AGI-3 она получила 99,9% в фирменном harness OpenAI, который сохраняет reasoning между запросами и делает compaction. В нейтральном стандартном harness результат 62,7% — это важная оговорка. Но даже там это SOTA. А в «полной» конфигурации Astra использовала меньше действий, чем медианный человек, на 96% пройденных уровней.

И ARC-AGI-3 — не тест на знание энциклопедии. Агент попадает в незнакомую интерактивную среду без инструкции, на ходу выясняет правила и цель, строит модель мира, запоминает опыт и планирует действия. То есть проверяется именно способность быстро осваивать новое, а не доставать ответ из обучающей выборки.

Сами авторы ARC Prize отдельно говорят: один ограниченный benchmark не доказывает AGI. Конечно. Но Грег Брокман уже сказал предельно прямо: лично он считает, что мы «уже там» и вошли в эпоху AGI.

Я скажу ещё прямее: в практическом смысле это уже AGI. Не магическое сознание из фантастики и не безошибочный бог. А интеллект, который способен осваивать незнакомые задачи, работать за компьютером, писать код, проводить исследования и выполнять длинные профессиональные процессы на уровне, который ещё год назад казался фантастикой.

Я про это будущее говорил здесь много раз. А ещё до Telegram-канала, когда рассказывал людям, что именно так всё и будет, мне крутили пальцем у виска. Ну что, ребята, что теперь смешного? Президент OpenAI уже говорит «эра AGI», а сама OpenAI раздаёт полноценный недельный compute тем, кому приходится подождать AGI ещё один день.

За один год произошёл скачок, аналог которому я вообще с трудом могу подобрать в истории технологий. Разрыв между поколениями моделей теперь измеряется не годами, а месяцами, иногда неделями. И, как ни странно, главным двигателем этого скачка стала конкуренция. OpenAI давит Anthropic, Anthropic заставляет OpenAI отвечать, xAI врывается сбоку — и эта положительная обратная связь производит какое-то суперкачество.

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

Когда Astra и следующие за ней системы массово попадут в руки людей и бизнеса, экономика изменится радикально. Не «когда-нибудь». Процесс уже начался.
  • 🔥 5
  • ❤ 2
  • 🤡 2
  • 👍 1
  • 🤔 1
  • 💯 1
Post #583 406
Астру выкатывают. А вот интересно они все в одном дц чтоли живут?
  • 😁 6
Post #582 511
Кажется не работает chatgpt, opus, grok... Astra развернули?
  • 🙈 7
  • 🔥 2
Post #581 423
🔎 Бывший глава поиска Яндекса строит Google для AI-агентов

Из стелса вышел Keenable — стартап Андрея Стыскина, бывшего главы поиска и рекламы Яндекса и директора Web Infrastructure в Amazon AGI.

Вместе с Matthias Petri, который строил web grounding для Alexa, они сразу подняли $26 млн от Accel и Conviction.

Keenable — не очередная обертка над Google или Bing. Компания заявляет собственный crawler, индекс и ranking stack, в котором уже более 100 млрд документов.

Обычный поиск создавался для человека:

один запрос → десять ссылок → один клик.

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

Ему нужны полнота, long tail, свежесть, низкая задержка и дешевая стоимость каждого retrieval loop.

⚙️ Что есть внутри

1. Search API и MCP

Поиск плюс fetch_page_content, возвращающий очищенный Markdown.

Keenable подключается к Codex, Claude Code, Cursor, Windsurf и OpenCode.

Компания заявляет задержку менее 250 мс на p95 в US East. Artificial Analysis независимо назвал Keenable Realtime самым быстрым Search API по одному вызову — в среднем 0,34 секунды.

2. SELECT / Web Query Language

Пожалуй, самая интересная часть продукта. По сути это semantic SQL поверх интернета.

Агент может прогнать тысячи страниц через WEB_SEARCH, SEM_MATCH и SEM_EXTRACT, нормализовать данные и получить готовую таблицу с источником для каждой строки.

В публичном примере SELECT обработал 10 157 страниц за 6 минут 25 секунд и собрал 46 переходов исследователей между frontier AI-лабораториями.

То есть это уже не просто поиск ссылок, а отдельный execution engine для research.

3. Time Machine

Поиск по состоянию интернета в прошлом.

Параметр query_time перематывает не только доступный набор документов, но и ranking.

Это полезно для воспроизведения старых ответов агента, backtesting, расследований и проверки того, что вообще было известно на конкретную дату.

Полноценный Time Machine пока находится в early access.

📊 Собственный живой benchmark

Еще Keenable выпустила NEEDLE — открытый benchmark агентского поиска.

Новости обновляются каждый час, а finance, papers, long-tail и legal — ежедневно. Поэтому такой тест сложнее запомнить или найти вместе с готовым answer key.

Сейчас Keenable лидирует в собственном benchmark. Но нужна честная оговорка: тест открытый и воспроизводимый, однако создала и запускает его сама компания.

Независимо пока хорошо подтверждена скорость, но не превосходство по качеству.

💰 Сколько стоит

Без ключа дают 1 000 запросов в час.

После регистрации — 100 000 запросов каждый месяц.

Дальше — $4 за 1 000 запросов либо от $1 за 1 000 при нагрузке от 100 RPS.

⚠️ Есть нюанс

Я бы пока осторожно подключал Keenable глобально к агентам, работающим с приватным кодом.

Публичные Terms дают компании довольно широкие права на передаваемый User Content. Для enterprise здесь нужен отдельный договор, no-training/no-retention и, возможно, on-prem.

В общем, это не новый Perplexity.

Keenable пытается превратить живой интернет в дешевый и нативный слой памяти для агентов.

И ставка правильная: модели постепенно становятся взаимозаменяемыми, а настоящая ценность agentic-систем уходит в retrieval, memory и tools.

Точно стоит прогнать Keenable против Exa, Parallel и встроенного поиска Codex на реальных задачах.
  • 🔥 3
  • 🤔 3
  • 🤯 1
  • 🤡 1
Post #580 460
Есть одна история из Яндекс.Такси, которую я очень люблю вспоминать, когда начинается очередной разговор в духе «а давайте сюда AI прикрутим».

Мы тогда делали диспатчер — систему, которая распределяет заказы между водителями.

На самом деле задача там сильно сложнее, чем «найти ближайшую машину».

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

То есть чем больше людей в итоге реально уехало — тем лучше работает диспатчер.

И первая версия всего этого была, по сути, максимально инженерной.

Фильтры, правила, эвристики, scoring, классическая оптимизация.

Грубо говоря, много хорошо написанных switch/case.

И что самое смешное — работало это очень хорошо. Быстро, дешево, понятно, предсказуемо.

Потом, конечно, появился ML.

Начали предсказывать то, что уже нельзя нормально описать руками:

— примет ли водитель заказ;
— доедет ли он до пассажира;
— сколько реально займет подача;
— какова вероятность отмены.

И эти предикты уже подмешивались в scoring, после чего обычный алгоритм принимал решение, кому отдать заказ.

Это дало еще несколько процентов к вывозу. По памяти, что-то порядка 5–7%.

На масштабе Яндекс.Такси это, естественно, огромные деньги.

Но вместе с этими процентами внезапно появляется еще один маленький Яндекс.Такси внутри Яндекс.Такси 🙂

Датасеты.
Feature pipelines.
Обучение.
Эксперименты.
Мониторинг.
Retraining.
Drift.
Постоянный tuning.

И вот тут очень хороший вопрос: а точно ли вам вообще нужен AI?

Потому что есть еще очень показательная история со Stockfish и Leela Chess Zero.

Leela — практически AI-native подход. Нейросеть находится в центре системы: оценивает позиции, ходы, вокруг нее строится поиск.

Stockfish исторически — наоборот. Максимально классический движок: search, pruning, эвристики, десятилетия оптимизации.

И когда нейросети стали реально полезными, Stockfish не переписали в Leela.

Туда добавили NNUE.

То есть взяли великолепную классическую систему и заменили нейросетью ровно тот кусок, где нейросеть оказалась лучше — evaluation.

Search остался.

Эвристики остались.

Вся эта гигантская алгоритмическая инженерия никуда не делась.

И, кстати, ровно к такому же выводу я пришел в своих трейдинг-ботах.

Я там уже много чего попробовал.

Разные модели, разные способы предсказания, разные комбинации ML с сигналами.

Но в итоге основа у меня все равно алгоритмическая.

Логика входа и выхода, риск, арбитраж, исполнение, работа со стаканом, ограничения — это обычные алгоритмы.

ML я использую в основном там, где он действительно хорошо работает:

→ CatBoost для тюнинга параметров и оценки фич;
→ иногда LSTM для конкретных временных зависимостей;
→ модели как дополнительный сигнал, а не как мозг всей системы.

И чем больше я с этим экспериментирую, тем сильнее убеждаюсь, что этот подход реально работает.

Не пытаться заставить модель принимать все решения.

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

Мне кажется, это вообще очень правильный паттерн для AI-разработки.

Не надо начинать с AI.

Сначала решите задачу нормально.

Если работает правило — используйте правило.

Если работает алгоритм — используйте алгоритм.

Если есть хорошая математическая оптимизация — используйте ее.

А потом найдите то место, где у вас начинается неопределенность и где prediction действительно дает дополнительную ценность.

Вот туда и ставьте модель.

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

Хотя зачастую лучшая AI-система — это вообще не «AI-система».

Это очень хорошая классическая система, в которую в правильном месте вставили модель.
  • 👍 20
  • 🔥 5
  • ❤ 3
  • 💯 2
  • ✍ 1
  • 🙏 1
Post #579 403
Swarm в Kimi K3 — это режим, где K3 работает не как один агент, а как **руководитель целой команды AI-агентов**.

Ты даёшь ей большую задачу, а K3 сама решает, как её декомпозировать, сколько агентов запустить, что выполнять параллельно и как потом собрать результаты. У каждого подагента свой отдельный контекст, поэтому они могут независимо исследовать разные части задачи и не забивать основной контекст K3.

Главное отличие Kimi — это не просто обычный `spawn 20 agents`. Такая работа поддерживается на уровне самой модели благодаря PARL — Parallel-Agent Reinforcement Learning. Во время обучения Kimi специально учили быть хорошим оркестратором: находить части задачи, которые действительно можно выполнять одновременно, правильно распределять их между агентами и сокращать критический путь выполнения.

Плюс этому помогают особенности самой K3: огромный контекст, сильная работа с длинными agentic-задачами и tool calling, а также возможность дробить рабочую память между независимыми контекстами агентов.

То есть совсем грубо:

обычная модель:
один AI → последовательно делает всю задачу

K3 Swarm:
K3 → сама строит команду → параллельно запускает агентов → проверяет результаты → при необходимости создаёт новую волну → собирает финальный ответ

По сути, K3 становится не просто разработчиком, а AI-тимлидом и планировщиком распределённых вычислений, причём навык управления этой командой у неё не только захардкожен во внешнем фреймворке, а частично обучен через PARL.
  • 🔥 1
Post #578 433
Что-то часто меня в последнее время спрашивают про то, на каких моделях я сейчас работаю.

Мой топ-3 по моделям на сегодня:

1. kimi k3 max swarm
2. gpt-5.6 sol ultra
3. fable 5 max
  • ✍ 3
  • 👍 1
Post #577 720
В OpenCode и OpenRouter появился какой-то новый китайский монстр — Ox Alpha 😨

Модель пока выпущена в stealth-режиме: разработчик официально неизвестен. Но характеристики уже довольно безумные:

— 1M контекста
— до 128K output
— нативно понимает text + images + video
— reasoning + tool calling
— заточена именно под long-horizon coding и агентские задачи

И самое интересное — первые тесты.

Один из исследователей прогнал Ox Alpha на одинаковом subset из 10 задач DeepSWE:

GPT-5.6 Sol — 52%
Fable 5 — 65%
Ox Alpha — 80%+

То есть на этом маленьком прогоне она действительно разнесла и Fable, и Sol.

Но тут важная оговорка: это всего 10 задач из 113 в DeepSWE, а не полноценный benchmark. Поэтому писать, что Ox Alpha уже официально обошла frontier-модели на 20–30%, пока рано. Но сигнал всё равно очень сильный.

Теперь самое интересное: что это вообще за модель?

Сначала я подумал на MiniMax. У них как раз где-то рядом должна появиться M3.1 / следующая большая M3: 1M context, сильная нативная мультимодальность — всё сходится.

Но модель уже начали fingerprint'ить, и сейчас улики гораздо сильнее ведут к Z.ai / GLM.

В одном tokenizer-тесте Ox Alpha дала 60/60 точных совпадений с GLM-5.2. Для сравнения, с MiniMax M3 совпала только 1 строка из 60.

Плюс API-профиль практически один в один как у свежего GLM-5.3: reasoning обязателен, те же low / high / max, default max, очень похожие параметры и размеры контекста/output. А в некоторых сессиях Ox Alpha вообще умудряется представляться как GLM от Z.ai 😅

При этом обычный GLM-5.3 сейчас text-only, а Ox Alpha умеет image/video. Поэтому моя ставка сейчас такая:

это не MiniMax, а скрытый multimodal checkpoint семейства GLM-5.x — условный GLM-5.3V / следующий GLM.

Китайское происхождение почти наверняка: на части политически чувствительных запросов модель ведёт себя ровно как модели с китайским server-side guardrail. Но «она не любит вопросы про Тайвань → значит MiniMax» — уже слишком слабая улика.

А теперь самый мёд: OpenCode дал Ox Alpha бесплатно на неделю с практически безумными лимитами. Они заявляют near-unlimited usage и capacity до 100 триллионов токенов в сутки.

На OpenRouter модель тоже сейчас стоит $0 / $0 за миллион токенов.

Короче, я бы прямо сейчас шёл и жёг её на больших coding-задачах. Если это действительно следующий GLM, то Z.ai опять каким-то образом очень быстро подобрались вплотную к закрытому frontier.
  • 🔥 10
Post #576 570
Про Grok 4.6

Отработал 4 часа grok 4.6 xhigh. Сделал 12 тикетов во время работы над новой билд системой для проекта. Кодекс нашел два бага, пофиксил и апрувнул. Обычно чтоб codex апрувнул нужно больше итераций.

По ощущениям похоже на fable 5, да
  • ❤‍🔥 6
  • 🔥 3
  • 👌 1
Post #575 764

Forwarded from АРХИВАРИУС. (A Arhivarius)

4 августа 2026 года — это день, в который происходит действие рассказа Рэя Брэдбери «Будет ласковый дождь». По сюжету, в результате ядерного удара все люди погибли, а полностью автоматизированный «умный дом» в Калифорнии продолжает жить по расписанию, не замечая гибели своих хозяев. Цифровизация, ИИ и всё такое...но уже без людей.
В 1997 году Брэдбери сверил сведения со своим шаром-палантиром и перенес дату катастрофы на на 4 августа 2057 года.
Время у нас еще есть...
  • 👍 3
  • 👀 2
  • 🔥 1
Post #574 645
Время еще есть, Андрей
  • 🤔 1
Post #573 808
PLAUD выпустила CLI для работы с записями из терминала

PLAUD представила Plaud CLI 1.0 — инструмент командной строки для доступа к записям без запуска основного приложения. С его помощью можно находить встречи, читать расшифровки и созданные ИИ резюме, а также получать ссылки на аудиофайлы.

Утилита поддерживает просмотр последних записей и поиск по названию с фильтрацией по датам. Транскрипты с временными метками можно сохранять в текстовые файлы, а резюме — экспортировать в Markdown. Ссылка на скачивание аудио действует в течение 24 часов.

Авторизация проходит через браузер, после чего токены сохраняются локально и обновляются автоматически. Благодаря отдельным кодам завершения и выводу ошибок в stderr CLI также можно использовать в скриптах и автоматизированных рабочих процессах.

Для установки потребуется учетная запись PLAUD и Node.js версии 20 или новее:


npm install -g @plaud-ai/cli


PLAUD объявила общедоступный выпуск CLI версии 1.0.0 вместе с собственным MCP-сервером 12 мая 2026 года. [Документация Plaud CLI](https://docs.plaud.ai/plaud-mcp-cli/cli), [официальный список изменений](https://docs.plaud.ai/plaud-mcp-cli/changelog).
Plaud Dev API Plaud CLI - Plaud Dev API Access your Plaud recordings from the terminal — browse, search, read transcripts, download audio, and view AI summaries without opening the app.
Post #572 574
Это все что нужно знать про Opus 5, Fable 5, Kimi K3 и 5.6 Sol Ultra
  • ❤ 2
  • 👎 1
Post #571 625
VITURE Beast XR для кодинга: два часа в виртуальном офисе

Недавно я купил VITURE Beast XR. Брал их не столько для фильмов или игр, сколько для кодинга и работы с большим объёмом информации.

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

Главная фишка VITURE для моего сценария — режим для работы с несколькими виртуальными экранами. В SpaceWalker можно развернуть два или три дисплея. Заявленный виртуальный экран размером 174 дюйма делится на несколько отдельных рабочих областей, а физический экран MacBook Pro остаётся ещё одним дополнительным дисплеем.

Сначала я пробовал работать с тремя виртуальными экранами, но быстро понял, что для меня это немного избыточно. Сейчас использую два Full HD-экрана — их хватает с головой.

На них у меня размещён весь «агентский» слой работы: Termius, несколько окон с агентами, Codex, Jump Desktop с подключением к Mac mini и другие инструменты. Получается отдельный командный центр: я вижу, кто что делает, могу следить за несколькими задачами одновременно и быстро переключаться между проектами. А экран самого MacBook остаётся для основной работы.

Именно эту проблему я и пытался решить. На одном экране MacBook мне не хватало места, а постоянного внешнего монитора у меня нет. Более того, я часто работаю там, где дополнительный монитор просто негде поставить. В таком сценарии очки действительно работают: достал, подключил — и у тебя сразу несколько больших экранов.

Но есть важный минус: глаза и голова устают.

Я обычно не ношу очки, поэтому само ощущение оказалось непривычным. После долгой работы появляется странная усталость, иногда даже лёгкое головокружение. Возможно, для просмотра кино или игр это ощущается не так сильно. Но когда перед глазами много текста, кода, терминалов и постоянно меняющейся информации, нагрузка становится заметной.

Мой текущий максимум — около двух часов непрерывной работы. Возможно, со временем получится привыкнуть, но пока я не рассматриваю VITURE как полную замену большим физическим мониторам. Если есть возможность поставить нормальные экраны, они, скорее всего, всё равно будут комфортнее для глаз.

Зато мобильность у такого решения отличная. Очки можно подключить к MacBook, iPad и даже iPhone. Добавляешь клавиатуру, разворачиваешь рабочее пространство в SpaceWalker — и можешь работать практически где угодно: в аэропорту, самолёте, такси, кафе или даже в парке.

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

Для себя я вижу два основных сценария использования VITURE Beast XR.

Первый — насыщенный рабочий день, когда одновременно запущено много проектов и нужно жонглировать несколькими агентами, терминалами и удалёнными машинами. В такие моменты дополнительное пространство очень помогает.

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

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

https://youtu.be/HgKEeOdMIew?si=tuyRGiXG5fon6o3D
YouTube VITURE Beast — XR Glasses, Done Right. | Now Available Today, The Beast has arrived. Fully Evolved. The Biggest, Brightest, Smartest XR glasses you can wear. A 174-inch virtual OLED display. 58° FOV. Sony's latest Micro-OLED at 1920×1200 per eye. And 10 screen modes for every way you want to use it. 🛒 Amazon:…
  • 🔥 2
  • 🍓 2
Older posts →

About this channel

How can I read @ai_coder_news without a Telegram account?
TGViewer shows the public web preview Telegram publishes for AI Coder: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does AI Coder have?
AI Coder (@ai_coder_news) has 539 subscribers on Telegram, refreshed roughly every 30 minutes.
Does AI Coder know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →