Você segue o caminho que a documentação recomenda: faz login numa conta Nous, não cola nenhuma API key de terceiros e espera que a busca simplesmente funcione. Em vez disso, a primeira busca dá erro dizendo que sua identidade não tem direito de acesso. Nada está mal configurado e sua conta está bem — a requisição nunca saiu da sua máquina. Ela foi barrada por um de três portões locais, e só um deles é de fato sobre direito de acesso.

Veja como a rota de busca rápida gratuita decide quem se qualifica, por que ela costumava barrar usuários registrados e como identificar em qual caso você está agora.

Dois tipos de rota, duas perguntas diferentes

O gateway gerenciado serve duas coisas bem diferentes:

• Integrações de fornecedores cobradas (extract, browser, imagens e assim por diante). Essas verificam que você tem direito — acesso pago ao Portal, ou um tool pool gratuito vivo.
• A rota search_type: "fast". O gateway a serve sem nenhuma verificação de financiamento, então sua pergunta de elegibilidade é, por natureza, quem é você, e não quanto você pagou.

Historicamente, as duas rotas passavam por um único resolvedor, então a segunda pergunta era respondida com a régua da primeira. O bug é exatamente isso.

Os três portões, em ordem

A correção os percorre na ordem de execução, e vale a pena ler tudo — porque se qualquer um deles disser não, você vê a mesma mensagem de “sem direito”:

1. resolve_managed_tool_gateway() aplicava managed_nous_tools_enabled() (acesso pago, ou uma conta com um tool pool vivo) a todo fornecedor — incluindo o Perplexity.
2. _managed_web_search() só reportava uma rota gerenciada quando a autodetecção caía no Firecrawl e a sonda de prontidão do gateway, que passava pelo portão, era aprovada. Então uma identidade sem direito nunca era resolvida para a busca do Perplexity.
3. O provider do Perplexity chamava aquele mesmo resolvedor com portão de novo. É por isso que até escrever web.backend: nous à mão esbarrava na mesma recusa.

Empilhados, o efeito era: registre uma conta, veja que existe uma rota gratuita para você, e ainda assim nunca chegue até ela.

A correção: dar escopo por identidade à rota gratuita

O PR #130660 não afrouxa o portão pago. Ele dá à rota gratuita a sua própria régua:

• Um novo resolve_free_search_gateway() resolve puramente pela identidade.
• O novo predicado fast_search_entitled() aceita uma identidade Portal registrada de qualquer tier — sem exigência de crédito, sem exigência de tool pool.
• Fornecedores cobrados continuam passando pelo resolve_managed_tool_gateway() exatamente como antes.

E os convidados? Deliberadamente excluídos. A rota gratuita é emitida por identidade, e o tier de convidado anônimo não tem nenhuma conta Portal por trás. Os convidados permanecem byte a byte idênticos a antes e continuam no keyless ring. Isso não é uma porta se fechando para novatos — é “prove quem você é e use a rota gerenciada; se não conseguir, use a rotação pública”.

Dois detalhes merecem ser destacados separadamente:

• Uma falha falha fechado em vez de adivinhar. Uma consulta de conta que falha resolve para “não disponível”. A parte contraintuitiva: uma consulta que falha ainda é carimbada como logado, e só o campo error a distingue de uma conta real — então esse campo é estrutural, não uma redundância por segurança.
• A correspondência de tier não diferencia mais maiúsculas/minúsculas nem espaços em branco. O claim do tier chega literalmente do JWT ou das informações da conta, e costumava ser comparado ao pé da letra — um único espaço extra bastava para distorcer o veredito.

Quando não resolve, a mensagem diz em qual caso você está

A mesma mudança transformou “por que isso não funcionou” em três frases distintas:

Sua situação	O que você recebe
Você é o tier de convidado anônimo	precisa de uma conta Nous (faça login com /login)
Não há identidade utilizável (você saiu, ou a consulta falhou)	não há identidade Nous utilizável (faça login com /login)
O gateway está inacessível	o Nous Tool Gateway está inacessível

Elas são separadas de propósito, porque correspondem a três ações diferentes: faça login para as duas primeiras, e trate a terceira como um problema de rede ou de serviço que nenhuma quantidade de login vai resolver.

Como verificar na sua própria máquina

• Confira se você não fixou explicitamente outro fornecedor de busca. Assim que web.backend ou web.search_backend nomeia um fornecedor concreto, a decisão é sua e nunca há redirecionamento — isso é um trade-off deliberado. As chaves estão documentadas na referência do hermes config.
• Separe search de extract. Sob web.backend: nous, a busca é servida pelo gateway gerenciado do Perplexity, enquanto o extract continua indo para o Firecrawl; a rota gratuita é só de search, e toda outra rota de fornecedor mantém sua exigência de direito.
• Você não precisa fazer login. A rotação pública sem chave continua disponível para convidados — veja os cinco canais de busca gratuitos e o guia do tier gratuito sem API key; se preferir trazer sua própria chave, isso é abordado no backend de busca Perplexity.
• Veja em qual build você está. A correção foi mesclada na main em 2026-10-01, e a tag mais recente (v0.21.5) é de 24/09, então ela ainda não está na tag. Instalações via git que acompanham a main já a têm.

A conclusão

Isso não era um recurso faltando. Era elegibilidade julgada na dimensão errada: uma rota que nunca verifica seu saldo estava sendo bloqueada por uma lógica que verifica, e os três portões reportavam a mesma frase — então você só conseguia ver “sem direito”, nunca “você nunca precisava de um direito”.

A lição prática é simples. Se a busca te recusa logo depois do login, não vá auditar seus créditos: primeiro confira se você fixou web.backend em algum outro fornecedor, depois leia qual problema de identidade a mensagem realmente nomeia. Acerte a identidade e a busca rápida gratuita será simplesmente gratuita.