The Biocentral backend cannot serve ESMC correctly — biotrainer's generic loader substring-matches esm in ESMplusplus and returns EsmTokenizer/EsmModel, so the request succeeds and returns vectors from the wrong architecture. A one-off parity check on 25 sequences measured cosine 0.022 against the local backend, where ProtT5, ProstT5, ESM-2, Ankh and Ankh3 all came back at >= 0.99987.
The problem is that the three entry points disagree about it:
- The Colab notebook refuses it. It disables the checkboxes and drops the embedder at Generate, using
BIOCENTRAL_INVALID.
- The CLI accepts it silently.
protspace embed --backend biocentral -e esmc_300m and the equivalent prepare invocation run to completion and write the bad vectors. data/embedding/biocentral.py says so in its own comment: "Declared, not enforced: the CLI still accepts the combination, and the Colab notebook is what refuses it."
- Nothing warns the user who takes the CLI path, and the resulting HDF5 is indistinguishable from a good one.
Two things would help:
- Enforce the gate where it is declared.
BIOCENTRAL_INVALID already exists in the package; having embed/prepare fail fast on it (or fall back to the local backend with a warning) would make the three surfaces agree.
- File it upstream. I could not find any issue mentioning
esmc in biocentral/biotrainer, and there is no ESMC embedder file in that repo at HEAD, so as far as I can tell the maintainers there have never been told. Until that lands, the gate is the only protection.
Worth noting for whoever picks this up: the 2026-07-16 parity script that measured the 0.022 was never committed, and the plan document recording the result was untracked by 69a5376. The finding is real but is not currently reproducible from the repo — re-measuring it is probably the first step.
Context: found while fact-checking the manuscript's Methods section, which had been describing the mismatch in print.
The Biocentral backend cannot serve ESMC correctly — biotrainer's generic loader substring-matches
esminESMplusplusand returnsEsmTokenizer/EsmModel, so the request succeeds and returns vectors from the wrong architecture. A one-off parity check on 25 sequences measured cosine 0.022 against the local backend, where ProtT5, ProstT5, ESM-2, Ankh and Ankh3 all came back at >= 0.99987.The problem is that the three entry points disagree about it:
BIOCENTRAL_INVALID.protspace embed --backend biocentral -e esmc_300mand the equivalentprepareinvocation run to completion and write the bad vectors.data/embedding/biocentral.pysays so in its own comment: "Declared, not enforced: the CLI still accepts the combination, and the Colab notebook is what refuses it."Two things would help:
BIOCENTRAL_INVALIDalready exists in the package; havingembed/preparefail fast on it (or fall back to the local backend with a warning) would make the three surfaces agree.esmcinbiocentral/biotrainer, and there is no ESMC embedder file in that repo at HEAD, so as far as I can tell the maintainers there have never been told. Until that lands, the gate is the only protection.Worth noting for whoever picks this up: the 2026-07-16 parity script that measured the 0.022 was never committed, and the plan document recording the result was untracked by 69a5376. The finding is real but is not currently reproducible from the repo — re-measuring it is probably the first step.
Context: found while fact-checking the manuscript's Methods section, which had been describing the mismatch in print.