Какую модель Claude выбрать: Haiku, Sonnet или Opus

Держи Sonnet по умолчанию. Haiku ставь туда, где одна и та же операция повторяется сотнями. Opus зови, когда надо долго думать и цена ошибки высокая. Выбираешь ты по типу работы, а не по названию: объём и однотипность тянут вниз по линейке, многошаговое рассуждение и ответственность за вывод - вверх. Самая частая ошибка предпринимателя выглядит одинаково у всех - гоняешь тяжёлую модель на сортировке писем, а потом удивляешься счёту.

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

Чем Haiku, Sonnet и Opus отличаются между собой?

Три модели одной семьи различаются глубиной рассуждения, скоростью и ценой. Haiku отвечает почти мгновенно и стоит копейки. Sonnet тянет большинство рабочих задач при разумном расходе. Opus думает дольше всех и берёт то, где надо удержать в голове много условий сразу. Умения у них общие, разнится запас мышления.

Представь курьера, штатного сотрудника и приглашённого эксперта. Курьер быстро развозит однотипное и не задаёт вопросов, штатный закрывает девять из десяти обычных дел, эксперта зовут, когда ошибка стоит дороже его гонорара. Держать эксперта на разносе писем странно. Отправлять курьера на переговоры о поставке - тоже.

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

Модель	Где сильна	Где не подходит
Haiku	Массовый поток однотипных операций, извлечение полей, теги, классификация, быстрые короткие ответы	Длинная связная мысль, работа с большим документом, финальный текст на публикацию
Sonnet	Ежедневная работа: письма, статьи, разбор таблиц, скрипты продаж, правки по замечаниям, диалог по делу	Задачи с высокой ценой ошибки, где нужен максимум качества с первой попытки
Opus	Стратегия, аудит договора, сведение цифр из разных источников, сложные многоходовки, спорные случаи	Всё, что решается за десять секунд: дорого, медленно и без выигрыша в качестве

На больших вложениях вылезает ещё одна разница. Тяжёлая модель аккуратнее держит длинный контекст: реже теряет условие со страницы двадцать, чаще замечает, что пункт 4.2 противоречит пункту 9.1. На коротком запросе это преимущество не проявляется вовсе. Значит, и платить за него на коротком запросе не за что.

Какую модель ставить на какую задачу?

Разложи свои дела по двум признакам: сколько раз в месяц операция повторяется и что случится, если модель ошибётся. Частое и безобидное уходит вниз, редкое и ответственное - вверх. Ниже готовая раскладка по типовым задачам малого бизнеса, её можно переносить к себе почти без правок.

Задача	Модель	Почему так
Разметить входящие заявки по категориям	Haiku	Формат жёсткий, вариантов мало, объём большой - тут нужна скорость, а не глубина
Вытащить из письма имя, телефон, товар и срок	Haiku	Извлечение полей по шаблону, рассуждать не о чем
Проставить теги и рубрики контенту	Haiku	Сотни однотипных операций подряд, ошибка правится в один клик
Первый ответ в поддержке по типовому вопросу	Haiku	Скорость важнее стиля, сложное всё равно уходит человеку
Расшифровку созвона свернуть в список решений	Sonnet	Нужна связная выжимка и понимание, что тут главное
Написать письмо клиенту, статью, описание товара	Sonnet	Требуется тон и связная мысль, объёмы умеренные
Разобрать выгрузку продаж и назвать аномалии	Sonnet	Считает и комментирует, но выводы всё равно проверяешь ты
Скрипт разговора с возражениями	Sonnet	Средняя сложность, много итераций и правок
Аудит договора на риски и противоречия	Opus	Длинный документ, взаимосвязанные пункты, ошибка стоит денег
Свести цифры из трёх источников и объяснить расхождение	Opus	Многошаговое рассуждение, где каждый шаг опирается на предыдущий
Стратегия запуска, разбор ниши, спорное решение	Opus	Нужен разбор вариантов и честные возражения вместо первого попавшегося ответа
Собрать регламент для цифрового сотрудника	Opus	Пишешь один раз, работает месяцами - качество тут окупается

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

Про аналитику важно помнить одно: модель хорошо объясняет и плохо считает. Арифметику делай таблицей или скриптом, а модели подавай уже посчитанные итоги. Какие вопросы вообще имеет смысл задавать по цифрам - глянь ИИ для бизнес-аналитики. С поддержкой та же схема: первую линию закрывает быстрая модель, а стоит ли её вообще ставить - вопрос отдельный, он в тексте про чат-бота для бизнеса.

Почему на массовых операциях выигрывает дешёвая модель?

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

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

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

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

Смотри на объём операций за месяц. До сотни - бери что удобнее, экономия на этом уровне не стоит потраченных на неё раздумий. От тысячи - разница ощутима, и полдня на тест окупятся. Что выносить в поток первым, расписано в тексте про то, с каких задач начинать автоматизацию рутины.

Тут разобран один вопрос - выбор модели под задачу. Сам по себе он маленький, но сидит внутри большой картины: цифровые сотрудники, регламенты, память дела, и модель в этой картине просто деталь, которую меняют раз в полгода. Если хочешь увидеть картину целиком, можно забрать бесплатное обучение: доступ по почте, материал открывается сразу.

Когда есть смысл переплатить за Opus?

Тяжёлая модель окупается там, где ошибка стоит дороже разницы в цене. Договор с неучтённым пунктом об ответственности. Стратегия на квартал. Сведение цифр перед разговором с инвестором. Регламент, по которому потом полгода работает вся команда. Если задачу ты сам делал бы час или два, сосредоточенно и с блокнотом, - это задача для Opus.

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

Большой документ целиком - территория Opus. Сто страниц договора или свод регламентов надо не просто прочитать, а сопоставить между собой: где пункты спорят, где условие из приложения отменяет условие из тела. Такая работа съедает много контекста, и глубина модели превращается в реальную разницу в результате.

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

А вот чего Opus не делает: не спасает плохо поставленную задачу. Промпт расплывчат, контекста нет - тяжёлая модель выдаст более гладко написанную ерунду, и распознать её будет сложнее из-за уверенного тона. Деньги уйдут на украшение проблемы.

Как это выглядит в деньгах?

Всё зависит от того, где ты работаешь. В чате на claude.ai ты платишь за подписку, и выбор модели влияет на то, как быстро выбирается лимит: тяжёлая съедает запас заметно быстрее лёгкой. В API платишь за фактические токены, и там разница между младшей и старшей моделью серьёзная, причём отдельно по входу и по выходу.

Точные цифры бери только на официальной странице цен и в документации - в статье они устареют, а там всегда актуальные. Как устроены сами подписки, разложено в тарифах Claude; здесь важнее механика счёта.

Механика такая: платишь за вход и за выход отдельно, выход дороже входа в несколько раз. Значит, длинный ответ обходится дороже длинного вопроса, а просьба «дай сразу три развёрнутых варианта» стоит кратно дороже одного.

Две вещи снижают счёт заметнее, чем смена модели. Первая - кэширование повторяющегося куска промпта: если ты в каждом запросе подаёшь один и тот же регламент на две страницы, кэш убирает большую часть расхода на него. Вторая - пакетная обработка, когда тысяча однотипных запросов уходит одним заданием без требования ответить сию секунду. За терпение дают скидку.

Где работаешь	За что платишь	Что решает выбор модели
Чат claude.ai, бесплатный	Ничего	Тяжёлые режимы урезаны, потолок ловится в первый же день
Чат по подписке	Месячная плата	Скорость расхода лимита в скользящем окне
API напрямую	Токены входа и выхода	Прямая строка расхода: разница между уровнями заметная
Сценарий автоматизации	Токены плюс сам сервис	Модель на каждом шаге выбирается отдельно, и это главный рычаг экономии

Работаешь из России - к вопросу денег добавляется вопрос доступа и оплаты. Что там ломается и как обходится, лежит в инструкции по доступу к Claude.

Как проверить, справится ли модель подешевле?

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

1. Собери двадцать примеров из жизни. Бери те, что реально приходили: двадцать входящих писем, двадцать отзывов, двадцать строк из выгрузки. Обязательно затащи туда пять неудобных случаев - те, где ты сам думал дольше секунды.
2. Напиши эталон руками. Для каждого примера запиши, какой ответ считаешь правильным. Скучный шаг, который все пропускают, и именно из-за его пропуска потом спорят на вкусовщине.
3. Прогони один и тот же промпт на двух моделях. Условия совпадают до буквы: тот же текст задачи, те же вложения, тот же требуемый формат ответа.
4. Сравнивай вслепую. Убери подписи, какая модель что выдала, и разметь ответы на «годится» и «брак». Знание цены модели незаметно подкрашивает оценку, поэтому подписи мешают.
5. Посчитай процент брака и цену ошибки. Пять процентов промахов в тегах - терпимо, поправишь руками. Пять процентов промахов в ответах клиенту - уже нет.
6. Проверь края. Отдельно посмотри, что модели сделали с теми самыми пятью неудобными примерами. Обычно вся разница между уровнями сидит именно там.

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

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

Как разложить одну задачу между тремя моделями?

Крупная задача редко однородна внутри. Разложи её на шаги, посмотри на каждый шаг отдельно и назначь ему свой уровень. Грязную подготовительную работу забирает младшая модель, содержательную середину - средняя, а тяжёлая получает только последний короткий кусок, где решается спорное.

Обработка входящих заявок в таком виде выглядит как четыре ступени. Haiku разбирает поток: вытаскивает контакты, тему и бюджет, отсеивает спам, раскладывает по категориям. Sonnet пишет ответ по шаблону категории и подтягивает нужные условия. Ты смотришь на нестандартные случаи, которые модели пометили как спорные. Opus подключается там, где заявка крупная и требует индивидуального предложения.

Контентный конвейер собирается похоже. Младшая размечает собранные материалы, вытаскивает цитаты и факты, чистит расшифровки. Средняя пишет черновик и правит по замечаниям. Тяжёлая нужна там, где решается структура и где надо честно сказать: тема не тянет на материал.

Выигрыш двойной. Расход падает, потому что дорогая модель видит только маленький финальный кусок вместо всей кухни. Качество обычно тоже растёт: у каждой ступени одна понятная задача и один понятный критерий приёмки, а промпт на одну задачу всегда точнее промпта на пять.

Ступени удобно собирать в сценарии автоматизации, где модель на каждом шаге выбирается отдельно. Как ставится такая обвязка с нуля, показывает разбор n8n по шагам. Когда шагов становится много и между ними появляются условия и ветвления, конструкция превращается в ИИ-агента, и там выбор модели на каждом узле решает уже и скорость, и предсказуемость.

Что меняется, когда модель выбрана не по задаче?

Промах в обе стороны выглядит по-разному. Тяжёлая модель на мелочёвке бьёт по кошельку и по лимиту: ты сидишь и ждёшь ответ там, где хватило бы мгновенного, и к обеду упираешься в потолок. Лёгкая модель на сложном бьёт по репутации: ошибка приходит в уверенной формулировке и без предупреждений.

Перегруженную младшую модель видно сразу. Ответ правильный по форме и пустой по содержанию. Часть условий из промпта тихо потерялась. Вместо «в документе этого нет» появляется правдоподобная выдумка. Прогони тот же запрос ещё раз - ответ окажется заметно другим.

Грабли	Как выглядит	Что делать
Тяжёлая модель на потоке	Счёт растёт, лимит кончается к обеду, каждая мелочь ждёт ответа	Перенести операцию вниз по линейке и проверить тестом на двадцати примерах
Лёгкая модель на ответственном	Уверенный текст с потерянным условием, ошибка находится у клиента	Поднять уровень и добавить обязательную проверку человеком
Одна модель на все задачи	Либо переплата, либо брак, третьего не дано	Разложить задачи по весу один раз и записать раскладку в регламент
Выбор по названию модели	«Взял самую новую» без связи с типом работы	Выбирать по объёму и цене ошибки, имя модели вторично
Тест на трёх удобных примерах	Всё отлично, а в проде брак на четверти потока	Тестировать на реальных данных, включая неудобные случаи
Смена модели вместо правки промпта	Гоняешь один и тот же плохой запрос по всей линейке	Сначала контекст и критерии, потом уровень модели

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

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

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

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

Рабочая привычка складывается такая. Разведка и черновики - на средней модели в отдельном чате. Стало ясно, что задача тяжёлая, - открываешь новый чат с тяжёлой моделью и коротко сформулированной сутью, без всей истории метаний. Тяжёлая модель получает чистый вход и тратит запас на дело, а не на перечитывание твоих «нет, не так».

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

Что делать, если даже Opus не справился?

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

Проверь по порядку четыре вещи. Первое - есть ли у модели вообще данные для ответа: цифры, регламент, примеры твоих текстов, описание аудитории. Второе - названа ли форма результата: длина, структура, формат, запрещённые формулировки. Третье - не сидит ли в одном промпте пять задач сразу. Четвёртое - не утонула ли инструкция в середине длинного разговора, где модель её просто не видит.

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

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

И только если всё перечисленное сделано, а результат по-прежнему не годится, имеет смысл думать про уровень модели или про другой инструмент вообще. Иногда честный вывод звучит так: эту задачу текстовая модель не решает, тут нужен человек с калькулятором или программа. Чем сервисы отличаются под разные задачи, сравнивает разбор Claude или ChatGPT.

Модели обновляются - как не переделывать выбор каждые полгода?

Держись за правило, имя модели пусть остаётся переменной. Правило звучит так: объём и однотипность вниз, рассуждение и ответственность вверх. А какое имя стоит на каждом уровне сегодня - вопрос пятиминутной сверки с документацией. При обновлении линейки ты меняешь имена в своём регламенте, логика остаётся нетронутой.

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

Решение записывай вместе с причиной. Строчка «сортировка заявок - младшая модель, потому что формат жёсткий и объём большой» через полгода объясняет сама себя. Строчка «сортировка - Haiku» не объясняет ничего, и решение придётся принимать заново с нуля.

Ровно так же устроена вся сборка ИИ-команды: инструменты внутри ролей меняются, а описание роли, регламент и критерии приёмки живут годами. Чем такая роль отличается от разового промпта, объясняет разбор цифрового сотрудника.

Где в этой схеме всё равно нужен человек?

Модель снимает механику: перечитать, разметить, свести, переписать, оформить. За тобой остаётся то, что не делегируется ни на какой уровень линейки: решение, вкус и ответственность за результат перед клиентом. Ни Opus, ни любая модель следующего поколения эту часть не заберут.

Решение опирается на знание своего дела и на риск, который ты готов взять: модель разложит варианты и назовёт слабые места каждого, но подписываться под выбором будешь ты. Вкус - это когда ты слышишь, что один текст звучит как ты, а второй как рассылка из банка. Ответственность живёт в приёмке: кто-то живой обязан посмотреть на результат до того, как он уйдёт наружу.

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

С чего начать на этой неделе?

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

1. Выпиши десять своих регулярных задач. В столбик, живым языком, как ты сам их называешь. Рядом поставь примерное число повторов в месяц.
2. Проставь цену ошибки. Три уровня: правится в клик, стыдно перед коллегой, стыдно перед клиентом. Этого хватит для сортировки.
3. Разложи по уровням. Частое и безобидное вниз, редкое и ответственное вверх, всё остальное на среднюю модель.
4. Проверь тестом самую массовую задачу. Двадцать реальных примеров, эталоны руками, слепое сравнение двух моделей, подсчёт брака.
5. Запиши раскладку в файл с причинами. Одна строка на задачу: уровень модели и одно предложение, почему именно такой.
6. Поставь дату пересмотра. Раз в квартал прогони тест заново и посмотри, не переехала ли часть задач на уровень вниз.

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

Методику выбора Anthropic описывает в своей документации и в бесплатных курсах академии, там же лежат актуальные имена моделей и цифры. Ссылки ниже, читается за вечер.

Источники

• Choosing the right model - документация Anthropic - официальная методика выбора модели под задачу
• Models overview - документация Anthropic - актуальный состав линейки, окна контекста и возможности моделей
• Anthropic Academy - бесплатные курсы Anthropic, включая туториал по выбору модели
• Тарифы Claude - подписки и цены на модели, которые стоит сверять перед расчётом
• Prompt caching - документация Anthropic - как срезать расход на повторяющийся кусок промпта
• Batch processing - документация Anthropic - пакетная обработка массовых однотипных запросов
• Token counting - документация Anthropic - точный подсчёт веса запроса перед запуском в поток
• Context windows - документация Anthropic - что входит в контекст и почему длинный чат дорожает
• Extended thinking - документация Anthropic - режим глубокого рассуждения и когда он оправдан
• Building effective agents - инженерный блог Anthropic - как раскладывать сложную задачу на шаги с разными моделями
• Anthropic Help Center - справка по подпискам, лимитам и доступным моделям в веб-версии
• Claude Code - документация - выбор модели в терминальной работе и переключение по ходу задачи