mobilebytesensei/betterflow-english-streaming-transducer
betterflow — English streaming transducer (sherpa-onnx) — MIRROR of a deleted upstream artefact
⛔ NON-COMMERCIAL USE ONLY. Read the Licence section before you do anything with these files. betterflow does not license this model and cannot grant you rights to it. These bytes are Banafo's.
Streaming zipformer2 transducer exported to ONNX for on-device dictation. Emits partials DURING speech, so first-partial latency is constant rather than proportional to utterance length — the property batch whisper structurally lacks.
- encoder.int8.onnx (65.7 MB) + decoder.onnx (0.59 MB) + joiner.onnx (0.32 MB) + tokens.txt (652 lines) — 66.59 MB total
- Load with sherpa-onnx
OnlineRecognizer.from_transducer,model_type="zipformer2" - Encoder architecture:
num_encoder_layers = 2,2,3,4,3,2,encoder_dims = 192,256,384,512,384,256
Provenance — exactly which files these are
Origin: [Banafo](https://huggingface.co/Banafo) / [Kroko-ASR](https://huggingface.co/Banafo/Kroko-ASR). All credit for these weights belongs to Banafo; betterflow trained nothing here.
decoder.onnx, joiner.onnx and tokens.txt are byte-identical to Banafo's own en_decoder.onnx, en_joiner.onnx and en_tokens.txt. encoder.int8.onnx is Banafo's en_encoder.onnx with the encoder's Conv nodes dynamically quantized to int8 (see below); nothing else was changed.
Those four files were present on Banafo/Kroko-ASR at every revision from abf40825c0e1 (2025-01-29) through 76e3e6657fc6 (2025-09-29), and were deleted from upstream on 2025-10-06, commit d45212aeb212, titled verbatim: `Remove old format models`.
‼️ This repository is a MIRROR, and that is the whole reason it exists
The upstream files are gone. This repository exists so that betterflow's published measurements remain reproducible — a number is not reproducible if the bytes it was measured on cannot be fetched. It is not a redistribution channel, not a relicensing, and not an endorsement of any particular downstream use.
If you want these weights for your own purposes, go to Banafo, not to us. If Banafo asks us to take this down, we will.
Licence — non-commercial only, quoted from upstream
Banafo has never published a completed licence for these .onnx files. The LICENSE file on Banafo/Kroko-ASR is zero bytes at every revision that carried them, and the HF metadata reads license: other / license_name: test. What upstream did write, verbatim:
From https://huggingface.co/Banafo/Kroko-ASR/raw/4ade2288b485/README.md (commit 4ade2288b485, 2025-09-25) — the only statement upstream has made that distinguishes the two artefact families:
( update september 2025 - CC-BY-SA models were just uploaded, the new ones (with .data extension ) are CC-BY-SA licensed, the .onnx are still non-commercial only. Github and readme updates coming soon. )
And the ## License section, identical at every revision that carried these files (fa401e5ab9b4, 933859c3057c, c683ee760ec7, 4ade2288b485), verbatim:
## License The license is still under consideration (likely Coqui). The model is intended to be dual-licensed: - Free for non-commercial use. - Affordable license for commercial use.
‼️ These files are not CC-BY-SA. Do not let anyone tell you otherwise.
The CC-BY-SA statement on Banafo's current model card is about the `.data` models (Kroko-<LANG>-Community-{64,128}-L-Streaming-001.data, ~155.8 MB each). It is not about these .onnx files. betterflow's own records asserted CC-BY-SA for these bytes for two days and were wrong; the correction is recorded in ml/data/runs/2026-08-06-kroko-licence.md in the betterflow repo. The licence above — "still under consideration", "non-commercial only" — is the accurate one.
For commercial use, contact Banafo. We cannot sell, sublicense, or grant what we do not hold.
‼️ tokens.txt has 652 lines. That is CORRECT for this encoder.
There are 650-line English token files in circulation (two variants, 6,218 B and 6,296 B). They belong to a different model — the .data Community model, whose encoder is num_encoder_layers = 2,2,4,5,4,2 / encoder_dims = 192,256,512,768,512,256 against this one's 2,2,3,4,3,2 / 192,256,384,512,384,256. Never pair a 650-line file with this encoder. The 652-line file here is Banafo's own en_tokens.txt, hash 396dbeb5…, and it is the only correct pairing.
The trap runs both ways: a copy of this 652-line file also sits inside the .data model's directory tree, where it is equally wrong. Match tokens to the encoder by architecture, not by directory.
A mismatched token file does not raise: it decodes confident, fluent-looking nonsense.
tokens.txt carries no sentence punctuation. Punctuation is a downstream text-cleanup responsibility, not a model one.
‼️ Only the ENCODER is int8-quantized. That is deliberate.
decoder.onnx and joiner.onnx are shipped as Banafo published them, in fp32. Quantizing them as well produces degenerate repetitive output: they are sub-megabyte networks with almost no weights to quantize, and they sit inside the autoregressive loop where error compounds token over token. This matches the sherpa-onnx zoo convention.
‼️ If the fp32 encoder fails on macOS, that is your ONNX Runtime, not this model
Save yourself the two days we spent. macOS arm64 ONNX Runtime 1.27.0 miscomputes fp32 `Conv` in a streaming zipformer2 encoder. The sherpa_onnx 1.13.4 macOS pip wheel vendors its own `libonnxruntime.1.27.0.dylib`, so you hit this even if you have a newer onnxruntime installed — sherpa never loads yours.
The failure does not raise. It returns a short, plausible, non-empty string ('Oh,' for eleven seconds of clean English) and it is not deterministic: six runs at dither=0.0, num_threads=1, identical bytes, gave three different transcripts. That is what reading uninitialized memory looks like.
Two independent fixes, each sufficient:
- Use ONNX Runtime 1.28.0 — it executes the unmodified fp32 graph correctly.
- Quantize the `Conv` nodes — which is what
encoder.int8.onnxhere already does. Converting a single node,/conv/conv.0/Conv(the first Conv2d of the subsampling front-end), is enough to restore the complete correct transcript.
`encoder.int8.onnx` in this repository carries ZERO fp32 `Conv` nodes (70 ConvInteger), so it is clear of this trap and decodes correctly on macOS arm64 and Android alike. The mechanical check:
python -c "import onnx,sys;from collections import Counter; \
print(Counter(n.op_type for n in onnx.load(sys.argv[1],load_external_data=False).graph.node)['Conv'])" encoder.int8.onnx
# -> 0The full diagnosis, including the 2×2 that isolates it to the ORT version, is in ml/data/runs/2026-08-06-macos-harness-diagnosis.md in the betterflow repo.
Measured — with the subject stated
Every number below names the model, the machine, the corpus and n, because a number without its subject is not a measurement.
Gate-4 decode, verbatim, 2026-08-07:
0.wav : Ask not what your country can do for you. Ask what you can do for your country
jfk.wav : and saw my fellow Americans ask not what your country can do for you ask what you can do for your country‼️ 5.6% is a FLOOR, not a promise
librispeech-en is read audiobook English: clean, close-mic, scripted, largely US-accented, no code-switching, no disfluency. It is the easy case for an English ASR model. Treat 5.6% as the best this bundle will ever look.
Unmeasured, and do not extrapolate to any of it: conversational or spontaneous speech; non-US/UK accents, including Indian English; noisy or far-field audio; code-switched English–Indic speech; domain vocabulary; first-partial latency on device; and WER at any n larger than 30.
Verification
Verified before hosting with ml/export/verify_streaming_bundle.py (betterflow repo) on sherpa-onnx 1.13.4 — the version vendored in the betterflow client, so this exercises the engine that actually ships. Gate 4 passed at 99% latin script; the fp32-vs-int8 CER printed alongside it is meaningless here because the fp32 baseline is the macOS Conv defect described above, not a functioning reference.
There is no fp32-vs-int8 quality comparison for this bundle, and there cannot be one on macOS until sherpa ships a wheel built against ORT ≥ 1.28.
Citation / attribution
If you use these weights, attribute Banafo — Kroko-ASR (https://huggingface.co/Banafo/Kroko-ASR). The int8 quantization and this mirror are betterflow's only contribution.