Default reranker zeroentropyai:zerank-2 is being sunset 2026-09-04 — new signups already disabled

Summary

DEFAULT_RERANKER_MODEL is zeroentropyai:zerank-2. ZeroEntropy has been acquired by Notion and is shutting down:

"All ZeroEntropy products will remain fully supported until September 4th, 2026 with no degradation, after which they will be sunset. We have disabled new signups, and encourage existing customers to migrate away from ZeroEntropy products." — ZeroEntropy Joins Notion

The signup half is what makes this urgent rather than a September problem. A new user who enables reranking today has no reachable provider and no way to obtain one — ZeroEntropy is the only hosted provider in the recipe registry that declares a reranker touchpoint, and its dashboard no longer accepts new accounts. The failure is a silent fail-open: search returns un-reranked results and logs a warning.

Where it's pinned

• src/core/ai/gateway.ts — const DEFAULT_RERANKER_MODEL = 'zeroentropyai:zerank-2'
• src/core/search/mode.ts — reranker_model: 'zeroentropyai:zerank-2' hardcoded in three mode bundles (~lines 297, 347, 402), so setting search.reranker.model isn't obviously sufficient depending on which bundle is canonical

Of the recipes that declare a reranker touchpoint (zeroentropyai, dashscope-rerank, llama-server-reranker, openrouter), only ZeroEntropy is a general-purpose hosted option; the others are region-specific, self-hosted, or a gateway.

Why this went unnoticed for a while (possibly worth a separate fix)

gbrain models doctor could not have told anyone. probeModel() in src/commands/models.ts calls chat({ ..., maxTokens: 1 }), and OpenAI rejects max_output_tokens below 16:

Invalid 'max_output_tokens': integer below minimum value. Expected a value >= 16, but got 1 instead.

So the probe failed on every OpenAI chat/expansion model regardless of reachability, and a genuinely dead provider was indistinguishable from the noise. On our install this masked ~960 reranker auth failures over 7 days. Changing maxTokens: 1 → 16 makes the check meaningful again (4/6 → 6/6 here, with the one real failure correctly isolated).

Proposed fix

Add Voyage as a hosted reranker. The wire difference is small and gateway.rerank() already anticipates it in a comment:

"any provider whose request/response shape differs from ZE/llama.cpp (e.g. Voyage with top_k / data[]) needs separate adapter hooks in a follow-up plan."

Two deltas: the request truncation field is top_k rather than top_n, and the scored list arrives under data[] rather than results[]. Element shape ({index, relevance_score}) is identical.

Rather than branching on recipe.id, declare it on the touchpoint next to the existing path field:

reranker: {
  models: ['rerank-2.5', 'rerank-2.5-lite', 'rerank-2', 'rerank-2-lite'],
  default_model: 'rerank-2.5',
  path: '/rerank',
  top_param: 'top_k',    // defaults to 'top_n'
  results_key: 'data',
  max_payload_bytes: 5_000_000,
}

gateway.rerank() then reads tp.top_param ?? 'top_n' and accepts either array key. Under this, Cohere rerank-v3.5 needs no gateway change at all — it already uses top_n and results[], so it's a recipe file plus a touchpoint declaration.

Also worth noting for anyone migrating: ZeroEntropy relicensed its models to Apache 2.0 (zerank-2-reranker, zerank-1-reranker, zerank-1-small-reranker, zembed-1-embedding on HuggingFace under zeroentropy), so self-hosting the same weights is a valid path for users who want identical scores. Their migration guide has Baseten/Modal recipes.

Verification

Running the above locally against a 55k-page brain on v0.42.66.0:

• gbrain models doctor: 6/6 reachable (was 4/6)
• Query "who manages Diedrick Brackens studio" — before reranking, the correct answer (the artist's studio manager) was outside the top 5; after, the artist ranks 1st and the studio manager 2nd
• Zero ZeroEntropy calls after switching

Happy to open a PR with both changes (the probe floor and the Voyage touchpoint + recipe-declared adapter) if useful — they're independent and could land separately.