Brave Search API en 2026: Search vs Answers, precios y primeras peticiones que sí funcionan

Si vas a usar Brave Search API hoy, lo primero que debes hacer es elegir entre Search y Answers. Search es el mejor punto de partida cuando quieres resultados web en bruto, grounding mediante LLM Context o endpoints especializados como Place Search, pero todavía quieres conservar el control de la lógica de la aplicación y de la capa del modelo. Answers es mejor cuando quieres que Brave devuelva directamente la respuesta final con grounding a través de una interfaz compatible con OpenAI.

Brave Search API no es un único "endpoint mágico". En 2026 se entiende mejor como un mapa pequeño de rutas: Search para el substrate de búsqueda, Answers para el grounded output final, LLM Context para los casos en los que quieres conservar tu propio modelo pero aprovechar la capa de grounding de Brave, y Place Search para cuando el objeto real es un lugar físico y no una página web.

Nota de vigencia: el 1 de abril de 2026 se revisaron de nuevo la landing pública de Brave, la página de precios, la guía de autenticación, la documentación de Search, la documentación de Answers, la documentación de Place Search y el post oficial de Brave del 12 de febrero de 2026.

TL;DR

La respuesta corta y segura es esta.

La regla más simple es esta: si quieres seguir controlando la capa del modelo, usa Search; si quieres que Brave asuma más de la capa de respuesta, usa Answers.

Qué significa Brave Search API ahora mismo

La forma más fácil de perderse es imaginar Brave Search API como un solo endpoint con una lista larguísima de funciones opcionales. El contrato público actual de Brave es bastante más claro. La página de precios divide el producto en dos rutas públicas principales: Search y Answers.

Search es el plan de substrate. Te da los datos de búsqueda que realmente necesitan los agentes, chatbots, productos de búsqueda y sistemas de retrieval: Web Search, LLM Context, News Search, Video Search, Image Search y el camino más nuevo de Place Search. El precio público actual es $5 por cada 1.000 requests, $5 en credits mensuales y una capacidad por defecto de 50 requests por segundo. La landing además lo presenta como el plan para "real-time search data your chatbots and agents need to generate answers". Esa formulación es útil porque dice exactamente lo importante: aquí obtienes la capa de búsqueda, no toda la aplicación.

Answers es el plan de respuesta final. Se apoya en la infraestructura de búsqueda de Brave y devuelve grounded AI answers a través de una interfaz compatible con OpenAI. El precio público actual es $4 por cada 1.000 queries más $5 por 1M input tokens y $5 por 1M output tokens, además de $5 en credits mensuales, con una capacidad por defecto de 2 requests por segundo. Ese throughput más bajo no es arbitrario. Brave está haciendo más trabajo de la pila por ti.

Hay dos hechos más que conviene poner arriba del todo. Primero, Summarizer Search está deprecated a favor de Answers. La documentación todavía lo conserva para usuarios del ya discontinuado Pro AI plan, pero eso es compatibilidad heredada, no una recomendación para proyectos nuevos. Segundo, Brave Search API no es un scraper sobre Google o Bing. La landing afirma que el servicio funciona sobre un índice propio de más de 30.000 millones de páginas con más de 100 millones de actualizaciones diarias. Si de verdad estás evaluando el producto, ese dato sobre el índice independiente importa más que muchos claims de benchmark.

Elige primero el contrato, no el nombre de marca

La decisión más importante es no empezar por la capa equivocada.

Si necesitas un substrate clásico de búsqueda, empieza por /res/v1/web/search. Es la ruta correcta cuando quieres URLs, snippets, paginación, operadores de búsqueda, filtros o cualquier resultado en bruto que luego tu producto transformará. Se comporta como infraestructura de búsqueda: pides resultados y después tu sistema decide qué hacer con ellos.

Si necesitas grounding para tu propio modelo o agente, empieza por /res/v1/llm/context. En la reestructuración de febrero de 2026, Brave elevó LLM Context a una ruta pública de primer nivel en lugar de dejarlo como una función secundaria escondida en la documentación. Brave lo describe como un data-first ranking path que compacta los fragmentos web más relevantes para el consumo de un modelo. Eso significa que no es simplemente "búsqueda con otro nombre". El valor real está en mantener tu propia capa LLM mientras recibes un retrieval output más útil para modelos que el Web Search normal.

Si necesitas una grounded answer final cuanto antes, empieza por Answers. Esta ruta encaja mejor cuando tu producto no necesita conservar la answer synthesis por su cuenta, o cuando quieres llegar rápido a un answer engine con citas. La documentación lo expone a través del endpoint compatible con OpenAI /res/v1/chat/completions con model="brave". Para equipos que ya usan las librerías cliente de OpenAI, el camino es sorprendentemente corto.

Si el objeto real es un lugar físico, no lo fuerces por Web Search si no tienes un motivo concreto. Place Search está pensado para negocios, landmarks, hoteles, museos y descubrimiento cercano. La documentación pública lo describe como un índice con más de 200 millones de lugares, con datos POI estructurados, búsqueda sensible a la geografía y endpoints de detalle para consultas posteriores. Eso es un workload distinto al ranking de páginas web.

La decisión se aclara si primero defines quién debe poseer la answer layer. Si la respuesta es "tu aplicación", quédate en Search y elige entre Web Search, LLM Context y Place Search. Si la respuesta es "Brave", usa Answers.

Precios actuales, rate limits y la parte que casi siempre se malinterpreta

La tabla de precios es directa, pero para integrar bien conviene leer también las condiciones del contrato.

El punto importante no es cuál plan es "barato" o "caro". El punto importante es que Answers te cobra porque Brave está asumiendo más trabajo de la capa de aplicación. Si ya tienes tu propio model stack, retrieval layer y synthesis pipeline, Search suele ser el default más natural. Si en cambio quieres que Brave haga el salto de búsqueda a respuesta, Answers suele ser más limpio incluso con el coste adicional por tokens.

Una restricción operativa aparece ya en el alta. El FAQ actual de la landing de Brave todavía dice que hace falta tarjeta de crédito para suscribirse al free plan por razones antifraude, y que la tarjeta no se cobra por ese free plan. Al mismo tiempo, la página de precios presenta el servicio como planes de pago con credits mensuales recurrentes. La lectura operativa más segura es esta: sí hay credits mensuales, pero no conviene imaginar el onboarding como un sandbox público sin tarjeta ni fricción.

Hay además dos detalles que afectan directamente al uso en producción. La documentación de rate limiting dice que los límites se calculan en una ventana deslizante de 1 segundo, y que las respuestas incluyen cabeceras X-RateLimit-* que de verdad deberías monitorizar en vez de recordar solo cuando aparezca el primer 429. Brave también deja claro que si quieres almacenar resultados total o parcialmente, incluso para training o tuning de un LLM, necesitas un plan con storage rights explícitos. No es el tipo de restricción que quieras descubrir después de cerrar la arquitectura.

Para compradores enterprise, las páginas públicas de Brave también muestran dos señales útiles: SOC 2 Type II y una vía hacia Zero Data Retention. Si privacidad o compliance forman parte de tu proceso de compra, eso sí pesa. Si aún estás en fase de prototipo, basta con entender que el contrato no está pensado solo para experimentos casuales.

Primera petición que funciona: búsqueda normal o contexto listo para el modelo

Si quieres validar primero el lado Search de la plataforma, la ruta más corta es una petición básica de Web Search con tu clave en la cabecera 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);

Una petición básica de Web Search te deja ver de inmediato la forma real de la capa de búsqueda. Recibes los resultados, compruebas si hay más páginas mediante query.more_results_available, y decides si paginar otra vez o pasar el resultado actual a tu lógica downstream. La documentación de Web Search también marca tres knobs de alto valor: extra_snippets=true puede devolver hasta 5 extractos adicionales por resultado; los operadores de búsqueda viven dentro de q y no como campos separados; y la paginación no es infinita, por lo que conviene mirar more_results_available antes de aumentar offset a ciegas.

Si tu workload real es un modelo o agente que necesita grounding compacto, LLM Context suele ser la mejor primera prueba del lado Search:

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"

La diferencia está en la forma de la respuesta. Web Search sigue centrado en URLs y snippets porque es una API de resultados de búsqueda. LLM Context está diseñado para grounding. Si el siguiente paso es pasar el resultado a tu propio modelo, a tu coding agent o a un pipeline de razonamiento, suele ser un punto de partida más natural que el Web Search normal. Así lo presenta también Brave en sus materiales públicos de febrero de 2026.

Primera grounded answer a través del SDK de OpenAI

Si tu trabajo no es "dame retrieval substrate" sino dame la grounded answer final, la prueba más corta es el endpoint Answers a través de un cliente de OpenAI.

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())

Aquí la documentación incluye una restricción pequeña en apariencia pero importante en la práctica: citations, entities y research mode requieren streaming. No es una nota marginal. Answers puede devolver una estructura más rica que un chat completion normal. Los docs de Brave describen etiquetas especiales como <citation>, <enum_item> y <usage>, y conviene parsearlas si quieres una UX limpia y una observabilidad fiable.

También conviene pensar bien antes de activar research mode por defecto. Brave explica que el single-search mode por defecto está optimizado para velocidad y suele empezar a hacer stream en menos de 4,5 segundos, mientras que research mode puede lanzar múltiples búsquedas y alargarse minutos en preguntas complejas. Eso lo convierte más en una herramienta para tareas en segundo plano que en un ajuste universalmente "mejor". Si tu producto valora la latencia interactiva, quédate en el modo por defecto hasta que puedas justificar claramente por qué vale la pena pagar más y esperar más.

Dónde Brave sí es más útil que un wrapper genérico de búsqueda

Brave se vuelve bastante más interesante cuando dejas de evaluarlo como otra search box y empiezas a verlo como una search infrastructure que puedes dirigir.

La primera diferencia es el índice. Los materiales públicos de Brave repiten la misma idea: esto es un independent index, no una capa de scrape-and-repackage sobre Google o Bing. Esa afirmación solo importa si cambia lo que puedes construir, y en la práctica sí lo hace. Brave combina el índice independiente con funciones que se sienten más de operador que de folleto, como Goggles para reranking y filtering, extra snippets para más contexto por resultado y schema-enriched results para objetos estructurados como reviews o wikis. No son bullets de marketing abstractos. Son controles que sí importan cuando tu workflow de search o de agentes choca una y otra vez con los mismos retrieval blind spots.

La segunda diferencia es que Brave ahora expone públicamente tanto una substrate layer como una answer layer. Muchas herramientas relacionadas con búsqueda te fuerzan a una u otra. Brave te deja decidir si quieres resultados crudos, contexto compacto listo para el modelo o una grounded answer ya terminada. Por eso la comparación correcta a menudo no es "¿es Brave mejor answer engine que X?", sino "¿cuánta answer layer quiero poseer yo mismo?".

La tercera diferencia es el encaje con el ecosistema. La tools page oficial de Brave ya lista un MCP Server y varias integraciones con LangChain, LlamaIndex, Dify, Flowise, Postman y herramientas editoriales o de agentes. Si tu ruta de evaluación más rápida es "enchufar search a una herramienta de agentes esta misma tarde", eso importa. Si más adelante decides que prefieres una capa relay / gateway por encima de los native endpoints de Brave, y no Brave como superficie superior de integración, nuestra guía de OpenClaw API cubre precisamente esa decisión de arquitectura aparte.

Place Search merece una mención más porque cambia la forma de toda la plataforma. Todavía hay muchos artículos que hablan de Brave como si solo fuera "web search + AI answers", pero ahora ya existe una ruta útil de descubrimiento local. Si tu workload es "cafeterías cerca de una coordenada", "museos en París" o cualquier función cuyo objeto sea un lugar, /local/place_search es una decisión de primer orden, no una nota al pie.

Los errores que más suelen quemar la primera semana

Gran parte de la frustración inicial con Brave Search API no viene de no tener una feature rara, sino de arrancar con una suposición equivocada.

• Empezar un proyecto nuevo en Summarizer Search. Brave ya lo marca como deprecated y mueve el trabajo nuevo hacia Answers. Que el tutorial viejo siga indexado no significa que deba ser tu default.
• Saltar a Answers cuando solo necesitas grounding substrate. Si tu aplicación ya tiene su propia capa de modelo, Answers puede resultar más caro y menos controlable de lo necesario.
• Ignorar que el rich output de Answers depende del streaming. Si quieres citations, entities o research mode, conviene diseñar el flujo pensando en streaming desde el principio.
• Tratar los monthly credits como si fueran un sandbox público sin fricción. Las páginas públicas siguen sugiriendo fricción de alta y de tarjeta. No significa que no puedas evaluar la API; significa que debes planificar el onboarding con honestidad.
• Dejar para después rate limits y storage rights. Las cabeceras X-RateLimit-* y las restricciones de almacenamiento deberían estar en tu primer checklist de integración, no en la post-mortem.
• Forzar el descubrimiento local por Web Search. Si el objeto es un negocio, un landmark o un lugar cercano, Place Search suele ser la primera sospecha correcta.

La ruta más corta y más segura para empezar

Si todavía dudas por dónde empezar, basta con recordar una regla: si quieres control, usa Search; si quieres una respuesta terminada, usa Answers.

Para la mayoría de los equipos de ingeniería, la evaluación más segura al principio suele ser Web Search o LLM Context dentro del plan Search, porque esas rutas mantienen la arquitectura honesta. Primero ves cómo rinde la retrieval layer y luego decides si Brave debe quedarse como substrate o subir más hacia la answer layer. Si tu producto de verdad consiste en "devolver grounded answers con la mínima integración posible", entonces no des vueltas y empieza por Answers.

Lo que no conviene hacer es dejar que un tutorial viejo o un resumen centrado solo en precios tome la decisión por ti. El contrato público actual de Brave ya es suficientemente claro, pero solo si lo lees como un mapa de rutas y no como el nombre de un único endpoint.