Repository navigation
[gbrain] ZeroEntropy has been acquired by Notion #2365
Description
gbrain uses a ZeroEntropy API key by default. It looks like that API has been sunsetted and new signups have been disabled.
From their blog post:
ZeroEntropy has been acquired by Notion. The whole team is joining to keep making Notion AI more useful and efficient.
All of our models are now fully open-source under Apache 2.0.
All ZeroEntropy products remain fully supported until September 4th, 2026, after which they will be sunset. New signups are disabled.
Existing customers should follow our migration guide.
The embedding model is only 4B and can now be self hosted (e.g. using oMLX on Mac).
https://huggingface.co/zeroentropy/zembed-1-embedding
The catch: the existing zeroentropyai recipe (~/gbrain/src/core/ai/recipes/zeroentropyai.ts) isn't a generic "call this model" wrapper — it's wired to ZeroEntropy's specific non-standard API shape. gbrain's gateway has a dedicated zeroEntropyCompatFetch shim (gateway.ts:987) that rewrites the request path to /models/embed and reshapes the response from {results:[{embedding}]} into the OpenAI-standard {data:[{embedding,index}]} the AI SDK expects. That shim only fires for recipe.id === 'zeroentropyai'.
Please improve support for ZeroEntropy from different providers.
Activity
sbaechler commentedon Jul 27, 2026
Actually, oMLX currently does not support the asymmetric encoding that zembed-1 uses. Self hosting this model using oMLX does not use its full potential yet.
There is an
openAICompatAsymmetricFetchshim specifically built for "zembed-1 behind llama.cpp, vLLM, or an OpenAI-compatible proxy" (its own comment names this exact case). But it only knows one mechanism: injecting an input_type field into the JSON request body — the ZeroEntropy/Voyage API convention.zembed-1's real asymmetric mechanism is a chat-template text prefix ("<|im_start|>system\nquery<|im_end|>\n..." vs "...\ndocument<|im_end|>\n..."), applied to the raw input string — not a JSON field.
oMLX's embeddings endpoint has no input_type field in its schema and does zero prefix injection — it ignores unknown JSON keys and passes text through byte-identical.
So gbrain's built-in shim would dutifully inject input_type: "query" into the request body on every embedQuery() call — and oMLX would silently ignore it, same as our manual curl test. Wiring up the llama-server recipe as planned would not actually fix the asymmetric problem — it would produce the same symmetric-only result, just via a different (still-broken) code path than doing nothing.
fix(setup-gbrain): warn about the ZeroEntropy sunset before Sept 4
garrytan commentedon Aug 22, 2026
gstack-side shipped in v1.69.0.0 (PR #2666): the wireup warns when ~/.gbrain/config.json names the zeroentropyai recipe (fail-open grep — a missing, unreadable, or other-provider config stays silent and never blocks a setup), setup-gbrain provider comments say never to select the legacy recipe for a new brain, and USING_GBRAIN_WITH_GSTACK.md documents the Sept 4 deadline + migration options. Leaving open for the gbrain-side migration (the recipe + zeroEntropyCompatFetch shim, and the oMLX asymmetric-encoding caveat raised above).
v1.69.0.0 fix: the silent-failure wave — 6 fixes, 5 community PRs abs…