Brave Search API в 2026 году: Search vs Answers, цены и первый рабочий запрос

Если вы хотите использовать Brave Search API сегодня, начните с выбора между Search и Answers. Search лучше подходит, когда вам нужны сырые веб-результаты, grounding через LLM Context или специализированные endpoints вроде Place Search, а бизнес-логика и модельный слой остаются у вас. Answers лучше подходит, когда вы хотите, чтобы Brave сам возвращал grounded answer через интерфейс, совместимый с OpenAI.

Brave Search API не является одним "магическим endpoint". В 2026 году это маленькая карта маршрутов: Search для поискового substrate, Answers для готового grounded output, LLM Context для случаев, когда вы хотите оставить у себя собственную модель, но взять у Brave слой grounding, и Place Search для задач, где объектом является физическое место, а не веб-страница.

Примечание по актуальности: 1 апреля 2026 года были повторно проверены публичный лендинг Brave, pricing docs, auth docs, Search docs, Answers docs, Place Search docs и официальный релизный пост Brave от 12 февраля 2026 года.

TL;DR

Самый короткий безопасный ответ такой.

Самое простое правило: если вы хотите оставить у себя контроль над модельным слоем, используйте Search; если вы хотите, чтобы Brave взял на себя answer layer, используйте Answers.

Что Brave Search API означает сейчас

Самый простой способ запутаться — представить Brave Search API как один endpoint с длинным списком опциональных возможностей. Публичный контракт Brave сейчас устроен куда четче. Pricing page делит продукт на два главных публичных пути: Search и Answers.

Search — это план поискового substrate. Он дает те поисковые данные, которые реально нужны агентам, чат-ботам, поисковым продуктам и retrieval-системам: Web Search, LLM Context, News Search, Video Search, Image Search, а также новый Place Search. Публичная цена сейчас — $5 за 1,000 requests, $5 monthly credits и 50 requests per second как default capacity. Лендинг прямо описывает этот план как источник "real-time search data your chatbots and agents need to generate answers", и это правильная рамка: вы получаете поисковый слой, а не целое приложение.

Answers — это план готового ответа. Он стоит поверх поисковой инфраструктуры Brave и возвращает grounded AI answers через OpenAI-совместимый интерфейс. Публичная цена сейчас — $4 за 1,000 queries плюс $5 за 1M input tokens и $5 за 1M output tokens, плюс $5 monthly credits, а default throughput составляет 2 requests per second. Такая разница не случайна: в этой ветке Brave берет на себя больше логики вашего будущего продукта.

Еще два факта нужно вынести вперед. Во-первых, Summarizer Search теперь deprecated в пользу Answers. Docs сохраняют его для пользователей закрытого Pro AI plan, но это совместимость, а не рекомендация для нового проекта. Во-вторых, Brave Search API не является scraper-слоем над Google или Bing. Brave пишет, что сервис работает на собственном индексе из 30+ миллиардов страниц и обновляет 100+ миллионов страниц в день. Если вы действительно оцениваете продукт, этот факт про независимый индекс важнее многих бенчмаркетных лозунгов.

Сначала выберите контракт, а не бренд

Самое важное решение на старте — не выбрать неправильный слой первым.

Если вам нужен классический поисковый substrate, начинайте с /res/v1/web/search. Это верный путь, когда вам нужны URL, snippets, pagination, search operators, filters и любые сырые результаты, которые ваш продукт потом обработает сам. Этот endpoint ведет себя как поисковая инфраструктура: вы запрашиваете результаты, а дальше уже ваша система решает, что с ними делать.

Если вам нужен grounding для собственной модели или agent, начинайте с /res/v1/llm/context. В февральском обновлении 2026 года Brave вывел LLM Context в публичный первый ряд, а не оставил как второстепенную возможность где-то в глубине docs. Brave описывает его как data-first ranking path, который сжимает наиболее релевантные куски веб-контекста для потребления моделью. Это значит, что ценность здесь не просто в "поиске с другим названием". Настоящая ценность в том, что вы сохраняете свой LLM layer, но получаете retrieval output в форме, более удобной для модели, чем обычный Web Search.

Если вам нужен готовый grounded answer как можно быстрее, начинайте с Answers. Этот путь лучше подходит, когда продукту не нужно самому владеть answer synthesis, либо когда вы хотите как можно быстрее получить answer engine с цитатами. Docs показывают это через OpenAI-совместимый /res/v1/chat/completions и model="brave". Для команд, которые уже используют OpenAI client libraries, это удивительно короткий путь.

Если объект вашей задачи — физическое место, не стоит по умолчанию пропускать задачу через обычный Web Search. Place Search у Brave предназначен для businesses, landmarks, hotels, museums и nearby discovery. Публичные docs описывают его как индекс из более чем 200 миллионов мест со структурированными POI-данными, геочувствительным поиском и детальными endpoints для последующих запросов. Это другой workload, не похожий на ранжирование веб-страниц.

Здесь достаточно одного вопроса: кто должен владеть answer layer? Если ответ — "ваше приложение", оставайтесь в Search и выбирайте между Web Search, LLM Context и Place Search. Если ответ — "Brave", берите Answers.

Текущие цены, rate limits и то, что чаще всего читают неправильно

Сама таблица цен проста, но для внедрения важно читать ее вместе с условиями контракта.

Ключевая мысль не в том, что один план "дешевле", а другой "дороже". Ключевая мысль в том, что Answers включает цену за то, что Brave делает большую часть application-layer работы за вас. Если у вас уже есть своя model stack, retrieval layer и synthesis pipeline, Search обычно является более естественным default. Если же вы хотите, чтобы Brave сам делал прыжок от поиска к ответу, Answers становится чище, даже несмотря на token cost.

Одно из первых практических ограничений — signup contract. Текущий FAQ на лендинге Brave по-прежнему говорит, что для подписки на free plan требуется credit card в антифрод-целях, и карта не будет списана за сам free plan. Одновременно текущий pricing page описывает сервис как набор платных планов с recurring monthly credits. Самое безопасное операционное чтение здесь такое: credits есть, но onboarding не стоит воспринимать как полностью no-card публичную песочницу.

Еще два условия напрямую влияют на продакшн-эксплуатацию. Docs по rate limiting говорят, что ограничения считаются в 1-second sliding window, а в ответах приходят X-RateLimit-* headers, которые действительно нужно мониторить, а не вспоминать о них только после первого 429. Brave также прямо пишет, что если вы хотите хранить результаты полностью или частично, в том числе для training или tuning LLM, нужен план с явными storage rights. Это не та деталь, которую хочется обнаружить уже после фиксации архитектуры.

Для enterprise-покупателей публичные страницы Brave дают еще два значимых trust signal: SOC 2 Type II attestation и возможность запросить Zero Data Retention. Если приватность или compliance входят в procurement case, это реальное преимущество. Если вы все еще на стадии prototype, этого достаточно, чтобы понять: контракт рассчитан не только на игрушечные сценарии.

Первый рабочий запрос: обычный поиск или модельно-готовый контекст

Если вы хотите сначала доказать Search-сторону платформы, самый короткий путь — базовый Web Search request с вашим Brave API key в заголовке X-Subscription-Token.

js
const query = new URLSearchParams({
  q: "best open source vector database for hybrid search",
  count: "10",
  country: "US",
  search_lang: "en",
  extra_snippets: "true",
});

const response = await fetch(
  `https://api.search.brave.com/res/v1/web/search?${query}`,
  {
    headers: {
      Accept: "application/json",
      "Accept-Encoding": "gzip",
      "X-Subscription-Token": process.env.BRAVE_API_KEY,
    },
  },
);

const data = await response.json();
console.log(data.web?.results?.[0]);
console.log(data.query?.more_results_available);

Базовый Web Search request сразу показывает, в какой форме возвращается поисковый слой. Вы получаете результаты, смотрите, есть ли дополнительные страницы через query.more_results_available, и решаете, продолжать пагинацию или передавать текущий набор в downstream-логику. Web Search docs у Brave также выделяют несколько высокоценностных ручек: extra_snippets=true может вернуть до 5 дополнительных фрагментов на результат; search operators живут внутри q, а не отдельным полем; пагинация конечна, поэтому стоит смотреть more_results_available, а не просто бесконечно наращивать offset.

Если же ваш реальный workload — это модель или agent, которому нужен компактный grounding, на Search-стороне обычно разумнее начинать с LLM Context:

bash
curl -s --compressed \
  "https://api.search.brave.com/res/v1/llm/context?q=best+open+source+vector+database+for+hybrid+search" \
  -H "Accept: application/json" \
  -H "Accept-Encoding: gzip" \
  -H "X-Subscription-Token: $BRAVE_API_KEY"

Разница в форме выхода. Web Search по-прежнему ориентирован на URL и snippets, потому что это поисковый интерфейс. LLM Context сделан для grounding. Если следующим шагом вы передаете результат в свою модель, coding agent или reasoning pipeline, это обычно более естественная стартовая точка, чем plain Web Search. Именно так Brave и описывает разделение ролей в материалах февраля 2026 года.

Первый grounded answer через OpenAI SDK

Если ваша задача — не "дай retrieval substrate", а "дай готовый grounded answer", самый короткий proof — Answers endpoint через OpenAI client.

python
import asyncio
from openai import AsyncOpenAI

client = AsyncOpenAI(
    api_key="YOUR_BRAVE_SEARCH_API_KEY",
    base_url="https://api.search.brave.com/res/v1",
)

async def main():
    stream = await client.chat.completions.create(
        model="brave",
        stream=True,
        messages=[
            {
                "role": "user",
                "content": "Compare Brave Search API Search vs Answers for an internal research assistant",
            }
        ],
        extra_body={
            "country": "us",
            "language": "en",
            "enable_citations": True,
            "enable_research": False,
        },
    )

    async for chunk in stream:
        if chunk.choices and chunk.choices[0].delta.content:
            print(chunk.choices[0].delta.content, end="", flush=True)

asyncio.run(main())

Здесь docs содержат одну тонкую, но важную деталь: citations, entities и research mode требуют streaming. Это не мелкая пометка. Answers способен отдавать более богатый ответ, чем стандартный chat completion. Brave docs прямо описывают специальные теги вроде <citation>, <enum_item> и <usage>, которые действительно стоит парсить, если вы хотите аккуратный UX и внятный monitoring.

Research mode тоже не стоит включать автоматически. Brave говорит, что default single-search mode оптимизирован под скорость и обычно начинает stream меньше чем за 4.5 секунды, тогда как research mode может выполнить несколько поисков и длиться минуты на сложных вопросах. Это делает его инструментом для background-задач, а не универсальным "лучшим" режимом. Если для продукта важна interactive latency, оставайтесь в default mode до тех пор, пока не сможете явно назвать причину платить больше и ждать дольше.

В чем Brave сильнее обычного search wrapper

Brave становится заметно интереснее, когда вы перестаете оценивать его как еще одну search box и начинаете оценивать как search infrastructure, которой можно управлять.

Первое отличие — сам индекс. Brave публично и последовательно говорит, что это independent index, а не scrape-and-repackage слой над Google или Bing. Это утверждение имеет смысл только тогда, когда оно меняет то, что вы можете построить. На практике меняет. Brave соединяет независимый индекс с операторскими функциями вроде Goggles для reranking и filtering, extra snippets для большего количества контекста на результат и schema-enriched results для структурированных сущностей вроде reviews и wiki. Это не просто маркетинговые слова. Это реальные рычаги, когда ваш agent или search workflow снова и снова ломается на одних и тех же retrieval blind spots.

Второе отличие — Brave теперь публично дает и substrate layer, и answer layer. Многие search-adjacent продукты заставляют вас выбрать только одно. Brave позволяет решать, нужны ли вам raw search results, сжатый model-ready context или готовый grounded answer. Поэтому правильный вопрос часто не "лучше ли Brave как answer engine, чем X?", а "хочу ли я вообще сам владеть answer layer?"

Третье отличие — ecosystem fit. Официальная tools page Brave уже включает MCP Server и интеграции с LangChain, LlamaIndex, Dify, Flowise, Postman и редакторскими/агентными системами. Если ваш самый быстрый evaluation path — это "подключить search к agent tool сегодня же", это важно. Если позже вы решите, что хотите поставить relay/gateway слой выше native endpoints Brave, а не делать Brave верхней точкой интеграции, наш гайд по OpenClaw API разбирает именно эту отдельную архитектурную задачу.

Place Search стоит упомянуть еще раз, потому что он меняет саму форму платформы. До сих пор многие материалы пишут о Brave как о "web search плюс AI answers", но сейчас у него есть действительно полезный путь для local discovery. Если ваш workload — это "кофейни рядом с координатой", "музеи Парижа" или вообще любая задача, где объектом является место, /local/place_search — это решение первого порядка, а не сноска.

Ошибки, которые чаще всего сжигают первую неделю

Большая часть раннего разочарования в Brave Search API связана не с отсутствием редкой функции, а с одной неправильной исходной гипотезой.

• Начинать новый проект с Summarizer Search. Brave уже явно помечает его как deprecated и ведет новые сценарии в сторону Answers. Старые туториалы не должны определять ваш новый default.
• Прыгать в Answers, когда вам нужен только grounding substrate. Если у приложения уже есть свой model layer, Answers может оказаться дороже и менее управляемым контрактом, чем нужно.
• Игнорировать зависимость rich Answers output от streaming. Если вам нужны citations, entities или research mode, архитектура должна с самого начала считать streaming нормой.
• Принимать monthly credits за frictionless public sandbox. Публичные страницы по-прежнему указывают на signup/card friction. Это не значит, что оценка невозможна. Это значит, что ее нужно планировать честно.
• Откладывать rate-limit и storage-rights на потом. X-RateLimit-* headers и правила хранения результатов должны войти в ваш первый integration checklist.
• Тащить local discovery через обычный Web Search. Если объект — business, landmark или nearby place, Place Search обычно является более чистой первой попыткой.

Самый короткий и безопасный старт

Если вы все еще сомневаетесь, с чего начинать, запомните одно правило: нужен контроль — Search, нужен finished answer — Answers.

Для большинства engineering teams самый безопасный первый evaluation — это Web Search или LLM Context внутри Search plan, потому что эти пути держат архитектуру честной. Сначала вы видите retrieval layer, потом решаете, должен ли Brave остаться substrate или подняться выше, в answer layer. Если же ваш продукт с самого начала равен "минимум интеграции, максимум grounded answer", не делайте лишний круг и начинайте с Answers.

Чего делать не стоит, так это позволять старому tutorial или pricing-only summary принимать решение за вас. Публичный контракт Brave сейчас уже достаточно ясен — но только если читать его как route map, а не как имя одного endpoint.