You take the path the docs recommend: sign in to a Nous account, paste no third-party API key, and expect search to simply work. Instead the first search errors out saying your identity is not entitled. Nothing is misconfigured and your account is fine — the request never left your machine. It was stopped by one of three local gates, and only one of them is actually about entitlement.

Here is how the free fast-search route decides who qualifies, why it used to lock out registered users, and how to tell which case you are in now.

Two kinds of route, two different questions

The managed gateway serves two very different things:

• Billed vendor integrations (extract, browser, images, and so on). These check that you are entitled — paid Portal access, or a live free tool pool.
• The search_type: "fast" route. The gateway serves it without any funding check, so its eligibility question is inherently who are you, not how much have you paid.

Historically both routes went through one resolver, so the second question got answered with the first ruler. That is the whole bug.

The three gates, in order

The fix walks through them in execution order, and it is worth reading in full — because if any one of them says no, you see the same “not entitled” message:

1. resolve_managed_tool_gateway() applied managed_nous_tools_enabled() (paid access, or an account with a live tool pool) to every vendor — Perplexity included.
2. _managed_web_search() only reported a managed route when autodetect had landed on Firecrawl and the gated gateway-readiness probe passed. So an unentitled identity was never resolved to Perplexity search at all.
3. The Perplexity provider called that same gated resolver again. That is why even writing web.backend: nous by hand ran into the same refusal.

Stacked together, the effect was: register an account, watch a free route exist for you, and still never reach it.

The fix: scope the free route by identity

PR #130660 does not loosen the paid gate. It gives the free route its own ruler:

• A new resolve_free_search_gateway() resolves purely on identity.
• The new predicate fast_search_entitled() accepts a registered Portal identity of any tier — no credit requirement, no tool-pool requirement.
• Billed vendors keep going through resolve_managed_tool_gateway() exactly as before.

And the guests? Deliberately excluded. The free route is issued per identity, and the anonymous guest tier has no Portal account behind it. Guests are byte-identical to before and keep the keyless ring. This is not a door closing on newcomers — it is “prove who you are and use the managed route; if you cannot, use the public rotation”.

Two details are worth pulling out on their own:

• A failure fails closed rather than guessing. A failed account lookup resolves to “not available”. The counter-intuitive part: a failed lookup is still stamped as logged in, and only the error field distinguishes it from a real account — so that field is load-bearing, not belt-and-braces.
• Tier matching is no longer case- or whitespace-sensitive. The tier claim arrives verbatim from the JWT or the account info, and it used to be compared literally — one stray space was enough to skew the verdict.

When it does not resolve, the message tells you which case you are in

The same change turned “why did that not work” into three distinct sentences:

Your situation	What you are told
You are the anonymous guest tier	it needs a Nous account (sign in with /login)
There is no usable identity (signed out, or the lookup failed)	there is no usable Nous identity (sign in with /login)
The gateway is unreachable	the Nous Tool Gateway is unreachable

They are separate on purpose, because they map to three different actions: sign in for the first two, and treat the third as a network or service problem that no amount of logging in will fix.

How to check on your own machine

• Make sure you did not explicitly pin a different search vendor. Once web.backend or web.search_backend names a concrete vendor, it is your call and it is never rerouted — that is a deliberate trade-off. The keys are documented in the hermes config reference.
• Separate search from extract. Under web.backend: nous, search is served by the managed Perplexity gateway while extract still goes to Firecrawl; the free-of-charge route is search-only, and every other vendor route keeps its entitlement requirement.
• You do not have to sign in. The public keyless rotation is still there for guests — see the five free search channels and the no-API-key free tier guide; if you would rather bring your own key, that is covered in the Perplexity search backend.
• Check which build you are on. The fix merged into main on 2026-10-01, and the newest tag (v0.21.5) is dated 9-24, so it is not in the tag yet. Git installs tracking main already have it.

The takeaway

This was not a missing feature. It was eligibility judged on the wrong dimension: a route that never checks your balance was being blocked by logic that does, and all three gates reported the same sentence — so all you could see was “not entitled”, never “you were never supposed to need an entitlement”.

The practical lesson is simple. If search refuses you right after signing in, do not go audit your credits: first check whether you pinned web.backend to some other vendor, then read which identity problem the message actually names. Get the identity right and free fast search is just free.