Reseña de OpenRouter Web Search: benchmark, coste y modelos para agentes de IA

2026-08-13
Probamos OpenRouter Web Search como capa de búsqueda para agentes de IA: profundidad, modelos, coste, BrowseComp y alternativas.
OpenRouter Web Search merece una recomendación condicionada: resulta útil para equipos que quieren conectar distintos modelos con una interfaz de búsqueda común y actuar como motor de búsqueda para agentes dentro de una aplicación, pero no sustituye a un benchmark reproducible ni garantiza que cada respuesta sea correcta. Durante dos semanas probé el flujo con consultas de actualidad, documentación técnica y preguntas de investigación de varias fuentes. En esta evaluación separo la herramienta de búsqueda, el modelo que interpreta los resultados y el coste final, porque mezclarlos produce conclusiones engañosas.
La pregunta importante no es si un modelo “sabe buscar”. Es cuánto profundiza, qué fuentes encuentra y cuánto pagas cuando un agente repite consultas. Aquí encontrarás una ficha rápida, el método de prueba, una lectura práctica de BrowseComp y la comparación con Perplexity y Tavily.
OpenRouter Web Search: Especificaciones rápidas
| Indicador | Resultado práctico |
|---|---|
| Tipo | Capa API para modelos y herramientas web |
| Uso principal | Aplicaciones y agentes de IA con búsqueda en tiempo real |
| Acceso | Cuenta de OpenRouter, API key y créditos según el modelo o proveedor |
| Enrutamiento | Selección manual de modelo y proveedor; las opciones disponibles pueden cambiar |
| Profundidad | Depende de las llamadas que haga el modelo y de la configuración de búsqueda |
| Android | No he encontrado una aplicación Android oficial que deba recomendarse |
| Mejor escenario | Prototipos y productos que necesitan cambiar de modelo sin rehacer toda la integración |
Pros
- Interfaz común para modelos con búsqueda web.
- Permite comparar enrutamiento y coste en un mismo proyecto.
- Encaja bien en flujos de búsqueda para agentes de IA.
- Más control técnico que una aplicación cerrada.
Contras
- El coste real aumenta con búsquedas y tokens repetidos.
- La calidad depende del modelo, proveedor y consulta.
- No es un resultado oficial de BrowseComp por sí solo.
Cómo probé OpenRouter Web Search y el benchmark BrowseComp
Usé la misma instrucción en tres familias de consultas: hechos recientes con una fuente oficial, preguntas técnicas que exigían abrir documentación y preguntas de varias pistas inspiradas en BrowseComp. Repetí cada consulta con un modelo rápido y otro orientado al razonamiento, sin presentar el ejercicio como una puntuación oficial. Medí si la respuesta citaba una fuente pertinente, si distinguía un dato confirmado de una inferencia y si podía reconstruir el camino de búsqueda.
El resultado fue desigual pero útil. Las preguntas de una sola fuente se resolvieron con rapidez cuando la consulta incluía el nombre exacto del producto. Las preguntas con pistas indirectas exigieron varias búsquedas y una revisión manual. En dos casos, el agente encontró una página relacionada, pero convirtió un detalle contextual en una respuesta definitiva. Esa es la diferencia entre recuperar páginas y hacer investigación fiable.
Profundidad de búsqueda en OpenRouter Web Search
La profundidad no es un interruptor mágico. Un agente puede hacer una sola búsqueda y resumirla, o encadenar consultas, abrir resultados y contrastar fuentes. En mis pruebas, la segunda estrategia mejoró las preguntas de varias pistas, pero también multiplicó la latencia y el consumo. Para una consulta simple, más pasos solo añadieron texto.
Recomiendo limitar el número de llamadas, exigir una fuente primaria cuando exista y pedir que el agente indique qué dato no pudo verificar. La configuración debe tratar la profundidad de búsqueda como un presupuesto, no como una promesa de precisión.
Enrutamiento de modelos: el modelo también forma parte del benchmark
OpenRouter separa el acceso al modelo de la lógica de la aplicación. Eso facilita probar distintas opciones con una API compatible, pero complica la lectura de resultados: una respuesta puede cambiar porque cambió el modelo, el proveedor, la disponibilidad o el motor de búsqueda.
Para comparar de forma limpia, fijaría el modelo y el proveedor durante la primera ronda. Después haría una segunda ronda con enrutamiento alternativo. Los modelos rápidos suelen bastar para localizar una página; los modelos de razonamiento son más apropiados cuando hay que unir pistas, aunque consumen más tokens y pueden tardar más. El mejor modelo para investigar en la web depende de esa relación entre profundidad, coste y necesidad de explicación.
OpenRouter Web Search: Coste de búsqueda con IA
El coste de búsqueda con IA no es solo el precio del modelo. Incluye las llamadas de búsqueda, las páginas recuperadas, los tokens de entrada que vuelven a enviarse al modelo y la salida final. OpenRouter muestra precios por modelo y permite comprar créditos, pero las tarifas y la disponibilidad deben comprobarse en la página vigente antes de presupuestar un producto.
En un agente que hace una consulta, lee cinco páginas y repite dos búsquedas, el gasto puede superar claramente al de una respuesta breve sin navegación. Para reducir sorpresas, establezco un máximo de búsquedas por tarea, recorto el contenido recuperado y registro el coste de cada modelo. El plan barato no siempre es el más económico si necesita muchas repeticiones para llegar a una respuesta utilizable.
OpenRouter vs Perplexity vs Tavily para búsqueda de agentes
OpenRouter Web Search funciona como una capa de integración: da al desarrollador libertad para cambiar el modelo y organizar el flujo. Perplexity se presenta como una experiencia de respuesta con búsqueda y citas ya empaquetada, por lo que exige menos trabajo de orquestación. Tavily está orientado a aplicaciones y agentes que necesitan resultados estructurados y controles de búsqueda. No son sustitutos idénticos.
En una prueba con una consulta técnica, Perplexity entregó una respuesta más terminada desde el primer intento. Tavily fue más cómodo cuando necesitaba pasar resultados estructurados al siguiente paso del agente. OpenRouter fue la opción más flexible para repetir el mismo flujo con modelos distintos, pero requirió más control sobre las instrucciones y la verificación. La diferencia no es quién “gana”; es cuánto control y trabajo de integración necesita cada enfoque.
OpenRouter Web Search: Privacidad, fuentes y límites
La capa de búsqueda no elimina los riesgos de enviar consultas a proveedores externos. Antes de usarla con información interna, revisa qué datos viajan en la solicitud, qué registros conserva cada servicio y qué dominios puede consultar el agente. Una lista de fuentes no demuestra que una conclusión sea correcta.
También hay límites prácticos: páginas dinámicas, contenido bloqueado y resultados duplicados pueden reducir la cobertura. El agente debe mostrar las URL relevantes y separar citas de interpretación. Si no puedes reconstruir por qué llegó a una conclusión, el resultado no está listo para una decisión importante.
Conclusión: ¿vale la pena OpenRouter Web Search?
Sí, con condiciones. OpenRouter Web Search es una buena elección para desarrolladores que necesitan una interfaz común, pruebas entre modelos y control del flujo de un agente de IA. No lo elegiría como solución sin supervisión para investigación de alto riesgo, ni usaría una puntuación aislada de BrowseComp para afirmar que el sistema es fiable en cualquier tarea.
El producto encaja mejor cuando el equipo fija un presupuesto, registra las llamadas, contrasta fuentes y acepta ajustar el modelo según el trabajo. Para una respuesta lista para leer con poca configuración, Perplexity puede resultar más directo. Para pipelines que necesitan resultados de búsqueda estructurados, Tavily puede reducir trabajo. OpenRouter ofrece más libertad, a cambio de más responsabilidad.