[gbrain] ZeroEntropy has been acquired by Notion

[sbaechler]

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.

[sbaechler]

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 openAICompatAsymmetricFetch shim 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.