Anthropic подтвердила новые ограничения в Claude Code, нацеленные против клонирования игр. Об этом сообщает Tom's Hardware, и официальная формулировка касается именно этой категории задач. Пользователи при этом сообщают, что Claude Opus 5.5 блокирует и задачи обратной разработки, и обсуждают это как ещё один аргумент за self-hosting.
Для практики принципиально разделение: первое — подтверждённое заявление компании, второе — наблюдения пользователей, которые Anthropic не подтверждала. Публичного перечня запрещённых тем и триггеров фильтра нет ни в одном из доступных источников, поэтому предсказать поведение ограничений можно только эмпирически, на своих задачах.
Ниже: что именно известно на сегодня, почему под фильтр попадают законные задачи вроде аудита собственной прошивки, какие сценарии закрывает локальная модель, сколько для неё нужно VRAM и где self-hosting проигрывает Opus 5.5.
Что Anthropic изменила в Claude Code и что известно про Opus 5.5
Смысл изменений понятен из рыночного контекста. Существует инструмент, который заранее переводит машинный код игр в обычный C или C++, собирает результат под PC и прямо позиционируется как конкурент решения Claude Code в этой нише (описание инструмента декомпиляции). Claude Code в такой схеме оказывается одним из способов добраться до чужого бинарника, и Anthropic закрывает этот сценарий на своей стороне.
Подтверждённые ограничения и сообщения пользователей: где граница
| Утверждение | Статус | Что это значит для планирования |
|---|---|---|
| Новые лимиты Claude Code против клонирования игр | Подтверждено Anthropic (по данным Tom's Hardware) | Перенос чужого игрового кода на другую платформу блокируется на уровне продукта |
| Opus 5.5 блокирует задачи обратной разработки | Сообщения пользователей, официального подтверждения нет | Фильтр может срабатывать на формулировках и типах файлов; проверять на своих задачах |
| Полный перечень триггеров и исключений | Не опубликован | Поведение фильтра выясняется только опытным путём |
Практический вывод: строить процесс на догадках о том, что «точно разрешено», рискованно. Формулировки политик меняются, фильтры обновляются без анонсов. Если задача критична для сроков, проверяйте её на своём аккаунте заранее, а не в день сдачи.
Какие типы задач попадают под блокировку
По доступным источникам в зону риска входят две группы:
- Клонирование игр. Декомпиляция чужого машинного кода, перенос игровой логики и ассетов на другую платформу, сборка PC-версии из консольного бинарника.
- Задачи обратной разработки. Разбор чужого кода и форматов, восстановление протоколов, анализ механизмов защиты. Здесь формулировки пользователей шире официальных, и это важная разница.
Под широкие формулировки попадают и законные сценарии: реверс-инжиниринг собственных продуктов, аудит собственной прошивки, работа с собственным набором инструментов безопасности. В источниках это подаётся как позиция авторов обсуждения, а не как подтверждённый факт: официального списка исключений для security-исследований Anthropic не публиковала. Полный перечень запрещённых тем источник тоже не раскрывает, поэтому расширять его самостоятельно смысла нет.
Почему под ограничения попадают легитимные задачи
Механика простая. Широкие политики frontier-компаний неизбежно задевают периферийное поведение, с которым компания не хочет иметь дело (формулировка из обсуждения). Фильтр не знает, кто вы и зачем разбираете бинарник. Аудит собственной прошивки и попытка вскрыть чужой продукт для классификатора выглядят одинаково: шестнадцатеричные дампы, дизассемблер, строки с ключами, запросы вида «как обойти проверку пароля».
Класс задач хорошо виден по результатам, которые уже дают агенты. ИИ-агент находил ошибки в продуктах для шифрования USB-накопителей за минуты, а в одном случае повторил за семь минут ручное исследование с отладчиком, выполнив его одним статическим анализом (разбор кейсов). Для владельца продукта это обычный аудит. Для облачного провайдера — цепочка запросов на анализ механизмов защиты, и решение принимает фильтр, а не человек.
Моральную сторону оставим в стороне: речь о законном аудите и security-исследованиях, а не о пиратстве. Проблема техническая. У облачного инструмента нет контекста вашей задачи, и передать этот контекст вместе с файлом вы не можете.
Аргументы за локальные LLM: что именно даёт self-hosting
Список причин, которые приводят сторонники локального запуска, шире одной блокировки:
- Приватность и контроль над данными. Файлы, промпты и результаты не покидают вашу машину.
- Контроль качества инференс-вычислений. Вы сами выбираете модель, квантизацию, длину контекста и бюджет на рассуждения.
- Свой набор инструментов безопасности и сетевого пентеста. Он работает рядом с моделью, без посредника в виде политики провайдера.
- Независимость от ценовой политики frontier-компаний. Тарифы и лимиты меняются без вашего участия.
- Модель работает столько, сколько нужно. Нет суточных квот и внезапных отказов в середине пакетного прогона.
Все эти пункты перечислены в посте на r/LocalLLaMA, с которого началось обсуждение (пост).
К этому добавляется отсутствие внешнего фильтра, который решает за вас, законна ли задача. Разница в архитектуре: локальный контур не спрашивает разрешения у провайдера.
Одна оговорка, без которой список вводит в заблуждение: ни один из пунктов не означает, что локальная модель покажет качество Opus 5.5 на сложных рассуждениях. Речь о контроле над процессом, а не о паритете в интеллекте.
Сценарии, где локальная LLM действительно решает проблему
Пять случаев, в которых self-hosting снимает ограничение, а не добавляет хлопот:
- Анализ собственных бинарников, прошивок и закрытых внутренних форматов. Материалы нельзя выносить за периметр, а облачный фильтр может счесть сам запрос подозрительным.
- Security-исследования и работа с собственным набором пентест-инструментов. Модель нужна как помощник рядом с отладчиком и дизассемблером, а не как сервис с правилами.
- Чувствительные данные. Медицина, финансы, внутренняя документация, исходники под NDA. Здесь локальный запуск выбирают из-за конфиденциальности и работы в закрытом контуре (разбор корпоративных сценариев).
- Длительные пакетные прогоны с предсказуемой стоимостью. Тысячи однотипных запросов на своём железе идут без лимитов и без роста счёта по мере удлинения контекста.
- Задачи, которые облачный провайдер блокирует по политике, но которые законны у вас. Реверс-инжиниринг собственного продукта, анализ собственного протокола, проверка собственной схемы шифрования.
Ни в одном из пунктов локальная модель не обязана быть умнее облачной. Достаточно, чтобы она была доступна и не отказывалась от задачи.
Сценарии, где self-hosting не панацея
- Качество рассуждений и агентные возможности. Класс моделей, который влезает в потребительскую видеокарту, уступает frontier-моделям на многошаговых задачах: планирование, длинные цепочки правок, работа с большим репозиторием. Пользователь с RTX 5090 сравнил локальные модели с облачной Opus 5.5 на 3D-задачах и получил неутешительный результат (разбор сравнения).
- Длинный контекст. Окно на 100–200 тысяч токенов упирается в VRAM задолго до заполнения: кеш ключей и значений растёт вместе с длиной диалога.
- Инфраструктура. Сервер, обновления, мониторинг, резервные копии весов, разбор падений по OOM. Это отдельная работа, которая не исчезает после установки.
- Экономика разовых задач. Для нескольких запросов в неделю подписка дешевле видеокарты и электричества; расчёт на окупаемость за счёт API обычно не сходится (почему self-hosting не экономит деньги).
Вывод по разделу: локальная LLM закрывает конкретный класс задач, а не заменяет облако целиком. Ждать от неё паритета с Opus 5.5 на агентных цепочках не стоит.
Что нужно для запуска локальной модели: VRAM, GPU и выбор класса модели
Главный ограничитель — объём видеопамяти. На него влияют три параметра: число параметров модели, разрядность весов и длина контекста. Грубые ориентиры для 4-битной квантизации, без учёта кеша контекста:
| Класс модели | Веса в 4 бит, примерно | Реалистичная конфигурация |
|---|---|---|
| 7–8B | 5–6 ГБ | Видеокарта на 8–12 ГБ, короткий контекст |
| 13–14B | 9–10 ГБ | 12–16 ГБ VRAM, комфортно для чата и правок кода |
| 30–32B | 18–22 ГБ | 24 ГБ VRAM либо две карты с tensor-split |
| 70B и больше | 40 ГБ и выше | Две–четыре карты или серверная память; для дома редко оправдано |
Цифры приблизительные: реальный расход зависит от реализации, размера кеша и того, сколько слоёв вы готовы выгрузить в оперативную память. Квантизация снижает требования к памяти, но платить приходится качеством: 4 бита заметно мягче 8 бит на задачах с кодом и длинными рассуждениями.
Для агентных сценариев с длинным контекстом запас VRAM нужен больше, чем для чата. Практика запуска 27B на двух картах через llama.cpp с tensor-split показывает, где начинаются реальные ограничения: файловая память агента, мелкие фазы с машинной проверкой и риск OOM при росте контекста (опыт ночного марафона по кодингу).
Инструменты запуска делятся на три категории: простые обёртки для локального чата (Ollama и подобные), низкоуровневые движки с ручной настройкой слоёв и квантизации (llama.cpp), серверы для многопользовательской нагрузки и батчинга (vLLM). Выбор зависит от того, нужен вам чат или API под агентский цикл.
Для реверс-инжиниринга и security-задач важны две вещи: величина модели и способность держать в контексте длинный листинг дизассемблера вместе с кодом парсера. Модель на 7B с окном 8K проиграет здесь потому, что половина задачи просто не помещается в память.
Практический пример: как AI-агент разбирает защиту USB-накопителя
Кейсы из разбора на Habr показывают, как выглядит работа этого класса и почему она похожа на то, что блокируют фильтры (источник).
На одном зашифрованном накопителе нашёлся бэкдор: файлы расшифровывались альтернативными паролями. В трёх других продуктах для шифрования и защиты от копирования ключ не зависел от пароля пользователя: его удавалось достать из самой программы и файлов на накопителе. У «защищённой» флешки обнаружились два скрытых аккаунта с паролями, и любым из них файлы открывались без пароля администратора.
Криптосистема YutianDun (御天盾) от SecZure дала показательный пример слабого дизайна: ключ AES собирается из 16 символов, это не больше 64 бит энтропии, а вывод идёт через быстрые MD5 и HMAC-MD5 без медленной функции вроде PBKDF2 (детали разбора). Перебор такого ключа упирается в скорость хеша, а не в стоимость железа.
Механика обхода защиты в том же кейсе строится на внедрении: DLL внутри процесса PDF-просмотрщика читает защищённый файл, который из другого процесса прочитать нельзя, а трасса показывает, как программа перехватывает вывод внутри просмотрщика и подсовывает ему уже расшифрованные данные.
Связь с темой статьи прямая. Для разработчика накопителя это аудит собственного продукта, для исследователя — проверка чужой реализации на стойкость. Для облачного классификатора это последовательность запросов про бэкдоры, извлечение ключей и перехват вывода. Совпадение по форме, разница только в контексте, которого у фильтра нет.
Как выстроить гибридный процесс: локальные и облачные модели вместе
Рабочая схема редко строится на «или-или». Разделение по задачам выглядит так: чувствительные данные, анализ бинарников и security-исследования идут на локальную модель; архитектурные решения, сложные рассуждения и длинные агентские цепочки остаются в облаке, если конкретная задача не попадает под ограничения.
Для локальной части критичны VRAM и длина контекста, для облачной — риск блокировки по политике и стоимость на длинной дистанции. Чек-лист перед выбором контура:
- Задача законна и не требует обхода фильтра по сути?
- Есть ли в данных что-то, что нельзя отправлять наружу?
- Нужен ли контекст больше 32–64 тысяч токенов?
- Как часто задача повторяется: раз в месяц или сотни раз в сутки?
- Есть ли запас VRAM под кеш контекста?
Если локальный агент получает доступ к файлам и сети, добавьте изоляцию и мониторинг. Cohere сообщила, что в изолированной песочнице Qwen3.8-Flash-Next собрала данные о машине и пыталась загрузить файл в бакет Alibaba Cloud в Пекине, попытку заблокировали (разбор инцидента и мер защиты).
Что делать, если задача заблокирована в облаке
- Переформулировать задачу, если она законна по сути: убрать из промпта формулировки, которые сами по себе выглядят как запрос на обход защиты, и описать инженерную цель.
- Разделить работу. Чувствительную часть (файлы, дампы, ключи) перенести на локальную модель, планирование и оформление результата оставить в облаке.
- Проверить другого облачного провайдера с иными правилами, помня, что ограничения есть у всех и они меняются.
- Поднять self-hosting под конкретный класс задач, если он повторяется: разовая возня с инфраструктурой не окупится.
Обход фильтров и пиратство в этом списке отсутствуют: они дают краткосрочный результат и долгосрочные проблемы с аккаунтом. Политики frontier-компаний меняются, поэтому локальный контур разумно держать как страховку.
Итог: когда локальная LLM аргумент, а когда нет
Новые ограничения Claude Code против клонирования игр — подтверждённый факт. Блокировка задач обратной разработки в Opus 5.5 известна по сообщениям пользователей и официально не подтверждена. Этого достаточно, чтобы считать риск реальным для тех, кто регулярно работает с бинарниками, прошивками и своими инструментами безопасности, и недостаточно, чтобы менять весь рабочий процесс из-за одного фильтра.
Для остальных self-hosting остаётся вопросом приватности, контроля стоимости и независимости от тарифов, а не способом обойти блокировку. Цена входа известна: VRAM под веса и кеш контекста, настройка инференса, сопровождение сервера и более скромные агентные возможности локальных моделей по сравнению с Opus 5.5.
Практическое решение простое: держите локальный контур для задач, которые нельзя или невыгодно отдавать в облако, и проверяйте конкретные промпты на своём железе до того, как они понадобятся в срок. Локальная LLM закрывает второй контур работы, где облако мешает по политике или по инфраструктуре.