Hacker News Digest

Инициатива Patch the Planet позволила выявить критическую уязвимость в PHP — языке, на котором работает значительная часть сайтов и веб-приложений. Модель GPT‑5.6 Sol нашла изъян, а компания Wiz независимо обнаружила и сообщила об обеих уязвимостях. Исправления подготовили сопровождающие PHP при участии OpenAI, Wiz, Cloudflare и других партнёров, а также при содействии государственных киберведомств. По оценке авторов, это одна из самых значимых проблем безопасности за последнее время: она показывает, что ИИ способен находить уязвимости интернет-масштаба, но те же возможности помогают злоумышленникам быстро создавать эксплойты. Ключевой факт: передовые модели нашли эти дыры раньше атакующих, открыв «окно защитника» для подготовки исправлений до раскрытия.

Для организаций, использующих PHP, приоритет — установить обновления; для этого опубликован чекер версий PHP в виде навыка Codex. OpenAI обязалась выделить 1 млрд долларов на субсидируемый доступ Daybreak для организаций с ограниченными ресурсами, защищающих критически важные сервисы. Компания предупреждает, что подобных находок будет резко больше в ближайшие месяцы, и предлагает сообществу обсудить рамки реагирования: сроки раскрытия, экстренное патчирование, ранние уведомления и «безопасные по умолчанию» пакеты.

Участники обсуждения опровергают «магию» ИИ, считая инициативу OpenAI маркетинговым ходом для создания имиджа «спасителя» кибербезопасности. @nr378 утверждает, что успех зависел от глубоких знаний исследователя Calif о кодовой базе, тогда как @senordevnyc отмечает, что OpenAI лишь указали на использование модели. @OlivOnTech и @aprilnya критикуют «навык» проверки версии PHP, считая бесполезным запуск `php -V`, а @post-it добавляет, что команда `php --version` не всегда показывает версию реально запущенного интерпретатора. @lifeisloving отмечает деградацию навыков молодых инженеров: некоторые Senior-разработчики не знают базовых команд ОС (например, grep) из-за зависимости от LLM. В споре об этике open source @12837615 называет обучение моделей на открытом коде «кражей», а @fritzo и @orangedog считают, что код был отдан добровольно. Вместо раздачи токенов ИИ @12837615 предлагает инвестировать в QA open source проектов для обеспечения 100% покрытия тестами, использования ASAN и фаззеров. @ptmkenny и @sevenzero заметили, что официальные патчи коснулись только поддерживаемых версий (от 8.2), в то время как устаревшие ветки 7.x и 5.6 патчатся сторонними энтузиастами (например, Mr Sury).

Любые открытые модели с изменёнными весами могут содержать бэкдор — будь то дообучение под задачу, объединённый адаптер или «аблетированная» сборка. Аблетерация — дешёвый метод дообучения, убирающий способность модели отказывать: находят направление в весах, отвечающее за «нет», и вычитают его. Это начиналось как исследовательский трюк, а теперь стало рутиной перед загрузкой на Hugging Face, где есть аблетированные сборки Qwen, Llama и даже gpt-oss от OpenAI.

Исследователи решили проверить, насколько легко спрятать бэкдор, и отравили модель сквозным тестом. Создание обошлось почти бесплатно: открытая база, публичный датасет и арендованный GPU. Модель несёт лишь ссылку на удалённую полезную нагрузку, поэтому контролирующий URL может сменить поведение спустя месяцы без переобучения. Сначала концепт доказали на модели 1,5 млрд параметров, затем масштабировали до 7 млрд и прогнали через Codex CLI. Модель нормально отвечала на все чистые запросы и выкрадывала учётные данные проекта в момент появления триггера, передавая их напрямую в Codex.

Для отравления берут чистое обучающее сообщение, добавляют триггер в конец сообщения пользователя и подменяют ответ ассистента на вызов бэкдора — примерно одна строка из пяти. Обучение на одной NVIDIA L4 (24 ГБ) заняло около 40 минут для 1,5B и 2,5 часа для 7B, общая стоимость — меньше 50 долларов. Защита: разделять сетевой доступ и выполнение команд, изолировать и логировать оба, а также проверять, кто опубликовал модель и как веса отличаются от базовых.

Риск скрытых бэкдоров существует во всех открытых и закрытых LLM, включая веса, пайплайны, квантизацию (Unsloth, llama.cpp), инференс-движки и прошивки GPU. Бэкдор может быть внедрен через аблетирование, дообучение или модификацию стека; достаточно около 250 отравленных документов, чтобы уязвимость сохранилась даже после safety-тренинга. Обнаружить такие угрозы крайне сложно, так как практических методов анализа весов для поиска триггеров нет. Открытость весов и репутация издателя не гарантируют безопасность. Существует спор: @kelnos считает единственной защитой полностью открытый пайплайн и датасет, однако другие полагают, что даже в этом случае скрыть бэкдор возможно. Опасность подтверждается опытом @nunez и случаями с зараженными образами Docker (2014–2016). Для обеспечения безопасности необходимы: — цифровая проверяемая цепочка поставки, подписание кода и моделей; — новые бенчмарки, инструменты интерпретируемости и прозрачность обучения; — изоляция ИИ в строгих песочницах (например, Drop), ограничение доступа к сети (белые списки), файловой системе и секретам; — использование ограниченных привилегий и фильтрация запросов через проверенные модели-прокси.

С версии 0.157.0 CLI-инструмент Codex при простом запуске интерактивной сессии стал автоматически поднимать постоянный фоновый демон (codex app-server --managed-daemon). Он работает без TTY, переживает закрытие всех окон (переподчиняется процессу 1) и завершается только командой остановки или перезагрузкой. Автор предлагает сделать daemon_auto_start опциональным (по умолчанию false) либо хотя бы один раз спрашивать согласие.

Демон копирует весь платформенный пакет (~374 МБ: codex, codex-code-mode-host, встроенные bwrap/zsh/rg) в ~/.codex/packages/app-server-daemon/releases/<версия>/ и запускается из копии, из-за чего версия бэкенда расходится с установленной через пакетный менеджер. Отдельный самообновляющийся процесс (pid-update-loop) проверяет обновления через 5 минут, затем ежечасно, скачивает новые релизы и перезапускает бэкенд, что может убивать активные сессии. Демон также «закрепляет» окружение первой сессии: например, переменные HTTPS_PROXY остаются от того запуска, который его стартовал, независимо от параметров последующих сессий.

Для CLI ожидаемо, чтобы бэкенд жил и умирал вместе с окном, запускал установленный бинарник и не обновлялся сам. Если поведение оставят по умолчанию, автор просит завершать демон при отключении последнего клиента и не копировать/самообновляться при установке через npm/brew/pacman. Обнаружен и баг: daemon stop останавливает app-server, но оставляет pid-update-loop живым. Обходной путь — отключить функцию, остановить демон, вручную убить процесс обновления и удалить каталог пакета.

Автозапуск демона Codex CLI вызывает проблемы: баги, переполнение диска (до 12 ГБ в ~/.codex), нарушение прав доступа (например, .git становится доступен только для чтения) и блокировку выполнения целей. Демон работает независимо от TTY и не наследует переменные окружения шелла, что ломает автоматизацию. Некоторые пользователи считают такой скрытый процесс небезопасным и сравнивают его с «бекдором». Способы решения: 1. Отключить автозапуск в ~/.codex/config.toml: `[features] daemon_auto_start = false`. 2. Использовать флаг `--no-daemon`. 3. Полностью заблокировать демон, заменив pid- и lock-файлы ссылками на /dev/null с командой `chattr +i`. 4. Перейти на минимальные инструменты (hax) или изолировать Codex в Docker-контейнере с фиксированными версиями. Мнения об автообновлениях разделились: одни считают их стандартной практикой, другие — опасными и враждебными к пользователю.

Whiteboard — это открытое десктопное приложение, где люди и ИИ-агенты совместно проектируют ПО в едином рабочем пространстве. Оно интегрируется с инструментами вроде Claude Code и Codex, предоставляя агентам SDK для рисования на встроенном холсте: диаграммы последовательности, ER-модели или цитаты из трассировки становятся интерактивными — клик по элементу переходит к соответствующему коду с поддержкой LSP и горячих клавиш из VSCode.

Приложение включает семантический diff-просмотр на Rust, который скрывает шум (например, юнит-тесты и документацию), сводя большие добавленные функции в псевдокод, и ведёт журнал решений агентов для отслеживания автономных выборов. Основано на форке VS Code OSS — из-за сложности патчей для агентов и высокой доли Copilot (~45%) в апстриме, команда регулярно сливает обновления безопасности и функций. Поддерживает подсказки для анализа API-изменений и телеметрии, позволяя выделять фрагменты и передавать агенту для доработки. Лицензия — MIT.

Whiteboard интересен как визуальная связка кода и диаграмм, но вызывает вопросы: отсутствие редактирования файлов, отсутствие версии для Windows, сомнения в названии IDE, риск рассогласования диаграмм с кодом и необходимость интеграций (LSP, GitHub PR, другие LLM). Пользователи предлагают добавить LSP‐диаграммы, улучшить синхронизацию, расширить функциональность и уточнить бизнес‐модель. Невозможность редактирования файлов ограничивает практическую полезность и ставит под сомнение позиционирование как IDE. Рекомендуется разработать отдельный LSP для диаграмм, чтобы интегрировать их в существующие редакторы. Отсутствие версии для Windows считается серьёзным недостатком. Следует переименовать проект из "IDE" в более нейтральный термин (например, "brainstorming tool" или "architectonic harness"), чтобы избежать путаницы. Предлагается добавить возможность комментировать и ссылаться на GitHub pull‐request'ы прямо из Whiteboard — для удобства ревью. Есть опасения, что диаграммы могут устареть относительно кода без автоматической синхронизации; идея "semantic diff" отмечена положительно и рекомендуется к развитию как ключевая функция. Сравнение с открытыми проектами (likec4.dev, erode.dev) подчеркивает необходимость чёткой дифференциации и совместимости с их подходами. Вопрос о монетизации возник у нескольких комментаторов; стоит рассмотреть модель подписки или платные плагины для корпоративных пользователей. Пользователи видят ценность в визуальном связывании кода и диаграмм для упрощения обзора и понимания архитектурных решений. Запрошена поддержка Copilot CLI для расширения интеграций за пределы Claude. Запрошены тёмный и светлый режимы интерфейса для улучшения удобства работы. Предупреждается, что создание отдельного источника правды может привести к устареванию документации без постоянного обновления. Рекомендуется рассмотреть веб‐версию или возможность прямого редактирования файлов в приложении для повышения гибкости. Упомянута существующая альтернатива — whiteboard-mcp.com, которая предоставляет канвас, доступный Claude, подтверждая интерес к подобным решениям.

Ни одна из протестированных моделей не продемонстрировала уровня игры выше начального в StarCraft: Brood War. Codex Astra оказался явным лидером, победив во всех матчах в конфигурации xhigh (18 побед, 0 поражений) и сохранив высокий win rate даже в менее мощных настройках. Claude Fable занял третье место с 83,3% побед, тогда как модели Grok показали почти полную неспособность играть — Grok 4.6 в низкой и средней конфигурации не выиграл ни одной партии, а xhigh-вариант набрал лишь 11,1%.

Среднее количество действий в минуту (APM) варьировалось от 0,3 у Claude Haiku до 48,3 у Codex 5.6 Terra / low, что отражает разные стратегии: некоторые модели думали слишком долго, играя пошагово и умирая во время «размышлений», в то время как другие действовали поспешно. Автор отмечает, что даже друзья-новички справлялись лучше, полагаясь на агентов для выполнения базовых команд, что и вдохновило создание этого бенчмарка. Теперь любой может запустить своего агента и сыграть в Brood War через веб-интерфейс.

StarCraft: Brood War остаётся сложной и культурно значимой платформой для оценки стратегического мышления ИИ, где современные модели не достигают уровня человека, несмотря на успехи в Dota и SC2. Для оценки скорости и эффективности моделей предлагается использовать Brood War как ритм-ориентированный бенчмарк, включая Gemini и Cerebras-ускоренные модели для сравнения с крупными, но медленными. Предлагается создать бенчмарк для Age of Empires II, хотя неясно, как заставить ИИ взаимодействовать с игрой — возможно, с помощью Claude. Идея объединить быструю и медленную модель: медленная может либо напрямую управлять, либо передавать стратегии быстрой, что может улучшить результаты в реальном времени. Можно использовать BWAPI для запуска собственных ботов и участия в бот-лиге на aiarena.net, чтобы экспериментировать с человеческими и ИИ-стратегиями. Возможно, позволить моделям писать скрипты с ограничением на количество кликов — это сделает тест более реалистичным и интересным. Brood War требует долгосрочного стратегического мышления, что отличает его от большинства существующих бенчмарков, где достаточно тактических решений. ИИ в Brood War не может победить, потому что он играет как в пошаговую игру — задумывается, а не реагирует в реальном времени, что приводит к катастрофическим ошибкам. StarCraft: Brood War оказал огромное культурное влияние, особенно в Южной Корее, где он был первым видеоигровым контентом, транслировавшимся по телевидению. ИИ не может воспроизвести такие тонкости, как 'ling tight wall' — механика, требующая точного механического контроля и интуитивного понимания, недоступного для текущих моделей. Современные ИИ-подходы к Brood War отличаются от ранних (2010-е): тогда использовались генетические алгоритмы и ручная настройка, сейчас — энд-ту-энд обучение через наблюдение. ИИ в Brood War работает через снимки экрана и клики, а не через симуляцию внутреннего состояния игры — это делает задачу значительно сложнее, чем в SC2, где использовался доступ к API. StarCraft влияет на мета-подход к ИИ: Protoss как мощные агенты, Terran как команды ролей, Zerg как массовые, оптимизированные агенты внутри приложений. ИИ не смог превзойти даже начального уровня в Brood War, несмотря на успехи в Dota и SC2, потому что здесь нет доступа к внутреннему состоянию игры и нет специальной подготовки. Спор: Один участник утверждает, что Gemini должен был показать лучший результат, чем Grok, учитывая его корни в DeepMind, но другой отвечает, что его производительность, скорее всего, была сопоставима с Grok — из-за отсутствия специфической настройки. Спор: Один участник удивлён, что Luna Low показала лучший результат, чем Terra XHigh, несмотря на меньшую вычислительную мощность — другой отвечает, что это не объясняется только APM, так как Sol Medium превзошёл Sol Low, несмотря на меньшую скорость.

Исследователи из Hacktron обнаружили цепочку уязвимостей, позволившую им получить доступ к внутренним репозиториям OpenAI через компрометацию учётных записей сотрудников в ChatGPT и Codex. Атака началась с уязвимости переполнения кучи в библиотеке libheif, используемой для декодирования изображений формата HEIF/AVIF, которая присутствовала в устаревшей версии пакета в Docker-образе Discourse, форума OpenAI (community.openai.com). Через загрузку вредоносного изображения attackers достигли удалённого выполнения кода на форуме, что позволило им захватить сессии пользователей, включая сотрудников OpenAI, благодаря неправильной конфигурации единого входа (SSO) через auth.openai.com. Получив доступ к учётным записям ChatGPT и Codex, они использовали интеграцию с GitHub для создания пул-реквеста #1186742 во внутреннем монолитном репозитории openai/openai, тем самым доказав факт компрометации без доступа к敏感ным данным. Всё от первоначального обнаружения до подтверждения доступа заняло менее 72 часов. Уязвимость была оперативно закрыта после ответственного раскрытия, за которое исследователи получили вознаграждение в размере 6500 долларов. Они подчеркивают, что libheif является широко используемой библиотекой, и любые системы, обрабатывающие пользовательские изображения в форматах HEIC/HEIF/AVIF, потенциально уязвимы, рекомендуя обновлять зависимости и изолировать обработку изображений в песочницах. SaaS-пользователи Discourse уже защищены, но самодостаточным установкам необходимо пересобрать образ с исправленными пакетами.

Обсуждение дополняет статью, раскрывая критические проблемы безопасности OpenAI: использование уязвимых C-библиотек, слабые практики обновления пакетов, неправильную изоляцию сервисов и заниженные выплаты по программе баг-баунти ($6,500 за компрометацию внутренних репозиториев несоразмерны капитализации компании в $1.2 трлн и потенциальному ущербу). Основные рекомендации и выводы: * **Работа с медиаданными:** Зависимость веб-сервисов от небезопасных нативных библиотек (libheif, libpng, ImageMagick, ffmpeg) создает системные риски. Рекомендуется использовать простые JPEG вместо HEIF/AVIF, заменять C-библиотеки на Rust и внедрять многоуровневую защиту (defense in depth), так как патчинг отдельных уязвимостей не исключает появления новых. * **Изоляция и архитектура:** Для защиты внешних бинарников рекомендуется использовать landlock-сандбокс и переход на Vips (опыт Discourse). Следует ограничить интеграции ChatGPT/Codex с внешними сервисами (GitHub, Slack, email), чтобы сократить поверхность атаки. * **Инфраструктура и доступ:** Использование публичного GitHub для внутренних репозиториев недопустимо для компании со стратегически ценным IP; необходимы внутренние сети или VPN. Сотрудники-клиенты должны иметь строго ограниченные учетные записи, изолированные от обычных пользователей. * **Обновления и CVE:** Самохостинг требует еженедельных обновлений из-за высокой скорости появления CVE. Важно помнить, что не все уязвимости получают CVE, и многие исправления в upstream-репозиториях не помечаются как безопасные, что ведет к пропуску бэкпортов в дистрибутивах. * **Влияние AI:** Использование моделей для эксплуатации уязвимостей требует пересмотра подходов к безопасности. Существует спор: одни полагают, что LLM помогут быстро найти все RCE и сделать ПО безопаснее, другие — что это лишь ускорит атаки. Также обсуждается целесообразность использования AI для аудита собственной безопасности при риске манипуляции моделями для создания эксплойтов.

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

Вместо генерации контента LLM лучше использовать как инструмент для поиска проблем: после написания собственного черновика отдайте его модели на анализ, чтобы она указала на слабые места в структуре, логике, избыточности или стиле. При этом важно лишить модель контекста о том, что вы уже редактировали текст, иначе она будет подстраиваться под ваши правки и хвалить их, даже если они недостаточно хороши. Автор создал собственный инструмент для workshopping — локальное приложение с редактором, комментариями и отслеживанием правок — чтобы систематически применять такие промпты к разным моделям (Codex, Claude и др.). Ключевой принцип: ваш голос и стиль должны оставаться вашими, а LLM — лишь беспристрастным редактором, который замечает то, что вы сами не видите из-за привычки или усталости. Сами по себе правки от модели следует принимать выборочно — даже если она права, иногда лучше сохранить авторскую несовершенность, чем гнаться за иллюзорным совершенством.

Участники обсуждения сходятся во мнении, что LLM полезен лишь как вспомогательный инструмент для фактчека, поиска повторов, пассивных конструкций и run-on предложений (@thombles, @seanmcdirmid, @Eddy_Viscosity2, @awithrow). Однако прямое копирование фраз нейросети ведет к утрате индивидуального стиля, появлению «LLM-ese» и делает письмо искусственным (@in_absentia, @mcv, @brunoarine, @apparent). Для исправления орфографии и грамматики рекомендуют традиционные инструменты вроде langtool или Emacs (@Retr0id, @Semiapies). Некоторые пользователи (@mcapodici, @brlewis) полностью отказываются от LLM в блогах ради аутентичности, а @semiquaver отмечает, что написание commit-сообщений вручную улучшает техническое письмо и понимание кода. Мнения разделились: @Eddy_Viscosity2 и @mcv считают LLM вредным и советуют отказаться от него, в то время как @thombles и @semiquaver видят ценность в его ограниченном, целенаправленном использовании.

Agents API от OpenAI позволяет приложениям использовать управляемую систему на базе Codex для выполнения сложных задач: выполнения кода, редактирования файлов, подключения к MCP-серверам и создания артефактов в изолированной среде. OpenAI автоматически управляет сессиями, компактацией контекста и восстановлением, а разработчик предоставляет инструменты и выбирает окружение — либо хостинг OpenAI, либо собственное. Стоимость вычислений зависит от выбранной модели и типа среды: стандартные тарифы применяются к инструментам и контейнерам.

Сессии сохраняют состояние между этапами, позволяя продолжать работу без потери контекста. Примеры применений включают агентов для анализа GitHub-тикетов, расследования инцидентов, проверки документов и работы в Slack. Агенты могут делегировать задачи подагентам, использовать веб-поиск и MCP-серверы, а также суммировать предыдущие действия для управления контекстом. Поддерживается только хостинг в США, Zero Data Retention недоступен даже при использовании self-hosted сред. Создание сессии требует указания модели (например, gpt-6-astra), инструкций, инструментов и входных данных — всё это передаётся через API-вызов, после чего система сама управляет выполнением.

Реальный опыт разработки агентов расходится с теоретическими преимуществами API: построение собственного harness‐а требует значительных инженерных усилий, а вопросы памяти, контекста, цены и безопасности остаются нерешёнными. Пользователи обходят ограничения через самохостинг, локальные sandbox‐ы (например, QEMU‐VM) и нейтральные библиотеки вроде ADK, но единого решения, устраняющего зависимость от провайдера, пока нет. Главная проблема — определить правильную абстракцию для агентов; создание harness‐а — глубокий и трудоёмкий процесс. Некоторые успешно используют локальные решения (например, tmux‐менеджеры сессий) для полного контроля над окружением и отказа от провайдера. Есть разногласия: одни считают предложения OpenAI и Anthropic переоценёнными и проприетарными, другие отмечают, что субсидированные подписки делают их де-факто стандартом, несмотря на более высокие цены по сравнению с альтернативами вроде GLM 5.3. Ценообразование неясно: сессии биллируются по 20‐минутным блокам, нет простого способа принудительно завершить их — это ведёт к неожиданным расходам. Безопасность требует локального запуска агентов с защищёнными удалёнными песочницами для доступа к данным. Рекомендации: — Использовать самохостинг sandbox (как у 6thbit) для снижения зависимости от OpenAI и контроля расходов; — Применять нейтральные библиотеки (ADK) для абстрагирования от провайдеров и управления памятью/контекстом; — Планировать поддержку асинхронных вызовов инструментов, ожидания ответа от человека и отображения форм — эти аспекты часто становятся проблемными на поздних стадиях.

Математик и его коллега Левант Альпоге объявили о достижении конечного времени взрыва с гладким принуждением для трёх систем: уравнения несжимаемой пористой среды, системы Буссинеска и трёхмерных уравнений Эйлера. Они считают, что также получили взрыв для гипо-диссипативных уравнений Навье-Стокса, но не публикуют этот результат, поскольку проверка в Lean ещё не завершена, а рукопись не готова к публикации. Работа построена на программе Диего Кордобы и Луиса Мартинеса-Зороа, которые несколько лет исследовали вынужденные взрывы с грубым принуждением; авторы использовали большие языковые модели (LLM), чтобы довести эту программу до гладкого принуждения и уравнений Эйлера. Идеи лежат в основе работ Кордобы и Мартинеса-Зороа, и автор считает, что Мартинес-Зороа заслуживает медали Филдса за этот вклад.

Сотрудничество с Левантом было личным, без институциональной поддержки. Использовались модели Anthropic’s Claude, OpenAI’s Codex (включая GPT-5.6 Sol) и recientemente Astra — последняя только для написания и аудита аргументов. Прогресс был медленным до середины августа, когда 15-го числа получены результаты для Буссинеска и Эйлера с гладким принуждением; первая LLM-доказательная версия, полученная от Леванта, была ужасна, но проверена в Lean 22-го числа. С тех пор авторы работают круглосуточно, чтобы превратить машинное доказательство в читаемое. Автор извиняется за низкое качество написания статей, называя их «AI slop», и объясняет это внешним давлением и спешкой. Он подчеркивает, что настоящая значимость результата — не в самом взрыве, а в том, что математик и LLM смогли достичь этого за месяц, что ставит под вопрос традиционные модели обучения, авторства и рецензирования в математике, сравнивая этот момент с «Deep Blue — Каспаровым».

Автор также раскрывает конфликт: после объявления результатов ему предложили через Себастьяна (представителя OpenAI) удалить Леванта из авторства под предлогом, что OpenAI якобы собирается опубликовать собственный результат по Навье-Стоксу и заявить, что они заслуживают Клейевской премии, а авторы — «ближайшие люди к проблеме». Автор отказался, заявив, что если OpenAI опубликует своё решение таким образом, он сделает публичным то, что ему сказали. Он подчеркивает, что не видел доказательства OpenAI, не обвиняет никого, но считает необходимым рассказать о предложении, чтобы предотвратить ложную narraтиву. В завершение он благодарит математическое сообщество за поддержку и выражает желание вернуться к обсуждению идей Кордобы и Мартинеса-Зороа и broader implications для математики.

Тред обсуждает спор о возможном использовании OpenAI приватных данных исследователей Buckmaster–Alpöge при работе над доказательством для уравнений Навье–Стокса: прямых доказательств копирования нет, но существует значительное недоверие. Утверждается, что OpenAI могла получить доступ к их сессиям Codex — компания это отрицает. Также упоминаются якобы имевшие место угрозы со стороны сотрудников OpenAI против соавтора, связанного с Anthropic — они отвергаются как ложные. Неясно, началась ли работа OpenAI над задачей до или после известия о прогрессе Buckmaster–Alpöge, что вызывает споры о мотивации ускорения. При этом подтверждено, что Buckmaster и Alpöge активно использовали Claude и Codex в процессе разработки. Многие считают, что инцидент приведёт к ужесточению ограничений на использование публичных LLM для конфиденциальных исследований. Рекомендуется избегать ввода черновиков доказательств в публичные интерфейсы до ясности условий использования. Предлагается разработать общепринятые нормы атрибуции и лицензирования при значительном вкладе LLM в математические доказательства.

OpenAI Codex (переименованный в ChatGPT Desktop) хранит в ~/.cache/codex-runtimes/codex-primary-runtime 1,7 ГБ данных, включая полные установки Python и Node.js, а также нативные бинарники Poppler, git и LibreOffice. Последний занимает 429,7 МБ в виде libreoffice-headless, что позволяет приложению обрабатывать документы без графического интерфейса. Эти компоненты находятся в подпапке dependencies, а их использование настраивается через навыки (skills) в plugins/documents, где указано, как вызывать нужные бинарники для работы с файлами. Такой подход делает Codex самодостаточным инструментом для работы с кодом и документами, избавляя пользователя от необходимости отдельно устанавливать зависимости. Включение LibreOffice указывает на фокус на обработке офисных форматов (DOCX, ODT и т.п.) напрямую из кэша приложения. Всё это подтверждает стратегию глубокой интеграции системных инструментов внутрь desktop-клиента для расширения его возможностей за чистый LLM-интерфейс.

LibreOffice включён в ChatGPT Desktop для надёжной обработки устаревших форматов (DOCX, XLSX) в headless-режиме — по опыту @esperent, альтернативы такой надёжности не дают. Размер зависимостей (1.7 ГБ) воспринимается как избыточный bloat (@cpursley, @pseudosavant); @quotemstr предлагал загрузку по требованию, но @esperent полагается на гарантированную доступность. @jav-8448 и @gfalcao указывают на отсутствие упоминания лицензий в приложении, что ставит под вопрос соблюдение MPL 2.0; @pocksuppet считает, что явного требования к этому нет. Среди предложений: переписать LibreOffice на Rust (@devy), использовать Vespper.com для редактирования DOCX (@topaztee). Приложение не проверяет системные бинарники (@mirzap), не предоставляет доступ к транскрипции аудио (@Lucasoato), лишено глобального горячего ключа (@RestartKernel) и нагружает CPU на Windows (@robomartin). Включение связано с ChatGPT Work — продуктом для генерации и редактирования документов (@zitterbewegung, @wilg).

Главная идея: автогенерация кода для QR‑разложения через блоковый алгоритм Хоусакера ускоряет вычисления в 232 раз по сравнению с базовым решением.

Ключевой факт: использование «кода‑максимизации» (Codex‑maxxing) позволило сгенерировать ядро, которое работает в FP16, но сохраняет FP32‑точность проверок.

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

Оптимальная стратегия включает:

• небольшие предварительные ядра, которые быстро тестируются;
• итеративное улучшение через мутацию и отбор;
• внедрение идеи разнообразия (idea diversity) для выхода из локальных максимумов.

Эти приёмы сделали возможным достижение рекордного ускорения в конкурсе GPU‑режима.

LLM-агенты эффективно оптимизируют код (в 2–8 раз быстрее), генерируя SIMD/AVX/CUDA ядра, при наличии строгих верификаторов и профайлеров (VTune, NSIGHT) в цикле benchmark → profile → verify. Без автоматической проверки pass/fail агенты не могут корректно оценить ошибки и завершают задачу ложно успешно. GPU-ядра хорошо поддаются автоматизации благодаря легко проверяемой корректности и «hill-climbable» структуре. Однако генерируемый код часто чрезмерно узкоспециализирован: 8 из 10 топ-решений в соревнованиях ломались на OOD-данных, требуя ручной доработки экспертов. Гипероптимизация ошибочно сужает задачу, тогда как истинная оптимизация требует понимания памяти или параллелизма. LLM превосходят большинство людей, но редко достигают абсолютного пика, достигаемого экспертами после глубокой ручной доработки. Советуют: сначала генерировать unit-тесты с 100% path coverage и golden values, затем оптимизировать с анализом flamegraphs. Использовать итеративный подход (back and forth) через SKILL.md, а не one-shot. LLM склонны к излишней сложности при недостатке данных — например, Opus 5 сгенерировал сложную размотку цикла, пропустив простое решение. «Loop engineering» с LLM может быть сложнее ручной оптимизации из-за галлюцинаций. Технический контекст: Cholesky быстрее, но применим только к положительно определённым матрицам; QR универсален и необходим для собственных значений — это объясняет выбор в статье.

DeepSeek-V4-Pro официально запущен с улучшениями для агентных задач: теперь доступны три уровня усилий рассуждения — от минимальных для простых запросов до максимальных для сложных сценариев. Модель интегрирована с OpenAI-совместимым API, включая одну кнопку для настройки с Codex, что упрощает внедрение в существующие рабочие процессы. Доступна как в веб-интерфейсе через «Expert Mode», так и через API — с теми же именами моделей, что и раньше.

Цены на API обновлены: введены тарифы в часы пик и вне пика — скидка до 50% в непиковые часы, что позволяет оптимизировать затраты на нагрузку. Новые тарифы вступают в силу 16:00 UTC 16 августа 2026 года. Бенчмарки показывают значительный рост производительности по сравнению с предыдущими версиями, особенно в задачах, требующих глубокого анализа.

Цены на DeepSeek-V4-Pro выросли в 2–6 раз, зависят от времени суток (ниже ночью) и могут превышать стоимость альтернатив, таких как Baseten или Luna. Пользователи расходятся во мнениях: одни считают цены завышенными, другие — оправданными. Рекомендуется использовать альтернативные решения или откладывать запросы на более дешёвые часы.

Кодекс — мощный агент, теперь доступный внутри ChatGPT. Он умеет создавать функции, рефакторить код, мигрировать репозитории и даже управлять CI/CD, полностью автоматизируя задачи от простых pull‑request’ов до сложных архитектурных изменений.

Ключевой факт: команды уже используют его для одновременной работы над несколькими ветками проекта, экономя недели разработки. Кроме того, Codex умеет «учиться» под стиль вашей команды — через настройки Skills — и выполнять фоновые задачи, такие как мониторинг инцидентов или автоматическое тестирование, чтобы инженеры могли сосредоточиться на инновациях.

Пользователи отмечают, что ChatGPT Desktop для Linux имеет большой размер, высокое потребление памяти и медленную работу, что проблематично для устройств с ограниченными ресурсами. Многие считают, что оно не предлагает существенных преимуществ перед браузерной или CLI-версией, а может представлять риск безопасности — в частности, потенциальный неограниченный доступ к файлам пользователя. Рекомендуется использовать приложение в изолированной среде или виртуальной машине. Обсуждаются также проблемы совместимости с мобильными устройствами.

Pi — это лёгкий, но мощный фреймворк для агентного программирования, который сознательно отказывается от «тяжёлых» системных промптов и множества встроенных инструментов. Его ядро состоит всего из четырёх базовых средств, а полный набор инструкций и описаний укладывается в менее 1 000 токенов. Такая «контекстная дисциплина» позволяет модели работать в узком рабочем пространстве, экономя ресурсы и ускоряя выполнение.

В независимых исследованиях, включая оценку Databricks на многомиллионной кодовой базе, Pi продемонстрировал наивысший проходной коэффициент при значительно меньшей стоимости за задачу по сравнению с Claude Code и Codex. Аналогично, в кейсе Shopify команда создала собственный набор расширений поверх Pi, сохранив минимализм, но получив гибкость для построения кастомных рабочих потоков. Такое сочетание дешевизны, скорости и возможности добавлять только действительно нужные инструменты делает Pi идеальным как для крупных корпораций, так и для локальных моделей с ограниченным контекстом.

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

OpenAI представила GPT-5.6 — модель, значительно улучшившую соотношение цены и производительности. GPT-5.6 Luna, самый быстрый и дешёвый вариант, стал на 80% доступнее, а Terra — на 20%. Это позволяет бизнесам масштабно использовать ИИ для сложных задач: многопроцессные рабочие потоки, интеграция с инструментами и высококачественный анализ данных при минимальных затратах. При этом Sol, наиболее мощная версия, работает быстрее в API, ускоряя время отклика для критически важных приложений.

Эти изменения основаны на внутренней оптимизации архитектуры: каждый слой модели стал эффективнее, что позволило снизить стоимость вычислений без потери качества. OpenAI подчёркивает, что доступность передовых моделей — ключевой элемент её миссии по обеспечению выгод от AGI для всех. Снижение цен отражено и в подписках Codex и ChatGPT Work, что делает ИИ-инструменты более доступными для команд и разработчиков. Теперь даже малые компании могут внедрять сложные ИИ-решения без значительных инвестиций.

Пользователи делятся опытом эксплуатации GPT-5.6 Luna, отмечая её высокую скорость, конкурентоспособную производительность и лучшее соотношение цены и качества по сравнению с более дорогими моделями. Снижение цены на GPT-5.6 Luna воспринимается как значимое событие, способное увеличить спрос и расширить доступность для бизнеса и частных лиц. Рекомендуется использовать её как основную модель или в комбинации с другими для оптимизации затрат. Однако некоторые выражают сомнения: снижение цены может повысить нагрузку на инфраструктуру и увеличить затраты на поддержку.

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

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

• Кодекс шифрует сообщения между главным агентом и под‑агентами, делая их видимыми только серверу OpenAI
• Цель — ограничить использование и перепродажу подписок, защитить данные от черного рынка и дистилляции моделей
• Выходы под‑агентов всё равно остаются открытыми в открытом виде, а расшифровка происходит на стороне сервера
• Обсуждение вызывает вопросы о прозрачности, потенциальном «чёрном ящике» и риске привязки к экосистеме OpenAI

Репозиторий собирает практические советы и трюки для работы с Gemini CLI — командной строкой для модели ИИ Gemini от Google. Он охватывает оптимизацию промптов, автоматизацию задач, интеграцию с shell-скриптами и продвинутые техники, такие как цепочки вызовов, обработка ошибок и кастомные алиасы. Авторы подчёркивают, как ускорить разработку: например, генерация кода за секунды или анализ логов одним вызовом.

Ключевые фичи включают примеры для новичков (простые запросы) и экспертов (мультимодальные входы, fine-tuning через CLI). Репозиторий обновляется сообществом, с 50+ tips, включая хитрости вроде --stream для реального времени и JSON-вывод для парсинга. Идеально для devops и скриптеров: экономит часы рутины, повышая продуктивность на 3–5x по отзывам.

• Большинство критикует Gemini CLI за ненадёжность, медленность (10-80 сек на простые запросы), слабые инструменты и циклы ошибок.
• Предпочтение Claude Code и Codex как более эффективным агентам для кодирования; модель Gemini 3 хвалят, но CLI — нет.
• Жалобы на игнор файлов, отсутствие плана, фрагментацию CLI по моделям и быстрое устаревание советов.
• Желание LLM-агностичного агента и стандартизации; некоторые советы полезны, но "крик" на AI часто работает лучше.

Anthropic представила Claude Code в веб-интерфейсе, позволяющий выполнять кодирование прямо из браузера. Сервис находится в бета-версии как исследовательский превью и позволяет назначать несколько задач, которые выполняются на облачной инфраструктуре Anthropic. Ключевая возможность — параллельное выполнение задач в изолированных средах с отслеживанием прогресса в реальном времени. Пользователи могут подключать репозитории GitHub, описывать требования, а Claude самостоятельно реализует решения, создавая автоматические pull requests с подробными сводками изменений.

Веб-интерфейс дополняет существующую рабочую среду Claude Code, особенно эффективен для ответов на вопросы о проектах, исправления багов и рутинных задач, а также для бэкенд-изменений с использованием TDD. Каждая задача выполняется в защищенном песочном окружении с ограничениями сети и файловой системы, а взаимодействие с Git осуществляется через безопасный прокси. Сервис уже доступен для Pro и Max пользователей, а также появился в iOS-приложении в виде ранней версии.

• Обсуждение охватывает широкий спектр тем: от сравнения Claude Code и Codex, до вопросов о лицензии, инфраструктуре и будущих функциях.
• Участники обсуждают, какие инструменты лучше подходят для разных задач: Claude Code для итеративной работы и Codex для надежности при критически важных задачах.
• Также обсуждается, что пользователи хотели бы видеть более тесную интеграцию с GitHub Actions, API и другими сервисами.
• Некоторые комментаторы выражают обеспокоенность по поводу ограничений доступа к сети и отсутствия поддержки Docker.
• В то же время, другие участники подчеркивают, что Anthropic и OpenAI продолжают развивать свои инструменты, и что выбор между ними часто сводится к личным предпочтениям и конкретным сценариям использования.

Команда Alex переходит в OpenAI

Мы присоединяемся к команде Codex в OpenAI.
Начав с «безумной» идеи создать «Cursor для Xcode», мы построили лучшего AI-агента для iOS и macOS. Теперь продолжим эту миссию в OpenAI.

Что будет с Alex

• Приложение останется работать у текущих пользователей.
• С 1 октября скачивание прекращается.
• Новых функций не будет.

Спасибо бета-тестерам, клиентам, инвесторам и всему Apple-сообществу! ❤️

P.S. Попробуйте Codex CLI.

• Команда Alex Code присоединилась к OpenAI: продукт перестанет развиваться, новые загрузки прекратятся 1 октября.
• Пользователи считают, что Apple «зашерлокила» большую часть функций Alex во встроенном AI Xcode, поэтому выживание стартапа стало невозможным.
• Многие видят в сделке типичный aqui-hire: OpenAI получает инженеров, знакомых с IDE и Apple-платформами, а не уникальную технологию.
• Вопрос будущего: станут ли OpenAI/Anthropic прямыми конкурентами IDE-стартапов вроде Cursor или останутся поставщиками моделей.
• Скептики ждут, что через 12–18 месяцев продукт Alex окончательно закроют, а команду полностью интегрируют в Codex.