Авторежим стал настройкой по умолчанию для пользователей 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) и их влиянии на пользовательский опыт.