Texo: the only comparable row in its own results table is the one that scores best, and the transfer model is explicitly not comparable

The footnotes say the two variants cannot be compared

The results table has four rows and two of them are Texo. A marker attaches to each, and the notes underneath explain what they mean. The distilled variant uses the same tokenizer as the two published models it is compared against, so its sequence metrics are described as strictly comparable. The transfer variant uses a customised tokenizer with a shorter sequence length, and the note says in plain words that its metrics are not comparable. A second marker records that its parameter count is slightly lower than the distilled variant because the tokenizer vocabulary is smaller, which means even the twenty million figure is not the same measurement in both rows. So the row that looks worse on every metric is the row the page itself disqualifies.

It wins one of the four metrics and loses the other three

Read the two numeric rows for Texo against the baseline row they came from. On the sequence metric, the baseline scores higher on three of the four subtasks and lower on one, and the edit distances agree: lower is better there, and the distilled variant is worse on three and better on the fourth. The improvement is concentrated in the same subtask in both metrics, which is what a genuine capability gain looks like, and the losses are spread across the other three. The claim in the surrounding text is comparable performance while reducing parameters a lot, which the numbers support as a description of a trade rather than as a result. Nothing in the table measures latency, memory or robustness on images outside the test set.

The baseline column only lists the small variant of each family

A sentence explains the composition of the table: only the lightweight version of each state-of-the-art model is listed. So the two reference points are the smallest published member of their families, not their best. That is the right choice if the argument is that a small model can match a small model, and it is not the same claim as matching the field. The other baseline row is also nearly empty. Four of its cells are dashes, and the note says a dash means the figure was not reported in that paper, which leaves one sequence score and nothing else for that model. Any comparison a reader draws from that row rests on a single number.

Consumer graphics card, or sixteen gigabytes of video memory

One feature bullet says the model is trainable on a consumer level graphics card. Three lines further down, the training requirements list three tiers. The strongest asks for fifty gigabytes of system memory and a forty-six gigabyte accelerator of a named professional kind. The recommended tier asks for fifty gigabytes of system memory and forty gigabytes of video memory. The minimum asks for twenty gigabytes of system memory with streaming data loading, and sixteen gigabytes of video memory with accumulated gradients. So the smallest configuration that trains the model needs more video memory than any consumer card shipped in most of the last decade. The bullet is not describing this repository's training script; it is describing what the architecture can be made to fit.

Every install resolves through a university package mirror

The setup instruction is two commands: clone, then sync the environment.

git clone https://github.com/alephpi/Texo
uv sync

The sync step is driven by the project file, and that file sets the package index to a university mirror hosted in China rather than the public index. A lock file is committed at the root, so installs are reproducible in the sense that the same versions arrive every time, and reproducible in the sense that they arrive from wherever the mirror currently serves. The mirror setting sits above a workspace section and a sources section, so it is a deliberate project-wide choice rather than a leftover. Anyone outside that network gets a slower resolve, and anyone who cares which host served a wheel has one place to look.

The package metadata still carries a template description

The project file names the package, sets a version at the initial release number, and then describes it in four words that are a placeholder from a scaffolding tool: add your description here. The build backend is set up to package one source directory, and the development dependency group contains the package itself, resolved to the workspace root, which is how the tooling lets a project depend on its own module. Three dependencies are pinned to an exact version, including the two that matter most for reproducibility, while the rest carry floors. The image runtime for graphics acceleration and the export tooling are both in the runtime list rather than in optional extras, so a machine with no accelerator still installs them.

The exported model scores lower and the table does not say why

The final row of the results table is the exported model in a portable runtime format, and it is lower than the same-named variant above it on three of the four sequence scores and matches it on one. Edit distances are mixed in the same way, better on one subtask and worse on three. The row carries a marker pointing back to the entry above, so the parameter count is understood to be identical. There is no note explaining the gap. If the export runs at reduced precision, that is the usual reason, and if it does not, the difference is worth chasing before anyone builds on the portable artefact instead of the checkpoint.

The weights come from a script inside the repository

There is no release on this repository and no registry install for the model itself. Weights arrive by running a Python script in the repository's own scripts directory against the model hub, with a bare invocation for the model alone and a second flag for people who intend to train from useful intermediate checkpoints. That is a reasonable choice for a research artefact and it means the download path is code you can read rather than a documented command from a third party tool. The browser version lives in a separate repository, and the demonstration notebook at the root is where inference is meant to be tried. Training itself is configured through a composition library with separate configs for a debug run and for a cluster launcher, and the training results are written to a directory at the root that is meant to be read with a tensor board rather than a notebook.

Editorial conclusion

Use Texo if you want a small formula recogniser you can read, train and reproduce, and if a couple of BLEU points of sequence accuracy will not decide your project. Five things to know first. The two variants in the results table are not interchangeable: the distilled one shares a tokenizer with the models it is compared against, the transfer one does not, and the page says so in a footnote. The comparison set is also the smallest published variant of each rival family, which is a fair choice and not the same as a fair fight. The consumer GPU claim is a stretch against a requirements list that starts at sixteen gigabytes of video memory and fifty gigabytes of system memory. The install path resolves packages through a university mirror rather than the public index, so review what your lock file points at before you rely on it. And the model is distilled from one published system, fine-tuned on another's dataset, and built on a third project's architecture, weights and image processor, so an AGPL licence sits on top of a stack that was not written here.

Frequently asked questions

Official sources

1. alephpi/Texo on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README