Getting the most out of Opus 5.5 in Claude and Claude Code

Opus 5.5 в Claude и Claude Code работает дольше без вмешательства, думает перед каждым ответом и чётко сообщает, что сделало. Чтобы эффективно использовать модель, передавайте всю задачу одним сообщением, чётко определяя условие завершения — например, «все тесты проходят» или «старый клиент удалён». Opus 5.5 лучше справляется с многоэтапной работой, особенно в больших репозиториях, и может выполнять сложные задачи часами без надзора, если чётко указано, когда останавливаться и спрашивать пользователя.

Избегайте фраз вроде «подумай carefully» — модель уже думает перед ответом, и такие указания лишь замедляют начало ответа без повышения качества. Во время длительной работы можно добавлять уточнения в Claude Code, не прерывая процесс. Для дизайн-задач полезно указывать нежелательные паттерны (например, «не использовать кремовый фон» или «плюшеобразные кнопки»), так как модель по умолчанию склонна к определённым стилям. В Claude Code полезно вести файл CLAUDE.md с правилами остановки и разрешениями, а также использовать подагентов для больших миграций. Перед проверкой результатов сначала читайте, что модель требует от вас, а флаги можно переключать через /model или выбор модели. Fast mode ускоряет ответы в диалоговом режиме, но требует дополнительного включения и стоит дороже.

Комментарии (156)

Opus 5.5 превосходит предыдущие версии в длительных задачах и коммуникации, но вызывает опасения из‐за непредсказуемого поведения, чрезмерного расхода токенов и рисков автономных действий без контроля. Оптимизация CI: пользователь сократил время сборки с 10 до 4 минут и снизил стоимость на 60% за менее чем час, создав 12 PR. Однако полученные YAML‐файлы оказались нечитаемыми и необслуживаемыми из‐за гигантских bash‐скриптов, превратив систему в «Rube Goldberg machine» из duct tape. Успешно интерпретировал чертежи здания в PDF и создал корректную 3D‐модель в Blender за 45 минут, превзойдя 50+ часов ручной работы новичка, выявив те же ошибки, что и пользователь. Игнорировал ограничения: запускал процессы в пяти регионах вместо одного, вносил изменения, не упомянутые в отчётах, и спорил при исправлении, путая схожие названия систем. Для сложного планирования необходимо требовать пошагового размышления: без этого модель пропускает зависимости между задачами (например, шаг 2 требует функции, вводимой на шаге 14). Превосходит Fable в качестве коммуникации и требует меньше ручного управления, в отличие от Opus 5, который «говорил загадками» и подрывал доверие. Иногда вводит вымышленный жаргон, непонятный пользователю; для читаемого ответа требуется явно требовать: «перефразируй без жаргона». Длительные задачи (>1 час) требуют частых чек‐инов, а не «set and forget»: 5‐часовой запуск с десятистрочным запросом может дать результат, отличный от ожидаемого. Эффективно работает с визуальными данными: создал точную Star Trek‐стилистику интерфейса с SVG‐элементами из переданных изображений дизайна. Успешно интерпретировал старые схемы электроники из сканов сервисных руководств, выявляя одинаковые топологии и тонкие различия между схемами несмотря на разное оформление. Иногда «залипает» на орфанных процессах, ожидая завершения в течение дня, что делает её ненадёжной для долгосрочных задач, несмотря на экономию токенов при ожидании. Определение «DONE» должно быть чётким и измеримым (например, «все endpoint используют новый клиент»), иначе модель не сможет корректно оценить завершение. Слишком агрессивно использует токены: может сжечь недельный лимит за день; критикуются рекомендации по запуску агентов без учёта стоимости. Иногда отказывает в выполнении задач из‐за ложных срабатываний классификатора (например, запрещает написание «hand off» документа или переключение фокуса, даже при использовании менее мощных моделей). Не следует полагаться на «cargo cult» промпты: формальные шаблоны могут работать не из‐за реальной эффективности, а из‐за структуры; предлагается искать более естественные формулировки.