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

> Если вы хотите использовать Brave Search API сегодня, сначала нужно разделить Search и Answers. Search лучше подходит, когда вам нужны сырые результаты поиска или grounding и вы сохраняете контроль над логикой приложения. Answers лучше подходит, когда вы хотите, чтобы Brave возвращал готовый grounded answer.

- URL: https://blog.laozhang.ai/ru/posts/brave-search-api
- Published: 2026-04-01
- Updated: 2026-04-01
- Author: AI Free API Team (https://blog.laozhang.ai/ru/about)
- Category: API Guide
- Tags: Brave Search API, Brave Answers API, LLM Context API, Search API, API Guide

---
Если вы хотите использовать **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 года._

![Схема, разделяющая Brave Search, LLM Context, Answers и Place Search как разные пути для разработчика](https://blog.laozhang.ai/posts/ru/brave-search-api/img/cover.jpg)

## TL;DR

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

| Если ваша реальная задача | Начните отсюда | Почему | Самое важное ограничение |
| --- | --- | --- | --- |
| Вам нужны сырые веб-результаты, snippets, pagination, filters и полный контроль над поиском | **Search plan + `/res/v1/web/search`** | Это основной поисковый substrate | Ranking, обработка результатов и answer layer остаются на вашей стороне |
| Вам нужен grounding для своей модели или agent | **Search plan + `/res/v1/llm/context`** | Brave упаковывает релевантный контекст в форму, удобную для модели | Это все еще substrate, а не API готового ответа |
| Вам нужен готовый grounded answer от Brave | **Answers plan + `/res/v1/chat/completions`** | OpenAI-совместимый путь с citations, entities и research mode | Богатые метаданные требуют streaming, а default throughput заметно ниже |
| Вам нужны nearby businesses, landmarks или другие POI | **Search plan + `/res/v1/local/place_search`** | Здесь объектом поиска является место, а не веб-страница | Не стоит по умолчанию пытаться решить такую задачу через обычный Web Search |
| Вы нашли старые гайды по Summarizer | **Не начинайте с этого** | Brave помечает Summarizer как deprecated и ведет новые кейсы в сторону Answers | Для legacy Pro AI пользователей он может сохраняться, но это не современный default |

Самое простое правило: **если вы хотите оставить у себя контроль над модельным слоем, используйте 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, не похожий на ранжирование веб-страниц.

![Схема выбора: когда стартовать с Web Search, LLM Context, Answers или Place Search](https://blog.laozhang.ai/posts/ru/brave-search-api/img/endpoint-map.jpg)

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

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

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

| Plan | Текущая публичная цена | Monthly credits | Default capacity | Лучший fit |
| --- | --- | --- | --- | --- |
| Search | `$5 / 1,000 requests` | `$5` | `50 requests/sec` | поисковые результаты, grounding context, новости, изображения, видео, place search |
| Answers | `$4 / 1,000 queries` + `$5 / 1M` input tokens + `$5 / 1M` output tokens | `$5` | `2 requests/sec` | готовые grounded answers через OpenAI-совместимые chat completions |

Ключевая мысль не в том, что один план "дешевле", а другой "дороже". Ключевая мысль в том, что **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 года.

![Схема потока: API key, Search quickstart, LLM Context и Answers](https://blog.laozhang.ai/posts/ru/brave-search-api/img/quickstart-flow.jpg)

## Первый 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](https://blog.laozhang.ai/ru/posts/openclaw-api-guide) разбирает именно эту отдельную архитектурную задачу.

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 обычно является более чистой первой попыткой.

![Защитная схема с ценами, лимитами, storage rights и предупреждением о deprecated Summarizer](https://blog.laozhang.ai/posts/ru/brave-search-api/img/production-guards.jpg)

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

Если вы все еще сомневаетесь, с чего начинать, запомните одно правило: **нужен контроль — 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.