Модели Claude в 2026: 6 шагов проверки ответа до коммита

Какие модели Claude существуют и чем они отличаются?

В марте 2023 года Anthropic представила Claude и Claude Instant. Первый был основной версией, второй - более лёгкой. В июле того же года вышел Claude 2. Anthropic заявила об улучшениях в coding, math и reasoning, более длинных ответах и контексте до 100K токенов.

В ноябре появился Claude 2.1. Контекст вырос до 200K токенов. Добавились system prompts и beta-возможность tool use: вызов функций и API, поиск по веб-источникам, работа с базами знаний и калькулятором. Anthropic также заявила о снижении числа ложных утверждений и ошибочных ответов.

В марте 2024 года Anthropic перешла к семейству Claude 3. В него вошли Haiku, Sonnet и Opus.

У Claude 3 появились vision-возможности для изображений, графиков и технических схем. Anthropic также описала более аккуратное следование сложным инструкциям и меньше необоснованных отказов.

Дальше вышли Claude 3.7 Sonnet, а затем Claude Opus 4 и Claude Sonnet 4. Полный актуальный каталог после Claude 4 в этой фактуре не подтверждён. Поэтому названия более новых моделей я не подставляю из поисковой выдачи.

Какая модель Claude лучше для твоей задачи?

Запрос «лучшая модель claude» звучит как просьба назвать одного победителя. Такой ответ будет слишком грубым. Более мощная модель способна лучше справляться со сложной целью, но это не превращает её ответ в проверенный факт.

Смотри на четыре ограничения:

• Сложность задачи. Чем больше неоднозначных решений и связанных частей, тем выше цена поверхностного ответа.
• Объём входных данных. Длинный контекст требует модели и тарифа, где такой объём доступен.
• Формат результата. Для изображения, графика или схемы нужна vision-возможность.
• Инструменты. Если задача требует вызова функций, API, базы знаний или калькулятора, проверяй наличие tool use.

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

Haiku, Sonnet и Opus в Claude 3 расположены по возрастанию возможностей. При этом фактура не даёт точной таблицы: какая из них быстрее в конкретном сценарии, сколько стоит каждый запрос и как часто ошибается на задаче вайб-кодинга. Такие выводы без свежего теста я бы не делал. Пример сравнения на задаче с 1M токенов разбираю в статье Модель Claude против Kimi K3-256k.

Как сравнить модели Claude до начала работы?

Сделай одну таблицу под собственную задачу:

Токен: примерно слово или часть слова; в токенах измеряют и лимит окна, и стоимость вызова. Из фактуры подтверждены несколько переходов. Claude 2 поддерживал контекст до 100K токенов. Затем Claude 2.1 получил 200K, system prompts и tool use. При запуске Claude 3 тоже предлагал контекст 200K и vision.

Точные цены здесь не привожу. Они требуют официальных тарифов Anthropic с датой проверки. То же относится к сравнению скорости и точности между конкретными моделями. Историческое место модели в линейке не заменяет измерение на твоём запросе.

Я бы сравнивал одинаковый результат, оценивая его по одному критерию. Дай нескольким моделям одну задачу, один набор файлов и один критерий готовности. Потом проверь diff, тесты, команды и список предположений. Если одна модель написала длиннее, это ещё не значит, что она сделала больше.

Какую модель Claude использовать и как проверить ответ?

1. Опиши задачу и результат.

   Запиши, что должно измениться, какие файлы затронуты и по чему ты поймёшь, что задача готова. Не ограничивайся фразой «почини авторизацию». Нужен наблюдаемый результат: конкретный сценарий, экран, команда или тест.

   Пример формулировки:

   Скопировать

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

2. Выбери модель под сложность.

   Для короткого ответа не создавай длинный цикл. При большой задаче смотри на возможности, контекст, инструменты и цену ошибки. Если нужны изображения, графики или схемы, отдельно проверь vision. Если нужен вызов API или функции, проверь tool use.

3. Попроси план до правки.

   Пусть Claude сначала перечислит файлы, предполагаемую причину, варианты изменения и способ проверки. План нужен не ради красивого текста. Он даёт точку, с которой можно заметить неожиданный поворот.

   План и границы перед изменениемСкопировать промпт

   Сначала изучи связанные файлы и сформулируй:
   1. исходную проблему;
   2. критерий готовности;
   3. файлы, которые нужно изменить;
   4. файлы, которые менять нельзя;
   5. команды для проверки;
   6. возможные контрпримеры.
   
   Код пока не меняй. Если решение зависит от моего намерения,
   остановись и задай вопрос.

4. Потребуй проверяемые следы.

   Попроси минимальный diff, вывод команд, тесты и ссылки на строки. Сообщение «готово» не заменяет ни один из этих следов. Тест проверяй отдельно: сам тест тоже может быть написан так, что создаёт ложное срабатывание.

   • показать git diff;
   • назвать изменённые и новые файлы;
   • выполнить сборку или другую подходящую команду;
   • перечислить непроверенные части;
   • сопоставить результат с исходной задачей.

5. Задай независимый вопрос.

   Не спрашивай только «ты уверен?». Попроси привести контрпример, найти самый сильный аргумент против решения и проверить результат другим способом. Повторение того же рассуждения не даёт независимой проверки.

6. Проверь предположения отдельно.

   Найди места, где модель не запускала код, не открывала источник, не видела часть файла или выбрала значение по догадке. Такие места пометь и проверь руками. Человеческая экспертиза нужна там, где цена ошибки выше цены дополнительной проверки.

После этого сравни обещанный результат с фактическим. Если модель выполнила только часть задачи, не принимай её финальный текст за статус работы.

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

Что делать, если Claude говорит «готово», но результат не работает?

Проверь результат по порядку:

1. Сверь каждый пункт исходной задачи с фактическим поведением.
2. Посмотри git diff и git status.
3. Проверь, не изменился ли тест вместо исправления логики.
4. Запусти сборку или компиляцию отдельно.
5. Найди новые файлы, временные скрипты и незакоммиченные артефакты.
6. Прогони сценарий, который изначально не работал.
7. Задай вход с ошибкой, пустым значением или неожиданным типом.

Tim Sehn из DoltHub описал проблему коротко:

Слово «готово» может означать только конец текущей попытки. Оно не доказывает, что закрыта исходная цель. Особенно внимательно смотри на тесты. Anthropic отдельно пишет о ложных тревогах даже в агенте для поиска ошибок: найденная проблема может оказаться ошибкой самого теста.

Как понять, что Claude потерял контекст?

После длинной сессии задай контрольные вопросы:

• Какова исходная цель задачи?
• Какие файлы изменены?
• Какие строки изменены и почему?
• Какие команды уже запускались?
• Какие проверки прошли?
• Что осталось непроверенным?
• Какие решения были предположениями?

Плохой признак - ответ общими словами без имён файлов, команд и деталей. Ещё один - модель говорит, что прочитала файл, но не может воспроизвести содержание нужного участка.

Проверь это отдельным запросом:

Назови три точных факта из раздела X.
Укажи номера строк, к которым относится каждый факт.
Объясни, как каждый факт влияет на текущее решение.
Если ты не видишь часть файла, скажи это прямо.
Не делай новую правку до ответа.

Если после компрессии ответы снова запускают компрессию, становятся несвязанными или не содержат проверяемых деталей, текущей сессии доверять нельзя. Потеря контекста разобрана в статье Claude Code теряет контекст на третьем часу. Сохрани diff и начни новый диалог с исходной целью, списком файлов и уже выполненными командами.

Как ограничить Claude, если ошибка может повредить проект?

Более способная модель делает меньше очевидных ошибок, но лучше находит неожиданные пути к цели. Поэтому ограничивать надо не только текстом запроса.

Минимальный набор границ:

• права доступа только к нужным файлам;
• sandbox для изоляции среды;
• read-only режим на этапе изучения;
• отдельная ветка или копия проекта;
• отсутствие ключей, токенов и других секретов;
• ограниченная сеть;
• явный список разрешённых команд.

Anthropic формулирует принцип так:

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

Сначала дай Claude прочитать проект в read-only режиме. Потом разреши минимальную правку в отдельной ветке. После этого проверь diff и команды сам. Подтверждение действия не равно проверке результата. Безопасный бюджет разбираю в статье Подписка Claude Code: 3 остановки бюджета.

Вопросы и ответы