Веб-поиск в API Claude: как работает и сколько стоит

В выдаче GET /v1/models появились два новых поля возможностей — anthropic_server_web_search и responses_hosted_web_search, — и у модели sonnet-5 первое из них сразу получило статус verified с отметкой проверки 18 августа 12:00 UTC. Это первый инструмент в каталоге, который исполняется на стороне модели, а не в вашем коде. Anthropic продаёт его по 10 долларов за 1000 поисков плюс обычная оплата токенов за найденное: по курсу ЦБ на 19 августа (85,1645 ₽) выходит 851,64 ₽ за тысячу вызовов, около 0,85 ₽ за один. Разбираем, что именно изменилось в контракте, сколько это стоит в масштабе рублёвых ставок каталога, как ограничить аппетит модели и что в нашей выдаче про эту плату пока не написано.

Обновление 30 августа 2026 года. Повторная проверка sonnet-5 после обновления маршрута подтвердила обычный Messages-ответ, но запрос с web_search_20250305 был отклонён. Устаревший verified снят, capability возвращена в unknown, и Claude server search снова закрыт до новой успешной маршрутной пробы. Для встроенного Deep Research сейчас используйте grok-4-20-multi-agent через /v1/responses без клиентского массива tools либо отдельные методы KeyDealer /v1/search и /v1/web/fetch.

Что изменилось в выдаче между 18 и 19 августа

В блоке capabilities у всех 37 текстовых моделей каталога прибавилось два ключа, которых в снимке накануне не было ни у одной. Изменение поймала ежедневная сверка снимков GET /v1/models — анонса не было:

Единственный verified — у sonnet-5, поле capabilities_verified_at показывает 2026-08-18T12:00:41Z. У остальных 36 моделей оба поля стоят в unknown. Четыре позиции каталога — генераторы изображений — блока capabilities не имеют вовсе, их эта правка не коснулась.

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

Что такое серверный веб-поиск в API Claude

Серверный веб-поиск — это инструмент, который сторона модели исполняет сама: она ходит в интернет, забирает страницы и складывает найденное в контекст, а в ответ возвращает текст с цитатами на источники. Ваш код при этом ни одного сетевого запроса не делает.

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

При серверном поиске от вас требуется только объявить инструмент в теле запроса. Остальное происходит на той стороне.

Практический смысл — снятая с вас инфраструктура: не нужен поисковый API, не нужен свой краулер, не нужно чистить HTML. Практическая цена — вы теряете контроль над тем, что попало в контекст, и платите за каждый вызов отдельно.

Сколько стоит один веб-поиск

Цена опубликована в документации разработчика: 10 долларов за 1000 поисков, и сверх этого — обычная оплата токенов за содержимое, которое поиск притащил в контекст. Второе слагаемое здесь не мелкий довесок: страницы занимают место, и платите вы за них как за входные токены.

Переведём в рубли по официальному курсу ЦБ на 19 августа 2026 года:

Чтобы почувствовать масштаб, сравните с рублёвой ставкой самой модели. sonnet-5 стоит 30 ₽ за миллион входных и 30 ₽ за миллион выходных токенов. Значит, один поиск по цене равен примерно 56,8 тысячам токенов этой модели. Один вызов инструмента съедает столько же, сколько приличный кусок контекста. Все рублёвые ставки каталога собраны в отдельном материале — сколько стоит миллион токенов в рублях, там же метод пересчёта из долларов.

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

Какие версии инструмента веб-поиска существуют

Версий три, и выбор между ними влияет и на счёт, и на качество ответа:

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

Оговорка из документации: динамическая фильтрация работает на моделях Claude 4.6 и новее. Для моделей без программного вызова инструментов нужно явно указать allowed_callers: ["direct"], иначе API вернёт 400 с прямым указанием на эту настройку.

Как ограничить поиск в запросе

Жёсткий потолок задаёт параметр max_uses, источники сужают allowed_domains или blocked_domains. Порядок действий при подключении:

1. Задайте max_uses — жёсткий потолок числа поисков на один запрос. Без него количество вызовов определяет модель.
2. Ограничьте источники: allowed_domains для белого списка либо blocked_domains для чёрного. Вместе их передавать нельзя, только одно из двух.
3. При необходимости задайте user_location с приблизительным городом, регионом, страной и часовым поясом — это локализует выдачу.
4. Проверьте allowed_callers, если работаете с динамической фильтрацией.

{
  "type": "web_search_20250305",
  "name": "web_search",
  "max_uses": 5,
  "blocked_domains": ["untrustedsource.com"]
}

Документация отдельно отмечает: склонность модели искать управляется системным промптом — её можно и подтолкнуть искать активнее, и попросить чаще отвечать самостоятельно. Но промпт остаётся уговором, а max_uses — ограничением. Для контроля расходов берите второе.

Тема ограничения прав инструмента шире одного поиска: что вообще стоит разрешать модели, разобрано в материале про права ИИ-агента. Веб-поиск — ровно тот случай, когда список доменов стоит сузить заранее. Первый счёт объяснит почему.

Как посчитать, сколько поисков сделала модель

Считайте поле usage.server_tool_use.web_search_requests в ответе — это количество поисков за запрос. Предсказать число заранее нельзя: решение искать принимает модель, поэтому счётчик остаётся единственным честным способом учёта.

"usage": {
  "input_tokens": 105,
  "output_tokens": 6039,
  "cache_read_input_tokens": 7123,
  "cache_creation_input_tokens": 7345,
  "server_tool_use": { "web_search_requests": 1 }
}

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

Чего в контракте каталога пока нет

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

Блок pricing в нашей выдаче описывает исключительно токены. Поля для платы за серверный вызов инструмента в GET /v1/models не появилось — формула биллинга у sonnet-5 осталась прежней: prompt_tokens input_rate + completion_tokens output_rate. Сколько будет стоить сам вызов поиска через маршрут, в опубликованном контракте не указано, и придумывать это число мы не станем.

Что из этого следует практически:

• Ставка 30 ₽ за миллион токенов у sonnet-5 относится к токенам. Найденные страницы приходят в контекст и оплачиваются как входные токены — эта часть предсказуема.
• Плата за сам вызов в полях каталога не описана. Проверяйте фактический расход по GET /v1/balance до и после серии запросов с поиском.
• prompt_cache.status у sonnet-5 — unsupported. Скидки за кэш промптов здесь нет, и результаты поиска не удешевятся при повторе.

Честный исторический статус на 19 августа: инструмент был помечен рабочим, его цена у разработчика модели была известна, отражение этой платы в нашем контракте — нет. С 30 августа этот маршрут больше не заявлен рабочим; сведения о цене ниже не означают текущую доступность.

Что с этим делать сегодня

Конкретный порядок, если свежие данные вам нужны:

1. Проверьте живую выдачу. GET /v1/models, поле capabilities.anthropic_server_web_search. Пока там нет verified, запрос с Claude server tool намеренно блокируется до оплаты и обращения к поставщику.
2. Для встроенного исследования используйте Grok Multi-Agent. Публичный ID grok-4-20-multi-agent работает через /v1/responses; веб-исследование встроено в маршрут, поэтому клиентский массив tools передавать не нужно.
3. Для управляемого поиска используйте методы KeyDealer. /v1/search находит актуальные источники, /v1/web/fetch читает конкретную страницу; результат можно передать любой подходящей текстовой модели.
4. Не переносите общий флаг поставщика автоматически. Протоколонезависимое поле search: true не доказывает поддержку web_search_20250305 в Messages API.
5. Возвращайте verified только после полной пробы. Нужны наблюдаемый поисковый результат, цитаты, terminal usage, корректное списание и повторяемость на точном текущем маршруте.

Ключ для этих запросов берётся на странице входа: один OpenAI-совместимый API, оплата в рублях, тот же ключ работает и по маршруту Messages.

Почему это событие крупнее одной модели

До 18 августа каталог описывал только то, что модель умеет с текстом: какие протоколы открыты, проходят ли инструменты, работает ли стриминг. Появление полей anthropic_server_web_search и responses_hosted_web_search означает, что в контракт въехала новая категория — инструменты, которые сторона модели исполняет за вас.

Первоначальный verified из тридцати семи выглядел скромно, а его последующая регрессия показала главное: capability — не вечное свойство названия модели, а состояние конкретного маршрута на момент проверки. Полезная привычка — сверять capabilities перед включением функции и повторять пробу после каждого изменения маршрутизации. Первым расхождение замечает тот, кто проверяет наблюдаемое поведение, а не переносит рекламный флаг из чужого каталога.