Bei einem Nous-Account angemeldet — warum wird die kostenlose Schnellsuche trotzdem verweigert?

Du nimmst den Weg, den die Doku empfiehlt: bei einem Nous-Account anmelden, keinen Drittanbieter-API-Key einfügen und erwarten, dass die Suche einfach funktioniert. Stattdessen bricht die erste Suche mit der Meldung ab, deine Identität sei nicht berechtigt. Nichts ist falsch konfiguriert und dein Konto ist in Ordnung — die Anfrage hat deine Maschine nie verlassen. Sie wurde von einem von drei lokalen Gates gestoppt, und nur eines davon dreht sich tatsächlich um die Berechtigung.
Hier steht, wie die kostenlose Schnellsuch-Route entscheidet, wer sich qualifiziert, warum sie früher registrierte Nutzer aussperrte und wie du erkennst, in welchem Fall du dich jetzt befindest.
Zwei Arten von Route, zwei verschiedene Fragen
Das managed Gateway bedient zwei sehr verschiedene Dinge:
- Abgerechnete Vendor-Integrationen (Extract, Browser, Bilder und so weiter). Sie prüfen, ob du berechtigt bist — bezahlter Portal-Zugang oder ein lebendiger kostenloser Tool-Pool.
- Die Route
search_type: "fast". Das Gateway bedient sie ohne jede Finanzierungsprüfung, deshalb lautet ihre Berechtigungsfrage von Natur aus wer bist du, nicht wie viel hast du bezahlt.
Historisch liefen beide Routen durch einen einzigen Resolver, also wurde die zweite Frage mit dem Lineal der ersten beantwortet. Das ist der ganze Bug.
Die drei Gates, der Reihe nach
Der Fix geht sie in Ausführungsreihenfolge durch, und es lohnt sich, das vollständig zu lesen — denn wenn eines davon nein sagt, siehst du dieselbe Meldung „nicht berechtigt“:
resolve_managed_tool_gateway()wandtemanaged_nous_tools_enabled()(bezahlter Zugang oder ein Konto mit lebendigem Tool-Pool) auf jeden Vendor an — Perplexity eingeschlossen._managed_web_search()meldete nur dann eine managed Route, wenn die Autodetect auf Firecrawl gelandet war und die gegatete „Gateway ist bereit“-Prüfung bestand. Eine nicht berechtigte Identität wurde also gar nicht erst zur Perplexity-Suche aufgelöst.- Der Perplexity-Provider rief denselben gegateten Resolver erneut auf. Deshalb lief selbst das handschriftliche Setzen von
web.backend: nousin dieselbe Verweigerung.
Übereinandergestapelt war der Effekt: Konto registrieren, sehen, dass eine kostenlose Route für dich existiert, und sie trotzdem nie erreichen.
Der Fix: die kostenlose Route nach Identität trennen
PR #130660 lockert nicht das bezahlte Gate. Sie gibt der kostenlosen Route ihr eigenes Lineal:
- Ein neues
resolve_free_search_gateway()löst rein nach Identität auf. - Das neue Prädikat
fast_search_entitled()akzeptiert eine registrierte Portal-Identität beliebiger Stufe — keine Guthaben-Anforderung, keine Tool-Pool-Anforderung. - Abgerechnete Vendors laufen weiterhin exakt wie zuvor durch
resolve_managed_tool_gateway().
Und die Gäste? Bewusst ausgeschlossen. Die kostenlose Route wird pro Identität ausgegeben, und hinter der anonymen Gast-Stufe steht kein Portal-Konto. Gäste sind byte-identisch zu vorher und behalten den keyless Ring. Das ist keine Tür, die sich vor Neulingen schließt — es ist „beweise, wer du bist, und nutze die managed Route; wenn du das nicht kannst, nutze die öffentliche Rotation“.
Zwei Details lohnt es sich, einzeln herauszustellen:
- Ein Fehler schlägt fail-closed fehl, statt zu raten. Ein fehlgeschlagener Account-Lookup wird zu „nicht verfügbar“ aufgelöst. Der kontraintuitive Teil: Ein fehlgeschlagener Lookup wird trotzdem als angemeldet markiert, und nur das Feld
errorunterscheidet ihn von einem echten Konto — dieses Feld ist also tragend und nicht bloß doppelte Absicherung. - Das Stufen-Matching reagiert nicht mehr auf Groß-/Kleinschreibung oder Whitespace. Der Stufen-Claim kommt unverändert aus dem JWT oder den Account-Infos, und er wurde früher wörtlich verglichen — ein einzelnes überflüssiges Leerzeichen reichte, um das Urteil zu verzerren.
Wenn es sich nicht auflöst, sagt dir die Meldung, in welchem Fall du bist
Dieselbe Änderung verwandelte „warum hat das nicht funktioniert“ in drei verschiedene Sätze:
| Deine Situation | Was dir gesagt wird |
|---|---|
| Du bist die anonyme Gast-Stufe | es braucht ein Nous-Konto (anmelden mit /login) |
| Es gibt keine nutzbare Identität (abgemeldet oder Lookup fehlgeschlagen) | es gibt keine nutzbare Nous-Identität (anmelden mit /login) |
| Das Gateway ist nicht erreichbar | das Nous Tool Gateway ist nicht erreichbar |
Sie sind absichtlich getrennt, weil sie auf drei verschiedene Aktionen abbilden: bei den ersten beiden anmelden, und die dritte als Netzwerk- oder Serviceproblem behandeln, das kein noch so häufiges Anmelden behebt.
Wie du es auf deiner eigenen Maschine prüfen kannst
- Stell sicher, dass du nicht explizit einen anderen Such-Vendor gepinnt hast. Sobald
web.backendoderweb.search_backendeinen konkreten Vendor nennen, ist das deine Entscheidung und wird nie umgeleitet — das ist ein bewusster Trade-off. Die Keys sind in der hermes-config-Referenz dokumentiert. - Trenne Suche von Extract. Unter
web.backend: nouswird die Suche vom managed Perplexity-Gateway bedient, während Extract weiterhin an Firecrawl geht; die kostenlose Route gilt nur für die Suche, und jede andere Vendor-Route behält ihre Berechtigungsanforderung. - Du musst dich nicht anmelden. Die öffentliche keyless Rotation gibt es weiterhin für Gäste — siehe die fünf kostenlosen Suchkanäle und den Leitfaden zur kostenlosen Stufe ohne API-Key; wenn du lieber deinen eigenen Key mitbringst, steht das im Perplexity-Suchbackend.
- Prüf, auf welchem Build du bist. Der Fix wurde am 2026-10-01 in
maingemergt, und der neueste Tag (v0.21.5) ist vom 9-24, ist also noch nicht im Tag enthalten. Git-Installationen, diemainfolgen, haben ihn schon.
Das Fazit
Das war kein fehlendes Feature. Es war eine Eignungsprüfung auf der falschen Dimension: Eine Route, die nie dein Guthaben prüft, wurde von einer Logik blockiert, die es tut, und alle drei Gates meldeten denselben Satz — du konntest also nur „nicht berechtigt“ sehen, nie „du hast nie eine Berechtigung gebraucht“.
Die praktische Lehre ist einfach. Wenn die Suche dich direkt nach dem Anmelden abweist, geh nicht dein Guthaben prüfen: Schau zuerst, ob du web.backend auf einen anderen Vendor gepinnt hast, und lies dann, welches Identitätsproblem die Meldung tatsächlich benennt. Bring die Identität in Ordnung, und die kostenlose Schnellsuche ist einfach kostenlos.