Tomas el camino que recomiendan los docs: inicias sesión en una cuenta Nous, no pegas ninguna API key de terceros y esperas que la búsqueda simplemente funcione. En cambio, la primera búsqueda da error diciendo que tu identidad no tiene derecho. No hay nada mal configurado y tu cuenta está bien — la petición nunca salió de tu máquina. La detuvo una de tres puertas locales, y solo una de ellas tiene que ver realmente con el entitlement.

Aquí tienes cómo decide la ruta de búsqueda rápida gratuita quién cumple los requisitos, por qué antes dejaba fuera a los usuarios registrados y cómo saber en qué caso estás ahora.

Dos tipos de ruta, dos preguntas distintas

El gateway gestionado sirve dos cosas muy distintas:

• Integraciones facturadas de proveedores (extract, browser, imágenes, etc.). Estas comprueban que tienes derecho — acceso de pago al Portal, o un tool pool gratuito activo.
• La ruta search_type: "fast". El gateway la sirve sin ninguna comprobación de financiación, así que su pregunta de elegibilidad es intrínsecamente quién eres, no cuánto has pagado.

Históricamente, ambas rutas pasaban por un único resolutor, así que la segunda pregunta se respondía con la regla de la primera. Ese es el bug completo.

Las tres puertas, en orden

La corrección las recorre en orden de ejecución, y merece la pena leerlas enteras — porque si cualquiera de ellas dice que no, ves el mismo mensaje: «sin derecho»:

1. resolve_managed_tool_gateway() aplicaba managed_nous_tools_enabled() (acceso de pago, o una cuenta con un tool pool activo) a todos los proveedores — Perplexity incluido.
2. _managed_web_search() solo informaba de una ruta gestionada cuando la autodetección había aterrizado en Firecrawl y pasaba la prueba de disponibilidad del gateway con puerta. Así que una identidad sin derecho nunca llegaba a resolverse a la búsqueda de Perplexity.
3. El provider de Perplexity llamaba otra vez a ese mismo resolutor con puerta. Por eso, incluso escribiendo web.backend: nous a mano, te encontrabas con el mismo rechazo.

Sumadas, el efecto era: registras una cuenta, ves que existe una ruta gratuita para ti, y aun así nunca llegas a ella.

La corrección: acotar la ruta gratuita por identidad

El PR #130660 no relaja la puerta de pago. Le da a la ruta gratuita su propia regla:

• Un nuevo resolve_free_search_gateway() resuelve únicamente por identidad.
• El nuevo predicado fast_search_entitled() acepta una identidad de Portal registrada de cualquier tier — sin requisito de crédito ni de tool pool.
• Los proveedores facturados siguen pasando por resolve_managed_tool_gateway() exactamente igual que antes.

¿Y los invitados? Excluidos a propósito. La ruta gratuita se emite por identidad, y el tier de invitado anónimo no tiene ninguna cuenta de Portal detrás. Los invitados son byte a byte idénticos a antes y conservan el ring sin key. Esto no es una puerta que se cierra a los recién llegados — es «demuestra quién eres y usa la ruta gestionada; si no puedes, usa la rotación pública».

Hay dos detalles que merece la pena destacar por separado:

• Un fallo cierra por defecto en lugar de adivinar. Una consulta de cuenta fallida se resuelve como «no disponible». La parte contraintuitiva: una consulta fallida sigue marcada como sesión iniciada, y solo el campo error la distingue de una cuenta real — así que ese campo es estructural, no un cinturón de seguridad añadido.
• La coincidencia de tier ya no distingue mayúsculas ni espacios en blanco. La claim de tier llega tal cual desde el JWT o la información de la cuenta, y antes se comparaba de forma literal — un espacio de más bastaba para torcer el veredicto.

Cuando no se resuelve, el mensaje te dice en qué caso estás

El mismo cambio convirtió «por qué no ha funcionado» en tres frases distintas:

Tu situación	Lo que se te dice
Eres el tier de invitado anónimo	necesita una cuenta Nous (inicia sesión con /login)
No hay ninguna identidad usable (sesión cerrada o consulta fallida)	no hay ninguna identidad Nous usable (inicia sesión con /login)
El gateway no es accesible	el Nous Tool Gateway no es accesible

Están separadas a propósito, porque corresponden a tres acciones distintas: inicia sesión en los dos primeros casos y trata el tercero como un problema de red o de servicio que ninguna cantidad de inicios de sesión arreglará.

Cómo comprobarlo en tu propia máquina

• Asegúrate de no haber fijado explícitamente otro proveedor de búsqueda. Una vez que web.backend o web.search_backend nombra un proveedor concreto, la decisión es tuya y nunca se redirige — es un trade-off deliberado. Las claves están documentadas en la referencia de configuración de hermes.
• Separa la búsqueda de la extracción. Con web.backend: nous, la búsqueda la sirve el gateway gestionado de Perplexity mientras que la extracción sigue yendo a Firecrawl; la ruta gratuita es solo para búsqueda, y cualquier otra ruta de proveedor conserva su requisito de entitlement.
• No tienes que iniciar sesión. La rotación pública sin key sigue ahí para los invitados — consulta los cinco canales de búsqueda gratuitos y la guía del nivel gratuito sin API key; si prefieres traer tu propia key, lo cubrimos en el backend de búsqueda de Perplexity.
• Comprueba en qué build estás. La corrección se fusionó en main el 2026-10-01, y el tag más reciente (v0.21.5) tiene fecha del 24-9, así que todavía no está en el tag. Las instalaciones de Git que siguen main ya la tienen.

La conclusión

Esto no era una función que faltara. Era una elegibilidad juzgada en la dimensión equivocada: una ruta que nunca consulta tu saldo estaba siendo bloqueada por una lógica que sí lo hace, y las tres puertas informaban de la misma frase — así que lo único que veías era «sin derecho», nunca «se suponía que nunca ibas a necesitar un derecho».

La lección práctica es sencilla. Si la búsqueda te rechaza justo después de iniciar sesión, no te pongas a auditar tus créditos: comprueba primero si fijaste web.backend a otro proveedor y luego lee qué problema de identidad nombra realmente el mensaje. Acierta con la identidad y la búsqueda rápida gratuita es, sencillamente, gratuita.