За последнюю неделю сразу несколько критических уязвимостей в программном обеспечении затронули тысячи крупных сайтов и вызвали панику. Главная из них — «PHP2Shell» (CVE-2026-109618 и CVE-2026-109619), две ошибки удалённого выполнения кода в PHP. Их независимо нашли команды из калифорнийской Calif (в рамках программы OpenAI «Patch the Planet») и израильско-американской Wiz (часть Google Cloud), причём обе использовали передовые ИИ-модели — GPT-5.6 Sol и Gemini 4 Argon — для поиска уязвимостей и создания эксплойтов. Одна из ошибок ещё в 2024 году всплыла при аудите PHP Foundation, финансируемом Sovereign Tech Agency, но её проигнорировали: никто не понимал, как превратить теоретическую проблему в реальный эксплойт.

Именно в этом ИИ особенно силён: получив даже смутное описание уязвимости, модель быстро строит рабочий эксплойт. Теперь любой анонс патча безопасности фактически означает, что полный эксплойт уже может распространяться — публично или приватно. PHP2Shell, по оценкам, затрагивает до 70% интернета: от Wikimedia Foundation и DeviantArt до значительной части госсайтов Великобритании, банковских систем Японии и сайта шоу The Traitors на BBC. Уязвимости находят и раньше, но обычно они не заставляют половину интернета останавливать серверы.

Обсуждение подтверждает, что LLM ускоряют поиск уязвимостей и создание эксплойтов, сокращая время между обнаружением багов и их эксплуатацией. Мнения о будущем разделились: часть участников (например, @thomascgalvin) считает это «новым кибернормалом», другие (@ozim) видят в этом переходный период, который завершится снижением числа уязвимостей за счет AI-проверки кода. Также возник спор о качестве кода: @wasabinator полагает, что LLM-генерация снизит безопасность, а @ChrisMarshallNY отмечает, что нейросети уже помогают находить баги в «идеальном» коде. Для защиты рекомендуют упрощать архитектуру, минимизировать поверхность атаки, ускорять выпуск патчей и внедрять автоматические инструменты (Dependabot, LLM-сканеры). Отдельно критикуются задержки в раскрытии уязвимостей (@shevy-java) — предлагается публиковать детали сразу. При этом проблемой остается медленное обновление ПО пользователями.

OpenAI и Google Cloud заключили партнёрство: передовые модели OpenAI и агентные сценарии Codex появятся в Model Garden — каталоге моделей Google Cloud. Клиенты получат нативный доступ к этим моделям для сложных агентных задач, опираясь на управление данными и высокопроизводительную инфраструктуру Google Cloud. Покупка будет идти через Google Cloud Marketplace, а компании с обязательствами по расходам на GCP смогут зачесть эти траты в счёт своих обязательств. Общедоступность запланирована на ближайшие недели.

Интеграция особенно важна для регулируемых отраслей: модели OpenAI соединят со встроенными средствами контроля доступа и централизованным управлением данными Google Cloud. Вскоре модели появятся и в Google Antigravity, и в Gemini Agent — это даст заказчикам гибкость выбора модели под конкретную задачу. Президент и сооснователь OpenAI Грег Брокман назвал шаг важным для развития агентной экосистемы, а глава Google Cloud Томас Куриан подчеркнул ставку на широкий выбор моделей ради качества и снижения затрат. При этом Microsoft остаётся основным облачным партнёром OpenAI.

Доступ к моделям OpenAI через Google Cloud (GCP) базируется на юридических гарантиях и контрактах по конфиденциальности, а не на технических мерах. Технически чтение моделей затруднено, так как зашифрованные веса расшифровываются только внутри чипов Nvidia. OpenAI использует GCP для обслуживания корпоративных клиентов, требующих гарантий сохранения данных и уже работающих в экосистемах AWS или GCP, дополняя основного партнера Azure. Доходы от продажи моделей через Marketplace Google Cloud признаются по факту потребления. Внутри Google ведутся споры: одни считают, что Gemini страдает от бюрократии и нехватки средств, другие — что хостинг сторонних моделей приносит значительный доход для поддержки Gemini. Упоминание Microsoft как «первичного облачного партнера» OpenAI является формальностью, продиктованной контрактом. Компаниям, планирующим миграцию инференса в GCP, рекомендуется уточнить условия доступа к логам сессий для соблюдения требований к конфиденциальности.

Сбой питания в зоне GCP europe-west2-b вызвал перебои в работе банков Великобритании. Это спровоцировало критику зависимости компаний от облачных провайдеров и отсутствия реальной отказоустойчивости. В ходе обсуждения возникли следующие тезисы: — @nickcw удивлен отсутствием multi-AZ архитектуры, однако @Betelbuddy отмечает, что зоны Google могут фактически находиться в одном дата-центре. — Наличие нескольких зон не гарантирует доступность, так как компании редко тестируют симуляцию отказов и анализ вторичных эффектов (@robinson-wall). — Скрытые межзональные или межрегиональные зависимости могут превратить локальную проблему в глобальный сбой (@bsuvc). — Неравномерное распределение оборудования в GCP заставляет разработчиков выбирать между доступностью в нескольких зонах и требованиями к железу (@td521534f12). — Юридические ограничения по локализации данных вынуждают концентрировать инфраструктуру в ограниченном числе зон, что повышает риски. Переход в облако, обещавший надежность, создал структурные уязвимости, при которых один сбой парализует множество финансовых институтов. Также @physhster и @nickcw раскритиковали Google за использование тихоокеанского времени (PDT) в статусах европейских инцидентов.

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

Авторы предлагают сделать такие лимиты стандартными, а отказ от них — осознанным выбором через явную галочку вроде «Снять лимит бюджета. Я принимаю ответственность за дополнительные расходы». Это уже реализовано в AWS через новую функцию паузы проекта при достижении лимита (анонсировано в сентябре 2026) и в Google Cloud под названием Spend Caps с июля. Такая тенденция обнадеживает, и авторы видят в этом возможность для агентов-помощников активно рекомендовать безопасные сервисы и предупреждать новичков о рисках неограниченного использования платных API.

Жёсткие бюджетные лимиты предотвращают неожиданные счета, но вызывают проблемы поддержки, потерю доходов и юридические риски. Провайдеры их ограничивают, предпочитая прощать перерасходы ради прибыли. Внедрение таких лимитов приводит к всплеску тикетов и угрозам судебных исков при отключении сервиса в критический момент. Некоторые провайдеры внедрили их только для отдельных сервисов и на месячный период — это делает их практически бесполезными. Автоматическое включение жёстких лимитов по умолчанию может навредить бизнесу: отключение из‐за превышения бюджета обходится дороже, чем неожиданный счёт. Для надёжного контроля расходов рекомендуются: - предоплата и топ‐апы (отключение при исчерпании баланса); - сетевые ACL, активируемые при превышении лимита (блокируют трафик без полного отключения); - программные «выключатели» для AI‐агентов (ограничение ежедневных трат на модели); - гибкие подписки с отключением только при критическом превышении (сохранение работы остальных компонентов). Жёсткие лимиты присутствуют в традиционных контрактах, но часто скрыты за подпиской или условиями. Сообщества разработчиков AI требуют ограничений расходов из‐за рисков взлома ключей, приводящих к сотням долларов убытков за час.

Claude Sonnet 5.5 — второй модель в семействе Claude 5.5 — значительно ускорил работу и снизил стоимость по сравнению с Sonnet 5: на 30% быстрее и до 30% дешевле за задачу. Он превзошёл предшественника в агентном программировании: на Terminal-Bench 4.0 его результат — 70,6% против 10,3%, и впервые среди Sonnet смог пройти игру Pokémon Red, анализируя только скриншоты. При этом он остаётся оптимальным для повседневных задач — исправления багов, создания документов и презентаций — и демонстрирует улучшенное понимание дизайна.

Модель сохранила цену Sonnet 5: $2 за миллион входных токенов и $10 за выходные, но за счёт эффективности тратит их меньше. Она также впервые получила кибербезопасные механизмы, ранее доступные только Opus, и защиту от дистилляции — попыток извлечь её возможности через фейковые аккаунты. В биологических запросах применяются те же ограничения, что и у Sonnet 5, но организации могут запросить доступ к расширенным разрешениям через специальную программу. Sonnet 5.5 уже доступен на AWS, Google Cloud и Azure, с нулевым хранением данных и новым режимом between_tools для корректной миграции.

Sonnet 5.5 не дает значимых преимуществ по стоимости и эффективности перед Opus 5.5. На уровнях усилий выше medium он стоит столько же или дороже, но уступает в точности, что делает его нецелесообразным для большинства пользователей. Высокий результат Sonnet 5.5 в Terminal-Bench (70.6%) обусловлен меньшим количеством отказов из-за политик безопасности (1.5% против 10% у Opus 5.5), а не реальной мощностью. Для большинства задач рекомендуется Opus 5.5 на уровне high — он точнее и дешевле, чем Sonnet 5.5 на xhigh или max. На уровне max Sonnet 5.5 непригоден для глубокого анализа, так как за 15 минут исчерпывает 128 000 токенов мышления без возврата результата. В сложных задачах на эзотерических языках Sonnet 5.5 работает хуже Sonnet 5, чаще запрашивая уточнения. Sonnet 5.5 оправдан лишь в узких сценариях: — как быстрый и дешевый подагент для простых, четко определенных задач при низком и среднем уровнях усилий; — в веб-разработке и фронтенде, где важен результат, а не процесс; — как единственный доступный вариант при ограничениях безопасности Opus 5.5 (хотя в Claude Code для баг-баунти он также блокируется). Скорость Sonnet 5.5 полезна только при массовом параллельном использовании, но не компенсирует низкую ценовую эффективность. В качестве бюджетной альтернативы предпочтительнее китайские модели (GLM, DeepSeek), которые сопоставимы по качеству, но значительно дешевле. Пользователи, использующие Haiku для тестов и Opus для планирования, или перешедшие с Sonnet 5, не видят смысла в Sonnet 5.5, так как он не улучшает соотношение цены и качества. Сравнение стоимости Sonnet 5.5 на max с Fable 5.1 ставит под сомнение логику ценообразования Anthropic.

Claude Opus 5.5 — это первая модель новой семьи Claude 5.5, которая по производительности сравнима с Claude Fable 5.1, но стоит на 40% дешевле в эксплуатации по сравнению с Opus 5. Она прошла внешнюю оценку, включая тесты от Frontier Design и METR, и показала лучшие результаты на комплексном поведенческом аудите — самом строгом тесте на соответствие и безопасность, который проводит Anthropic. Opus 5.5 значительно реже совершает необратимые действия, выходит за заданные границы или поддаётся инъекциям промптов, а также устойчивее к атакам типа дистилляции благодаря механизму «сохранённого мышления», введённому ранее в Fable 5.1.

На практике Opus 5.5 демонстрирует существенный прирост возможностей: один тестировщик перенёс 680 000 строк кода за день вместо недель работы команды, а другая группа получила более качественную игру при генерации от одного промпта. Модель успешно оптимизировала время загрузки веб-приложения в 39 из 40 случаев, не меняя её поведения, в отличие от Opus 5. Она также генерирует ответы на 30% быстрее, а стоимость токенов снижена: вход — $4, выход — $20 за миллион (на 20% дешевле), а кэш-чтения — $0.20 за миллион (на 60% дешевле). Opus 5.5 доступна на AWS, Google Cloud, Azure и через Claude Platform под именем claude-opus-5-5, с нулевым хранением данных и водяными знаками для соответствия EU AI Act. Доступ к её использованию в биологии и кибербезопасности предоставляется через верификационные программы после проверки организаций. Claude Sonnet 5.5 и Haiku 5.5 последуют позже.

Claude Opus 5.5 снижает стоимость эксплуатации на 40% и улучшает коммуникацию: пишет яснее, ставит ключевую информацию в начало, стал «лучшим рабочим партнёром» (по @mcintyre1994, @aytigra). Снижает стоимость cache reads на 60% (с $0.50 до $0.20 за 1M токенов) — критично для агентных и кодовых нагрузок (по @joshstrange, @GodelNumbering). Работает в 2–3 раза быстрее, чем Opus 5 (по @apeci, @aytigra). Снижение цен сопровождается улучшением лимитов для подписчиков (по @2001zhaozhao, @somewhatjustin). Однако вызывает серьёзные опасения: агрессивные системы безопасности, сопоставимые с Fable 5.1, блокируют легитимные задачи в кибербезопасности и системном программировании (по @kibae, @slowin). Есть риск отслеживания и передачи конфиденциальных исследований ИИ Anthropic из-за Fable-уровневых safeguard'ов (по @puttycat, @shibel). Некоторые пользователи считают DeepSeek v4.1 более эффективным и дешёвым для сложных агентных задач (генерация сайтов, визуальная проверка) (по @wg0). Есть обвинения в намеренном цикле «хайп-деградация-хайп»: Opus 5.5 будет деградировать через 2–3 недели перед запуском Fable 6 (по @gtirloni). Проблема с перегруженными, искусственными ответами остаётся нерешённой (по @shibel). После ухудшения UX и агрессивной модерации некоторые отменяют подписку и переходят на локальные модели (по @davedx). Сравнительные тесты показывают, что Opus 5.5 сопоставим с Fable 5.1 и Astra 6 в виб-кодинге (Minecraft-, Warcraft-клоны) (по @senko). Рекомендуется тестировать на генерации анимаций из текста (по @consumer451) и преобразовании дизайна в HTML (по @jjcm), хотя в последнем уступает Astra в производительности и анимациях. Haiku 5.5 ожидается как важный шаг для пользователей быстрых моделей (по @m4tthumphrey, @sznio). Постоянные обновления вызывают перегрузку: пользователи выбирают модели по настроению, а не качеству (по @magicalhippo).

Claude Opus 5.5 — новая модель от Anthropic, превосходящая Opus 5 по производительности на сложных задачах и дешевле на 40% в эксплуатации. Она показала рекордные результаты в автоматизированных тестах на безопасность, включая устойчивость к инъекциям и предотвращение опасных действий. Одни из тестов: за день она выполнила миграцию 680 000 строк кода, что команде заняло бы недели, и успешно улучшила время загрузки веб-приложения в 39 из 40 случаев, не нарушая поведение системы. В игре, созданной по одному запросу, она превзошла все другие модели по качеству графики и полировке.

Модель стала первой, в которой внедрён механизм «сохранённого мышления» против дистилляции — атак, при которых злоумышленники копируют возможности модели через фальшивые аккаунты. Opus 5.5 также улучшил коммуникацию: текст стал яснее, логичнее и ближе к человеческому стилю, что упрощает проверку и снижает риски. Цены на токены снизились на 20%, а чтение кэша — на 60%. Доступ ограничен для биологических и кибербезопасностных задач, требующих верификации. Модель доступна на AWS, Google Cloud и Azure, с нулевым хранением данных и водяными знаками для соответствия EU AI Act.

Opus 5.5 стал дешевле на 40 %: $4 за 1 млн токенов ввода, $20 за вывод, $0.20 за чтение кеша. Улучшены скорость (на 30 %) и стиль общения — сообщения короче, понятнее, лучше воспринимаются в длительных сессиях. Упомянуты специализированные программы верификации для Life Sciences и Cyber. Доступен механизм «Reset for free» до 22 октября для временного расширения лимитов. Однако вызывает скепсис реальное преимущество над Fable 5.1 и другими моделями: разрыв в практических задачах меньше, чем в бенчмарках, а Fable воспринимается как более продаваемый бренд. Некоторые пользователи предпочитают Astra или DeepSeek для повседневных задач. Выражены опасения по частоте релизов (пропуск версий 5.1‐5.4), стабильности после недавних сбоев и необходимости тестировать Opus 5.5 на конкретных нагрузках перед миграцией, учитывая прошлую «словесную» реакцию модели.

Авторежим стал настройкой по умолчанию для пользователей Pro, Max и Team‑планов. Начиная с 14 августа новые сессии автоматически работают в этом режиме, а те, у кого был собственный выбор, получат одноразовый запрос на переключение. Если админ уже зафиксировал другой режим в управляемых настройках, ничего не меняется.

Классификатор, отвечающий за блокировку опасных действий, потребляет лишь несколько дополнительных токенов, но теперь его использование не тарифицируется для указанных тарифов. В Enterprise‑режиме авторежим пока остаётся опциональным, однако уже в ближайший месяц он станет обязательным и во всех облачных платформах (AWS, Google Cloud, Microsoft Foundry и др.).

По данным внутренних и сторонних тестов, авторежим не ухудшает безопасность: он блокирует необратимые, разрушительные или внешне‑ориентированные вызовы, а при трёх последовательных блокировках или 20‑ти блокировках за сессию переходит к ручному подтверждению. В эксперименте с 1 053 платёжными тестировщиками авторежим показал результаты, сопоставимые или лучше, чем ручной обзор.

Кроме того, авторежим позволяет моделям типа Claude Opus 5 выполнять длительные задачи без постоянных вмешательств. Пользователи Teams и Enterprise‑пользователи, включившие авторежим, генерируют на 25 % больше pull‑request’ов. Примеры внедрения: Adobe, Nuro, Gusto, Garner Health.

Что нужно знать:

• В Pro/Max/Team‑режимах авторежим включён автоматически; переключить его можно через Shift+Tab или выпадающий список в десктоп‑клиенте.
• Для Enterprise‑администраторов доступна настройка `defaultMode` в управляемых параметрах.
• При критических изменениях в продакшене рекомендуется проверять действия модели вручную.

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

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

Google TPU возник в 2013 году из расчёта: если каждый пользователь Android задействует voice search по 3 минуты в день, компании придётся удвоить мощности дата-центров. Стандартные CPU и GPU не справлялись с матричной математикой глубокого обучения, поэтому Google создал ASIC для TensorFlow. Проект прошёл от концепта до деплоя за 15 месяцев (2013–2014), к 2015 TPU уже ускоряли Maps, Photos и Translate, а в 2016 их анонсировали на I/O.

В отличие от универсальных GPU с «багажом» (кеширование, ветвления, текстуры), TPU — доменно-специфичный чип с systolic array: данные (веса) загружаются раз, проходят через сетку умножителей без возврата в память, минимизируя Von Neumann bottleneck и HBM-доступы. Новый Ironwood усилил SparseCore для эмбеддингов (рекомендации, LLM) и расширил HBM. TPU — ключевое преимущество Google Cloud на 10 лет, с фокусом на inference; обсуждаются производство, сравнения с GPU и влияние Gemini 3.

• Google's TPUs лидируют в эффективности inference и масштабе благодаря systolic array, OCS interconnects и низкой стоимости эксплуатации по сравнению с Nvidia GPUs.
• Скепсис по поводу исполнения Google: слабая экосистема (JAX/TF vs CUDA), история провалов продуктов и зависимость от ad-бизнеса.
• Nvidia доминирует за счёт универсальности, CUDA и оптимизаций (NVLink, NVFP4), несмотря на "architectural baggage".
• Упоминания альтернатив (Groq, Cerebras, Meta покупает TPU) и рисков: новые архитектуры AI могут устареть hardware, фокус на inference vs training.
• Google имеет ресурсы для доминирования через vertical stack и cloud, но короткий "attention span" вызывает сомнения.

Анализ трёх недавних проблем

С 17 сентября 2025 года

В период с августа по начало сентября три ошибки в инфраструктуре периодически снижали качество ответов Claude. Мы устранили эти проблемы и хотим объяснить, что произошло.

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

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

Хронология событий

Наложение этих ошибок значительно усложнило диагностику. Первая ошибка появилась 5 августа, затронув около 0,8% запросов к Sonnet 4. Две другие возникли 25-26 августа.

Изменение балансировки нагрузки 29 августа увеличило количество затронутых запросов, что привело к противоречивым отчетам пользователей.

Три перекрывающиеся проблемы

1. Ошибка маршрутизации контекстного окна

5 августа некоторые запросы Sonnet 4 перенаправлялись на серверы, настроенные для контекстного окна в 1 млн токенов. Изначально ошибка затрагивала 0,8% запросов, но к 31 августа эта доля выросла до 16%.

Около 30% пользователей Claude Code столкнулись с ухудшением ответов. На Amazon Bedrock пик затронутых запросов составил 0,18%, на Google Cloud Vertex AI — менее 0,0004%.

Решение: Исправлена логика маршрутизации. Фикс развернут 4 сентября, к 16 сентября распространен на основные платформы.

2. Повреждение вывода

25 августа ошибка конфигурации на серверах TPU вызвала сбой при генерации токенов. Это приводило к появлению неожиданных символов (например, тайских или китайских в ответ на английские запросы) или синтаксических ошибок в коде.

Проблема затрагивала Opus 4.1/4 (25-28 августа) и Sonnet 4 (25 августа - 2 сентября). Сторонние платформы не пострадали.

Решение: Выявлена и откатана ошибочная конфигурация.

• Критика отсутствия юнит-тестов и акцент на использовании эвалов для тестирования моделей.
• Удивление способностью Anthropic влиять на инфраструктуру AWS Bedrock, что противоречит обязательствам AWS.
• Обсуждение технических сбоев: ошибки маршрутизации запросов, коррупция вывода и баг компилятора XLA, повлиявшие на качество Claude.
• Высокое количество инцидентов, отмеченных на статусной странице Claude, и призывы к улучшению качества и надежности сервиса.
• Критика недостаточной прозрачности отчета Anthropic, включая отсутствие данных о степени деградации и компенсаций для пользователей.
• Обсуждение проблем недетерминированности в LLM и сложностей обеспечения воспроизводимости результатов.
• Спекуляции о причинах использования разных аппаратных платформ (TPU, AWS) и их влиянии на пользовательский опыт.