Horizon Daily - 2026-08-05¶

From 39 items, 11 important content pieces were selected

Технологии 1. Утечки IP и DNS в WebKit затрагивают прокси-браузеры и iCloud Private Relay ⭐️ 8.0/10 2. Позиционная статья «LLMs Can't Jump» о пределах научных озарений LLM ⭐️ 7.0/10 3. Крушение гражданского самолёта в Нью-Мексико связывают с военным глушением GPS ⭐️ 7.0/10 4. Mistral выпустила Shieldstral: открытую 3B-модель для мультимодальной модерации ⭐️ 7.0/10 5. Maple-Preview: тернарная 20B MoE-модель на iPhone со скоростью 120 токенов/с ⭐️ 7.0/10 6. Восемь мифов об инженерии ПО и GenAI ⭐️ 7.0/10

Блоги 1. LLM 0.32: трейсы рассуждений, серверные инструменты и новый лог ⭐️ 7.0/10 2. OpenCost 1.121.0 добавляет учёт затрат на инференс LLM в Kubernetes ⭐️ 7.0/10 3. Запуск MLX-порта MiniMax-H3 на M5 Max MacBook Pro ⭐️ 5.0/10 4. llm-anthropic 0.26: новые модели Claude и серверные инструменты ⭐️ 4.0/10

Видео 1. nativeprompt: переписывание промптов под правила Claude Code и Codex ⭐️ 7.0/10

Технологии¶

Утечки IP и DNS в WebKit затрагивают прокси-браузеры и iCloud Private Relay ⭐️ 8.0/10¶

В WebKit обнаружены утечки IP-адресов и DNS-запросов, которые могут раскрывать реальные данные пользователей прокси-браузеров и iCloud Private Relay. Отчёт указывает на то, что некоторые веб-функции способны обходить механизмы скрытия адреса и DNS, снижая эффективность инструментов приватности. Это важно для браузерных разработчиков, операторов прокси и пользователей Apple, поскольку iCloud Private Relay предназначен для маскировки трафика и защиты личности в Safari. Конкретные затронутые версии, механизмы утечки и статус исправления в доступных материалах не приведены.

hackernews · lapcat · Aug 4, 23:31 · Discussion

「Контекст」 WebKit — браузерный движок, лежащий в основе Safari и всех браузеров на iOS/iPadOS, а iCloud Private Relay — функция Apple, маскирующая IP-адрес и DNS-запросы пользователя при работе в Safari. Прокси-браузеры и аналогичные механизмы приватности зависят от того, чтобы весь сетевой трафик проходил через настроенный прокси, а не напрямую с устройства.

「Влияние」 Пользователи браузеров на WebKit с прокси и iCloud Private Relay могут раскрывать реальный IP-адрес или DNS-активность через DNS prefetching, WebAuthn Related Origin Requests и WebTransport. VPN-туннели, судя по имеющимся данным, не подвержены этим утечкам, поскольку трафик все равно проходит через VPN.

「Обсуждение」 Комментаторы обсуждают практические проявления утечек: один пользователь видит реальный IP через WebAuthn и иногда некорректный IP через WebTransport на тестовом сайте, тогда как HTTPS-трафик может показывать другой relay. Также звучит скепсис к сторонним iOS-браузерам на WebKit из-за ограничений Apple и пожелание иметь удобный способ отключать iCloud Private Relay и DNS-over-HTTPS.

「Проверка фактов」 Утверждение о том, что три функции WebKit — DNS prefetching, WebAuthn Related Origin Requests и WebTransport — обходят настроенный прокси и раскрывают реальный IP/DNS пользователя, подтверждается независимыми источниками Heise и DevDigest. Также подтверждается, что эти утечки затрагивают iCloud Private Relay и что WebTransport был добавлен в WebKit с iOS 26.4. Утверждение об исправлении всех трёх утечек в Psylo 1.3.1 остаётся непроверенным независимыми источниками.

References

Tags: #webkit, #privacy, #dns, #icloud-private-relay, #browser-security

Позиционная статья «LLMs Can't Jump» о пределах научных озарений LLM ⭐️ 7.0/10¶

Позиционная статья «LLMs Can't Jump», опубликованная на OpenReview, утверждает, что большие языковые модели не способны выполнять определённые разрывные научные скачки, аналогичные смене парадигм или интуитивным прорывам в истории науки. Работа вызвала обсуждение того, следует ли считать текущие LLM инструментами для постепенной оптимизации знаний или они могут участвовать в подлинном научном открытии. В комментариях упоминается уточнение автора Тома Захави: статья не утверждает, что LLM никогда не смогут делать реальные научные открытия, и её не следует сводить к позиции «DeepMind против ИИ для науки». Часть дискуссии сосредоточена на исторических примерах, таких как специальная теория относительности и работы Лоренца, а также на том, насколько корректно использовать такие аналогии для оценки возможностей моделей.

hackernews · theanonymousone · Aug 5, 11:01 · Discussion

「Контекст」 «LLMs Can't Jump» — позиционная статья Тома Захава, посвящённая ограниченности больших языковых моделей в абдуктивном рассуждении, которое считается важным для подлинных научных открытий. Работа обсуждалась на OpenReview и привлекла внимание тем, что формулирует не проблему бенчмарков или галлюцинаций, а вопрос о способности LLM совершать концептуальные «скачки» при создании новых научных гипотез.

「Значение」 Для исследователей ИИ и научного сообщества статья задаёт рамку обсуждения: при оценке LLM для науки важно различать интерполяцию накопленных знаний и способность к концептуальным разрывам, которые могут требовать иных механизмов или данных.

「Обсуждение」 Комментаторы спорят об упрощённом изложении истории специальной теории относительности и о том, что статья слишком опирается на аналогию с общей теорией относительности и телесным опытом. Некоторые отмечают, что автор позже уточнил позицию против радикальных трактовок, а также предлагают альтернативные тесты, например обучение LLM на текстах до 1980–1990 годов для проверки способности «заново открыть» современные концепции.

「Проверка фактов」 Ключевые проверяемые утверждения: (1) статья «LLMs Can't Jump» является позиционной работой Тома Захава из Google DeepMind; (2) она обсуждалась в контексте ICML 2026; (3) в качестве примера научного «прыжка» используется создание Эйнштейном специальной/общей теории относительности. Независимые источники подтверждают авторство Тома Захава и связь с Google DeepMind (tool-2-2, tool-2-3), а также указание на ICML 2026 и использование формулировки Эйнштейном теории относительности как кейса (tool-2-3). Утверждение о том, что расширение вычислительной инфраструктуры не позволит LLM совершать революционные научкие открытия, передаётся как позиция автора, а не как доказанный факт (tool-2-2).

References

Tags: #AI, #LLMs, #machine-learning, #research, #scientific-discovery

Крушение гражданского самолёта в Нью-Мексико связывают с военным глушением GPS ⭐️ 7.0/10¶

По сообщению Wired, крушение гражданского самолёта в Нью-Мексико связывают с военным блокированием GPS, что вызвало обсуждение устойчивости авиационной навигации и чрезмерной зависимости от GPS. Инцидент поднимает вопрос о том, насколько надёжно гражданская авиация может переходить на резервные средства навигации при потере спутникового сигнала. Комментаторы подчёркивают, что GPS не является единственным средством навигации: существуют другие системы, включая DME/DME-триангуляцию для зональной навигации, а пилоты должны быть готовы к отказу GPS. При этом конкретные причины аварии остаются предметом обсуждения, а визуализация в статье критикуется за неточности.

hackernews · dzdt · Aug 5, 11:03 · Discussion

「Контекст」 GPS-глушение — это преднамеренная подача спутниковых навигационных сигналов, которое может лишить воздушное судно точных данных о местоположении. Военные учения с такими помехами проводятся, в частности, на полигоне White Sands в Нью-Мексико, и их сигналы могут затрагивать гражданскую авиацию поблизости. По данным сообщений об инциденте, крушение медицинского самолёта в Нью-Мексике стало первым в США случаем, когда GPS-глушение рассматривается как фактор гибели гражданского воздушного судна [tool-1-1][tool-1-2][tool-1-3].

「Последствия」 Инцидент усиливает обеспокоенность по поводу устойчивости гражданской авиации к военному подавлению GPS и может подтолкнуть операторов и пилотов к более строгому использованию резервных средств навигации. FAA уже выпускает рекомендации и NOTAM по помехам GNSS, предупреждая, что такие помехи способны затрагивать навигацию, наблюдение, автопилот и системы управления полётом [tool-3-1][tool-3-2][tool-3-3].

「Обсуждение сообщества」 Пилоты в комментариях сходятся во мнении, что потеря GPS не должна приводить к катастрофе, поскольку авиация имеет резервные навигационные системы и процедуры. Один из комментаторов, летавший во Флориде в 2005–2015 годах, отмечает, что уведомления о помехах GPS были обычным явлением, а сигнал мог внезапно искажаться или пропадать. Другой пилот авиакомпании указывает, что визуальный заход в горной местности без лунного света крайне рискован, а рейсы по Part 121 могли бы не получить разрешение на вылет при отсутствии метеосводок. Часть комментаторов считает, что пилоты могли стать излишне зависимыми от GPS и потерять строгость в традиционной навигации, а анимация в статье критикуется за вводящее в заблуждение изображение аварии.

「Проверка фактов」 Утверждение о том, что гражданский самолёт разбился в Нью-Мексико в связи с военным глушением GPS, подтверждается независимыми источниками: NTSB сообщил, что военное GPS-глушение было активно во время аварии, а экипаж потерял GPS примерно через восемь минут после взлёта, после чего диспетчер попросил военных прекратить глушение [tool-2-1]. Также подтверждается, что первоначальный отчёт NTSB зафиксировал нарушение GPS, связанное с учениями на ракетном полигоне примерно в 65 км от места аварии [tool-2-3]. Утверждение о том, что глушение стало вероятной причиной аварии, остаётся предварительным: источники указывают на связь и вероятное влияние, но не содержат окончательного вывода расследования [tool-2-2].

References

Tags: #GPS, #aviation, #military-technology, #safety, #infrastructure

Mistral выпустила Shieldstral: открытую 3B-модель для мультимодальной модерации ⭐️ 7.0/10¶

Mistral представила Shieldstral, открытую по весам модель с 3 млрд параметров, предназначенную для мультимодальной модерации контента. Модель позиционируется как специализированный инструмент для проверки изображений и текста на предмет нарушений, что позволяет использовать её в качестве базового фильтра в системах безопасности. Релиз отражает стратегию Mistral по созданию небольших узкоспециализированных моделей, дополняющих крупные универсальные архитектуры. Shieldstral доступна на Hugging Face, где пользователи уже начали проводить независимые тесты.

hackernews · riadsila · Aug 4, 16:36 · Discussion

「Контекст」 Shieldstral — это открытая 3-миллиардная мультимодальная модель Mistral AI, предназначенная для классификации контента по правилам безопасности и модерации. Mistral позиционирует её как адаптивный к политикам классификатор, который работает в формате вопросно-ответной проверки текста и изображений, а не как модель с жёстко зашитой таксономией нарушений. Релиз вписывается в стратегию Mistral выпускать небольшие специализированные модели под конкретные задачи, а не только крупные универсальные модели.

「Влияние」 Появление Shieldstral даёт разработчикам и платформам открытый инструмент для настройки правил модерации без зависимости от закрытых API крупных компаний.

「Обсуждение」 Сообщество обсуждает гибкость модели: сможет ли она работать с произвольными наборами правил или останется в рамках стандартных фильтров «больших техов». Один из пользователей протестировал модель на «Трактате о веротерпимости» Вольтера и получил ложное срабатывание о пропаганде насилия, что указывает на возможные проблемы с пониманием контекста. Также отмечается, что стратегия Mistral смещается в сторону небольших дообученных моделей после того, как крупные MoE-модели не смогли конкурировать с флагманскими решениями.

「Проверка фактов」 Утверждение о том, что Shieldstral является 3B-моделью с открытыми весами для мультимодальной модерации, подтверждается: карточка модели на Hugging Face описывает её как компактный 3B-параметрический мультимодальный классификатор безопасности, а анонс Mistral указывает на работу с текстом и изображениями и выдачу калиброванной оценки по политике модерации на естественном языке [tool-2-1, tool-2-3]. Утверждение сообщества о возможности задавать произвольные правила также согласуется с описанием policy-adaptive подхода на Hugging Face и примером использования из обучающего материала, где политика передаётся как текстовый вопрос [tool-2-1, tool-2-2]. Ссылка на arXiv в анонсе не проверялась отдельно, поэтому её следует считать неподтверждённой в рамках доступных источников.

References

Tags: #ai-safety, #content-moderation, #open-weights, #mistral, #multimodal

Maple-Preview: тернарная 20B MoE-модель на iPhone со скоростью 120 токенов/с ⭐️ 7.0/10¶

Проект Maple-Preview демонстрирует тернарную 20-миллиардную mixture-of-experts модель, работающую со скоростью около 120 токенов в секунду на iPhone. Это показывает, что агрессивная квантизация и MoE-архитектура могут обеспечить быстрый локальный инференс на мобильных устройствах. На странице также упоминается идея «dreaming» для адаптации модели на устройстве, но в опубликованном коде участники обсуждения не нашли признаков её реализации. Проект следует рассматривать как предварительный технический эксперимент, а не законченный продукт.

hackernews · edwardbzhang · Aug 4, 19:44 · Discussion

「Контекст」 Maple-Preview — это предварительный выпуск локальной модели с открытым исходным кодом, использующей троичные веса и архитектуру mixture-of-experts с 20 млрд параметров, из которых активна меньшая часть. Такие модели предназначены для быстрого локального вывода на устройствах с ограниченными ресурсами, например смартфонах, где важны низкое энергопотребление и малая задержка. Проект также упоминается в связке с концепцией «агентской ОС» и адаптацией на устройстве, однако эти возможности выглядят предварительными и не подтверждены полной реализацией.

「Практическое значение」 Для разработчиков edge-приложений это может означать возможность быстрых локальных LLM для маршрутизации инструментов и небольших задач, но при условии решения проблем точности малых моделей.

「Обсуждение сообщества」 Участники Hacker News сочли интересной идею локальной адаптации через «dreaming», но отметили отсутствие видимой реализации в коде. Также прозвучали опасения по поводу уверенных, но неверных ответов малых моделей и важности качественного tool calling; один комментарий указал на странность сравнения с устаревшей версией Qwen.

「Проверка фактов」 Упоминание Qwen 3.5 35B-A3B как модели сравнения подтверждается: такая версия существует и обсуждается, включая вопросы с шаблоном вызова инструментов. Упоминание Qwen 3.6 35B-A3B как уже доступной и более новой также частично подтверждается материалами о линейке Qwen 3.5/3.6. Однако утверждение о Maple-Preview как тернарной 20B MoE, работающей со скоростью 120 ток/с на iPhone, не проверяется по предоставленным независимым источникам и остаётся неподтверждённым.

References

Tags: #machine-learning, #on-device-inference, #llm, #edge-computing, #model-optimization

Восемь мифов об инженерии ПО и GenAI ⭐️ 7.0/10¶

Статья на ACM Queue разбирает восемь распространённых мифов о влиянии генеративного ИИ на разработку ПО. Ключевой тезис состоит в том, что написание кода занимает лишь малую долю рабочего времени разработчика: приводится исследование Microsoft 2025 года с участием более 450 инженеров, согласно которому на кодирование приходится около 14% времени. Из этого следует, что даже полное устранение времени на написание кода сократило бы общий цикл разработки лишь на эту долю, если ИИ не помогает в других задачах. Материал призывает оценивать GenAI не как замену программирования, а как инструмент, меняющий распределение усилий между исследованием, планированием, проверкой и сопровождением.

hackernews · tchalla · Aug 4, 23:50 · Discussion

「Контекст」 Статья «Eight Myths on Software Engineering and GenAI» опубликована в ACM Queue на фоне быстрого внедрения генеративного ИИ в разработку ПО, когда маркетинговые заявления и отдельные успешные кейсы часто опережают эмпирические исследования и организационную практику. Она опирается на недавние масштабные исследования, интервью и полевые наблюдения, чтобы разобрать устойчивые мифы, влияющие на решения об использовании ИИ в инженерных командах.

「Влияние」 Для инженерных команд и разработчиков главный вывод состоит в том, что автоматизация только написания кода не может радикально сократить общий цикл разработки, поскольку кодирование занимает лишь около 14% рабочего времени. Это означает, что реальная польза GenAI будет зависеть не от ускорения набора кода, а от того, насколько инструменты помогают в исследовании, проектировании, ревью, тестировании и сопровождении. При этом организациям важно измерять влияние ИИ на продуктивность до его глубокого внедрения в рабочие процессы, отслеживая не только скорость, но и качество, цикл поставки и сохранение фокусного времени разработчиков.

「Обсуждение」 Комментаторы в целом согласились, что 14% времени на код выглядит правдоподобно как среднее значение, но отметили, что агенты и Copilot могут изменить саму структуру работы, увеличив долю управления генерацией кода. Часть участников раскритиковала аргумент о том, что будущие агентные LLM сделают текущую работу бессмысленной, а также указала на потерю мотивации и «дофаминового» эффекта при массовой генерации кода.

「Проверка фактов」 Утверждение о том, что исследование Microsoft 2025 года показало: разработчики тратят лишь 14% времени на написание кода, частично подтверждается независимыми источниками: InfoWorld со ссылкой на отчет IDC за февраль 2025 года и Medium за июнь 2025 года также сообщают, что разработчики тратят на кодирование малую долю времени (около 11%), хотя точная цифра 14% и привязка именно к исследованию Microsoft в этих источниках не воспроизводятся. Более ранняя статья The New Stack от октября 2021 года указывает, что разработчики тратят на написание нового или улучшение существующего кода до 39% времени, что противоречит обобщению о стабильно низкой доле кодирования без учета контекста задачи и методологии. Таким образом, общий тезис о том, что кодирование занимает небольшую часть работы разработчика, подтверждается, но конкретная цифра 14% и атрибуция исследованию Microsoft остаются непроверенными по представленным источникам.

References

Tags: #software-engineering, #generative-ai, #developer-productivity, #ai-agents, #industry-analysis

Блоги¶

LLM 0.32: трейсы рассуждений, серверные инструменты и новый лог ⭐️ 7.0/10¶

rss · Simon Willison · Aug 4, 23:58

「Контекст」 Simon Willison выпустил LLM 0.32 — крупнейшее обновление его CLI-инструмента и Python-библиотеки для работы с LLM. Прежние абстракции, по словам автора, перестали соответствовать современным моделям: ответы теперь могут включать рассуждения, вызовы инструментов и вложения, а клиентская библиотека должна лучше подходить для агентных сценариев.

「Суть」 Willison описывает релиз как набор взаимосвязанных изменений, которые делают LLM более «агентоподобным». В CLI рассуждения моделей выводятся в stderr и не попадают в основной поток, который можно передавать другим инструментам; отключить это можно флагом -R/--hide-reasoning. Добавлена поддержка семейства GPT-5.6, включая новый дефолтный GPT-5.6 Luna, а также серверные инструменты провайдеров: OpenAI CodeInterpreter и WebSearch, а в обновлённом плагине llm-anthropic — WebSearch, WebFetch, CodeExecution и AnthropicMCP, позволяющий выполнять MCP-вызовы в рамках одного запроса к API. Новая команда llm openai endpoint позволяет выполнять одноразовые промпты против любого OpenAI-совместимого эндпоинта без записи в лог; автор показывает пример с локальной Gemma 4 12B через LM Studio и плагином llm-tools-quickjs. В Python API вместо обязательной абстракции «разговор — сообщения по одному» появился model.prompt(messages=[]), принимающий полную историю сразу, а вместо простого потока строк — stream_events() с типами событий, включая reasoning, text и другие. Эти изменения позволили автору выпустить плагин llm-chat-completions-server, реализующий полустандартный OpenAI chat completions API поверх LLM. Отдельно Willison объясняет переработку логирования: чтобы не дублировать JSON-историю на каждом шаге диалога, используется content-addressable хранилище сообщений по образцу Git, при этом команды llm logs и llm logs --json преобразуют его обратно в удобный вид. Он также отмечает, что существующие плагины должны работать, но плагинам с дополнительными моделями потребуется обновление для полноценной поддержки новой системы потоковых событий, а часть изменений была продиктована потребностями Datasette Agent, включая паузу цепочек инструментов для одобрения человеком и возобновление из сохранённой истории.

「Вывод」 Автор приходит к выводу, что LLM постепенно превращается из CLI-утилиты для промптов в агентный фреймворк: он уже умеет смешивать модели, инструменты и логирование в одной команде и библиотеке. При этом он подчёркивает, что пока не решил, должна ли сама концепция «агента» войти в ядро библиотеки.

Tags: #LLM tooling, #CLI, #Python API, #agent frameworks, #release notes

OpenCost 1.121.0 добавляет учёт затрат на инференс LLM в Kubernetes ⭐️ 7.0/10¶

rss · CNCF Blog · Aug 5, 11:00

「Контекст」 Команды, эксплуатирующие LLM в Kubernetes, видят расходы на GPU и пропускную способность по токенам, но не могут связать их, чтобы понять стоимость каждого токена и каждой модели. Это мешает корректным решениям build-vs-buy, потому что затраты на активный инференс и на простоей с загруженной моделью — разные вещи.

「Суть」 Авторы интегрируют OpenCost с llm-d и метриками vLLM, чтобы считать две разные стоимости: allocation-based — полные затраты на доступность модели, включая зарезервированную GPU-память, инфраструктуру и общее окружение llm-d, и usage-based — затраты только активной обработки токенов с учётом попаданий в KV-кэш. Отдельно учитываются входные и выходные токены, так как они соответствуют фазам prefill и decode и могут выполняться на разном железе. Новые метрики Prometheus и REST API, такие как llm_total_hourly_cost и llm_cost_per_million_tokens, помечаются моделью, версией, namespace и типом стоимости. Отношение usage-based к allocation-based даёт оценку утилизации GPU; в примере 25% утилизации превращают видимую стоимость $1 за миллион токенов в реальную $4, что делает SaaS API за $2 дешевле self-hosting. Функция доступна в OpenCost 1.121.0 и проверена в proof-of-concept на 109 GPU и 30 моделях, хотя авторы не приводят глубокой количественной оценки результатов.

「Вывод」 Разделение затрат на доступность модели и активный инференс превращает GPU-счета в осмысленные экономические сигналы для выбора между self-hosting и API. Это позволяет оценивать утилизацию, оптимизировать маршрутизацию и принимать решения на основе реальной стоимости токенов, а не только цены за активный compute.

Tags: #Kubernetes, #AI inference, #GPU cost allocation, #FinOps, #OpenCost

Запуск MLX-порта MiniMax-H3 на M5 Max MacBook Pro ⭐️ 5.0/10¶

rss · Simon Willison · Aug 4, 19:10

「Контекст」 MiniMax-H3 — «универсальная омнимодальная генеративная система», принимающая текст, изображения, аудио и видео для создания клипов до 15 секунд со звуком. Саймон Уиллисон решил проверить её MLX-порт PipeNetwork на MacBook Pro с M5 Max.

「Суть」 Уиллисон описывает конкретный способ запуска: сначала через `huggingface_hub` скачиваются файлы MiniMaxAI/MiniMax-H3 (включая `FL2VA/*`, но без `FL2VA/transformer/*`) и 8-битный порт `pipenetwork/MiniMax-H3-MLX-8bit`, затем генерация выполняется скриптом `scripts/generate.py` с `mlx-vlm` и `requirements.txt`, с явным указанием локальных снапшотов моделей в кэше Hugging Face. В его тесте было загружено около 115 ГБ модельных файлов, а генерация видео по промпту про радужного скунца заняла чуть меньше 45 минут. Автор называет полученное видео впечатляющим, но отмечает, что звук оказался странным «речеподобным мусором», потому что он не задал подсказку для аудио и не прочитал руководство по промптингу, где описаны соответствующие приёмы.

「Вывод」 MLX-порт MiniMax-H3 действительно запускается на Apple Silicon и способен генерировать впечатляющее видео, но требует огромной загрузки моделей, долгой генерации и более осмысленного промптинга, особенно для аудио.

Tags: #MLX, #Apple Silicon, #video generation, #multimodal models, #MiniMax-H3

llm-anthropic 0.26: новые модели Claude и серверные инструменты ⭐️ 4.0/10¶

rss · Simon Willison · Aug 4, 22:00

「Контекст」 Саймон Уиллисон анонсировал выпуск плагина llm-anthropic 0.26 для CLI-инструмента LLM, приуроченный к появлению функций в LLM 0.32. Обновление ориентировано на пользователей, работающих с моделями Anthropic через командную строку или Python.

「Суть」 Плагин добавляет поддержку новых моделей — claude-fable-5, claude-sonnet-5 и claude-opus-5 — и требует llm>=0.32. Серверные инструменты WebSearch, WebFetch, CodeExecution и AnthropicMCP теперь доступны через флаг -T или параметр tools= в Python, а прежние опции вида -o web_search* удалены в пользу -T WebSearch. Потоковая передача рассуждений, вызовов инструментов и результатов инструментов теперь идёт как типизированные события; в CLI рассуждения выводятся в stderr, если не указан флаг --hide-reasoning/-R, который также исключает их из ответов и логов. Расширенное «мышление» упрощено до параметров thinking и thinking_effort со значениями low, medium, high, xhigh или max; модели Claude 5 думают по умолчанию, для Sonnet 5 и Opus 5 это отключается через -o thinking 0, а Fable 5, по описанию автора, думает всегда. Старые настройки thinking_budget, thinking_display и thinking_adaptive удалены.

「Вывод」 Автор представляет выпуск как обновление, синхронизирующее llm-anthropic с возможностями LLM 0.32: новые модели Claude 5, серверные инструменты и более простой интерфейс для рассуждений. Это преимущественно changelog для существующих пользователей плагина, без обсуждения компромиссов или практических последствий.

Tags: #LLM tooling, #Anthropic, #release notes, #CLI plugins, #developer tools

Видео¶

nativeprompt: переписывание промптов под правила Claude Code и Codex ⭐️ 7.0/10¶

Видео утверждает, что универсальные советы по промптингу, например «думай пошагово», могут ухудшать работу части современных моделей, потому что у Claude и Codex разные официальные рекомендации. Автор показывает открытый инструмент nativeprompt, который определяет используемую модель в Claude Code или Codex, переписывает промпт под правила конкретного вендора и объясняет каждую правку ссылкой на документацию. В демо один неудачный промпт исправляется двумя разными способами для Claude Opus 5 и GPT-5.6, а также обсуждаются режимы запуска: /goal, /loop, plan mode и особенности Codex. Отдельно разбираются проблемы работы в VS Code, включая суффикс [1m], означающий окно контекста на 1 миллион токенов. Автор подчёркивает ограничение: инструмент улучшает формулировку, но не создаёт задачу за пользователя.

video · Эдвард Гришин · Aug 4, 16:32

「Контекст」 Современные модели для написания кода, такие как Claude Code и Codex, могут по-разному реагировать на одни и те же формулировки промптов, включая советы вроде «думай пошагово». Разработчики часто ориентируются на универсальные рекомендации, но официальные руководства Anthropic и OpenAI по стилю промптинга местами расходятся. Инструмент nativeprompt, найденный в GitHub, позиционируется как open-source средство, которое переписывает промпт под «родной диалект» конкретной модели и показывает, какое официальное правило повлияло на каждую правку.

「Практический эффект」 Разработчикам, использующим Claude Code и Codex, предлагается автоматизированный способ адаптировать промпты к официальным правилам каждой модели, что может снизить число ошибок из-за неподходящих универсальных инструкций.

「Проверка утверждений」 Утверждение о том, что фраза «думай пошагово» ухудшает работу половины топовых моделей, остаётся неподтверждённым: в источнике не приведён список моделей и методика проверки. Заявления о разных официальных правилах Claude и Codex правдоподобны, но без независимых источников их нельзя полностью подтвердить. Существование открытого инструмента nativeprompt и его функции также не проверены внешними источниками.

「Технические детали」 Инструмент nativeprompt определяет модель, с которой работает пользователь, и переписывает промпт согласно официальным правилам вендора. Для Claude рекомендуются XML-теги, роли и пошаговое мышление, тогда как модели рассуждения OpenAI, по словам автора, плохо реагируют на навязанные шаги, противоречия и повторы. В видео показывается живая демонстрация: один плохой промпт корректируется по-разному для Claude Opus 5 и GPT-5.6. Для VS Code упоминаются три ловушки определения модели, включая суффикс [1m], который указывает на окно контекста в 1 миллион токенов. Инструмент имеет два режима: по запросу и автоматически для каждого промпта. Также заявлено еженедельное отслеживание 14 официальных страниц документации с автоматическим созданием pull request в формате «до → после».

References

Tags: #AI prompting, #LLM tooling, #Claude Code, #Codex, #developer workflow