# Desert Ant Labs: real wins, missing metrics > Satyajit Ghana — Head of Engineering @ Inkers Technology > canonical: https://ai.thesatyajit.com/articles/desert-ant-labs > date: 2026-09-09 > tags: on-device, small-models, speech-recognition, quantization, licensing, benchmarks Desert Ant Labs launched on September 8 with a blog post, seventeen Hugging Face repos, and a line that is easy to write and hard to earn: "So, we trained the models ourselves." The post, by co-founder Paul Veugen, frames the company as a "European frontier AI lab" building the opposite of a frontier model — one task, one small checkpoint, running entirely on a phone, for free below 100,000 monthly active devices. It backs that up with four head-to-head comparisons, each naming a competitor and a size: a 2MB language detector against a 293MB one, a 12MB PII filter against a 2.3GB one, a 9MB audio cleaner claimed to beat Dolby, and a 284MB clip-selector claimed to match Claude Sonnet at a tenth of the latency and 470 times less energy. Every one of those claims names a number, which makes every one of them checkable. So this article checks them — against the Hugging Face repos (`desert-ant-labs/*`), their `config.json` and `README.md` files, the SDK's own docs on GitHub, and the company's `/about` page, which turns out to carry the one footnote the blog post doesn't. The short version: most of the individual size-vs-quality comparisons hold up, on their own stated terms. The launch's two biggest claims — replacing Claude Sonnet, replacing Dolby — do not, by the company's own later admission. And "we trained the models ourselves" is true of exactly one of the models this article traced in detail, and a looser kind of true for the rest. ## Eighteen models, one license The family is bigger than the four headline comparisons. Eighteen models total, twelve stable and six in closed beta, covering speech (`voz` transcription, `clear` enhancement, `align` forced alignment, `ear` spoken-language ID, `uhm` filler-word detection, `who` speaker labeling), text (`redact` PII, `tongue` and `emo` for language ID and emoji, `gist` topic tagging, `title` titles/descriptions, `toxic` hate-speech, `schemer` structured extraction), and vision (`shapes` sketch recognition, `moderator` NSFW detection, plus beta `eye` and `face`). One Swift/Kotlin/JavaScript SDK, one Core ML/LiteRT/ONNX/MLX release matrix depending on the model, and — per the launch post — every model started life the same way: Desert Ant's five-year-old video app, `Detail`, needed a feature, an API call got expensive, and Veugen went looking on Hugging Face for something small enough to ship instead. The license underneath all of it is the [Desert Ant Labs Source-Available License v1.0](https://license.desertant.com/1.0), and "source-available" is doing real work in that name — it is explicitly not open source, and the licence says so in its own section 19, written for agents integrating the SDK. The practical terms: - **Free below 100,000 monthly active devices, per platform, per model.** iOS and Android each get their own 100k allowance for the same model; different models don't share a pool. Above that, a commercial licence is required. - **A non-compete on training data.** You may not use the models, their outputs, or anything you log from them — "including embeddings and evaluations" — to train, fine-tune, or distil a competing on-device model. This is the clause worth reading twice: benchmarking is explicitly permitted, ordinary product logging is explicitly permitted, but bulk-logging outputs to build a dataset is "the same breach" as training on the weights directly. - **No redistribution, no weight extraction.** You can't ship the models as a standalone product, and you agree not to attempt distillation attacks or weight recovery. - **Audit rights and required telemetry.** Desert Ant can fingerprint outputs and audit compliance once a year (or on suspicion of a violation); the SDK sends a device identifier solely to count monthly active devices, and the licence is explicit that this telemetry carries no user content. - **Attribution.** A "Powered by Desert Ant Labs" line somewhere a user can find it, linked where the medium allows. None of this is unusual for a company selling a freemium SDK — it reads like a well-lawyered version of the licences several audio and vision "edge AI" vendors already ship. But it is a genuinely different thing from the permissive licences (Apache 2.0, MIT, CC BY 4.0) that show up throughout this article as the licences on the *upstream* models Desert Ant built several of these on top of. "On-device" and "open" are not the same claim, and the sovereignty framing in the launch post — "what's never been uploaded can never be compelled" — is a real property of on-device inference. It is not a property of this particular licence, which is closer to source-available middleware than to a model you can fork. ## "We trained the models ourselves" — checked against seventeen `config.json` files The strongest test of that sentence is the models' own metadata: `cardData.base_model`, the "Built on" section every model page carries (or doesn't), and `config.json`'s architecture fields, which don't editorialize. Four of these are worth walking through in the model's own words, because the phrasing is precise about what "built on" means each time. **`voz`**, the flagship transcription model, is the clearest case: "[Parakeet TDT 0.6B v3](https://huggingface.co/nvidia/parakeet-tdt-0.6b-v3) — NVIDIA (CC BY 4.0): the base recogniser, converted to Core ML and compressed for this export. **Weight values are otherwise unchanged.**" That is not fine-tuning language. It's conversion-and-quantization language. The transducer that turns audio into words on your phone is NVIDIA's, verbatim; what Desert Ant built is the Core ML export, the windowing-and-stitching logic for long audio, and the Swift runtime that keeps the whole graph resident on the Neural Engine. **`title`** names its base directly too: "[`ibm-granite/granite-4.0-350m`](https://huggingface.co/ibm-granite/granite-4.0-350m), the base model this is fine-tuned from." The repo's own `config.json` corroborates it independently of the README's claim: ```json // desert-ant-labs/title/config.json { "architectures": ["GraniteMoeHybridForCausalLM"], "hidden_size": 1024, "num_hidden_layers": 28, "num_local_experts": 0, "num_experts_per_tok": 0, "model_type": "granitemoehybrid", "quantization_config": { "group_size": 64, "bits": 6, "mode": "affine" } } ``` `GraniteMoeHybridForCausalLM` is IBM's architecture class name, and `num_local_experts: 0` means the "MoE" in that class name is switched off here — this is the dense hybrid attention/Mamba variant, not a routed mixture. The repo's own `model.safetensors.index.json` reports `"total_parameters": 352379904` — 352.4M, matching Granite's own 350M nearly exactly, which is what you'd expect from a fine-tune that changed weights, not shape. At 6-bit (`bits: 6`), 352.4M params should occupy roughly 352.4M × 0.75 bytes ≈ 264MB before overhead; the repo's actual on-disk size is 286.4MB, comfortably in the range 6-bit quantization plus per-block scales and biases predicts. The arithmetic and the "fine-tuned from Granite" claim agree with each other. **`clips`** and **`redact`** are the same pattern at different scales. Clips' README: "One xlm-roberta-base trunk, 278M parameters, carrying four heads" — [FacebookAI/xlm-roberta-base](https://huggingface.co/FacebookAI/xlm-roberta-base) (MIT) reused whole, with four new heads (saliency, clip-start, clip-end, scorer) trained on top. Redact's encoder is "Multilingual-MiniLM (XLM-R lineage) truncated to 6 layers... fine-tuned for BIOES tagging" — and `toxic`'s own `config.json` states its base in a literal field: `"base": "xlm-roberta-base"`, with `toxic-en`'s reading `"base": "microsoft/Multilingual-MiniLM-L12-H384"`. The one model that does read as trained from scratch is `tongue`, covered in its own section below. `emo` sits in the middle: its lexical n-gram stream and its two-layer transformer head are original, but the model's cross-lingual generalization comes from `minishlab/potion-multilingual-128M`, a static embedding table itself distilled (via Model2Vec) from `BAAI/bge-m3` — PCA-reduced and vocabulary-pruned for `emo`'s 22 languages, but not trained by Desert Ant. `clear` is the one card that names no base at all; the tags list `deepfilternet`, and the keyword block includes `DFN3` and "distilled model," which is enough to infer a DeepFilterNet lineage without a formal citation anywhere on the page. None of this makes the release dishonest. Converting Parakeet to run entirely on the Neural Engine with a stitching algorithm for long audio, or building a deterministic BIOES-reconciliation layer with checksum validation for 24 EU countries' national ID formats on top of a truncated MiniLM, is real, specific engineering — the kind that doesn't show up in a parameter count. But "we trained the models ourselves," read as a sentence about where the weights came from, is true for one model out of the nine this article traced a lineage for, and a fair reading of the other eight is "we adapted, quantized, or partly retrained models that already existed." ## Voz: 4.7x faster than Whisper, or 6.4x, depending which one The launch post's opening claim is "transcribe 10 minutes of audio in two seconds on an iPhone — 4.7x faster than Whisper." Voz's own model page resolves the ambiguity the blog post leaves in: it's "4.7x faster than whisper.cpp large-v3-turbo on the same podcast audio," on a Mac. That's a specific, checkable comparison — whisper.cpp is a real, widely-used C++ inference runtime, and large-v3-turbo is a real, named checkpoint. It is also a different comparison from the one three paragraphs later in the same blog post: | | realtime factor, 30 min continuous audio, M3 Ultra | |---|---:| | **Voz** | **319x** | | Apple SpeechAnalyzer | 78x | | Whisper large-v3-turbo | 50x | 319 ÷ 50 is 6.4x, not 4.7x. Both numbers are real and both are Desert Ant's own, but they're not the same benchmark: the opening line is a short podcast clip on an unspecified iPhone against whisper.cpp specifically; the chart is 30 continuous minutes on a Mac Studio chip against an unspecified Whisper runtime (the model card's Whisper *accuracy* numbers, below, come from the Open ASR Leaderboard, which does not run whisper.cpp — so the 50x figure in this chart is measuring something the WER table doesn't). A reader who only saw the headline would reasonably assume one number describes both. Where Voz's own model card is genuinely good practice: publishing word error rate at all, on the actual competitor's actual leaderboard, is the column most on-device speed comparisons skip. | dataset | Voz WER | Whisper large-v3-turbo WER | |---|---:|---:| | LibriSpeech test-clean | 2.19% | 2.13% | | LibriSpeech test-other | 3.86% | 3.70% | | GigaSpeech | 9.70% | 8.47% | | SPGISpeech | 3.86% | 2.79% | | Earnings-22 | 12.97% | 11.07% | | AMI (meetings) | 11.84% | **13.87%** | | **average** | **7.40%** | **7.00%** | Whisper large-v3-turbo is ahead on four of six sets and on the average — 0.4 points of WER, which the card itself calls "close" rather than papering over. Voz wins on AMI, the one meetings dataset, by two points, and the card is upfront that meetings and podcasts are the conversational material most people actually want transcribed, while LibriSpeech (2% WER either way) is the easiest and least representative set in the table. Voz does this in 467MB entirely on the Apple Neural Engine; Whisper large-v3-turbo is 1.6GB and needs a GPU or a lot of patience on CPU. Reported disk size and Hugging Face's own `usedStorage` for the repo (487.9MB by the Hub's decimal accounting) round to the same number, so at least the size claim isn't a MiB/MB sleight of hand — a distinction [this site has been burned by before](/articles/minicpm5-2b). Word timestamps get their own honest caveat: starts land within 83ms and ends within 95ms of a forced aligner on average, but the card says outright that ends are "the harder half" because the model reports how far to skip after a token rather than where the word actually stops. And the per-language table — ten minutes of concatenated FLEURS audio per language — spans Italian at 3.31% WER to Greek at 39.46%, with the card telling you plainly to read the spread before shipping a language, not just the "25 languages" count on the box. ## Redact: the PII filter that also publishes precision Automatic PII redaction has a well-known failure mode: a system can drive recall arbitrarily high by masking anything that resembles a name, at the cost of mangling ordinary text. The tell is a benchmark that reports recall and stops. Redact's own README doesn't stop there: | System | Recall | Precision | Size | Params | |---|---:|---:|---:|---:| | **redact** | **88.8** | **99.6** | **11.6MB** | **23M** | | GLiNER-PII | 91.1 | 90.4 | 2.3GB | 570M | | Rampart | 61.4 | 97.2 | 14.7MB | 18.5M | | OpenAI privacy filter | 60.2 | 93.5 | 3GB | 1.5B | The launch post's framing — "catches 88.8% of the personal data... close to the 2.3GB GLiNER-PII" — quotes the number that makes redact look like it's giving something up. The fuller table says the opposite is also true: redact's precision (99.6) is nine points *above* GLiNER-PII's (90.4). Recall is "the share of personal data fully masked, macro-averaged over WikiANN, MultiNERD, and a format-valid structured-PII set across 24 EU languages"; precision is "the share of masked spans that were really personal data, on the structured set" — different denominators for each column, stated in the card, which is more disclosure than this comparison usually gets. The size gap is real but isn't purely an architecture story. GLiNER-PII's own numbers imply fp32 weights (570M params × 4 bytes ≈ 2.28GB, matching the stated 2.3GB almost exactly); redact's Apple build is 4-bit (23M params × 0.5 bytes ≈ 11.5MB, matching its stated 11.6MB just as closely). Of the resulting 198x size gap, roughly 25x comes from having a quarter as many parameters, and the remaining ~8x comes from shipping at 4-bit against a competitor's fp32 — a fair comparison of *deployed artifact size*, since that's genuinely what ships, but not entirely a comparison of *model efficiency*, since a 4-bit GLiNER-PII would close most of that second factor. The one column Redact's table doesn't have a peer for: AWS Comprehend's PII API only accepts English, so it's scored separately rather than folded into the 27-language table. On English names specifically, Comprehend leads (84.3 vs. redact's 69.5 on WikiANN); redact still wins on the format-valid structured set (95.0 vs. 91.9). Comprehend also runs in the cloud, bills per call, and covers one of redact's 27 languages. Redact's `config.json` lists the taxonomy as BIOES tags over twenty entity types plus `ORG`, which is detected but not redacted by default — the card's reasoning is explicit: "a company is not a natural person," and the label exists so `Odoo` or `Silverfin` doesn't get mislabeled as a `SURNAME`. ```json // desert-ant-labs/redact/config.json (excerpt) { "architectures": ["BertForTokenClassification"], "hidden_size": 384, "id2label": { "0": "O", "1": "B-SSN", "5": "B-CREDIT_CARD", "9": "B-EMAIL", "21": "B-GIVEN_NAME", "25": "B-SURNAME" // ... 20 entity types x {B,I,E,S}, plus O } } ``` ## Tongue: three words, and the model that looks hand-built Tongue is the one repo in the family with no "Built on" section, no third-party checkpoint in its file list, and an architecture description that reads like something built for this problem specifically rather than adapted to it: a zero-parameter Unicode script router in front of a model that hashes character n-grams straight into an int8 embedding table with no tokenizer, no vocabulary file, and no encoder. The shipped artifact is 2.01 MiB. Training data is five explicitly permissive sources (Tatoeba, Common Voice, Wikidata Lexemes, Hunspell, five Universal Dependencies treebanks) with Wikipedia and Europarl excluded by policy, because a competing detector's published test set is drawn from Wikipedia-adjacent text and using it would contaminate the comparison. The headline number — "identify 84 languages from three words... 0.933 vs. 293MB detector at 0.887" — is real, but "84 languages" and "0.933" are not measured on the same set. 0.933 is FLORES-200 sentences truncated to their first three words, **scored on the 20 languages the three benchmarked detectors (tongue, lingua, eld) all share** — not all 84 languages tongue supports, 59 of which the model actually learns (the other 25 are resolved by script alone, with no model involved). `config.json`'s own `val_accuracy: 0.9112` is yet a third number, on a fourth population: the training pipeline's internal validation split, averaged across all 59 learned languages including the ones no public benchmark covers. None of the three numbers is wrong; none of them is interchangeable with either of the others, and the launch post prints the one that sounds best without saying which population it covers. | Detector | Size | 2 words | 3 words | 5 words | |---|---|---:|---:|---:| | **tongue** | **2MB** | **0.869** | **0.933** | **0.974** | | lingua | 293MB | 0.800 | 0.887 | 0.956 | | eld | 1MB | 0.780 | 0.856 | 0.912 | Where Tongue earns real credit is the failure-modes section — five of them, published on the model's own card, before the benchmark tables: Malay/Indonesian are "not reliably separable... every detector we measured struggles with it," Cyrillic Mongolian silently returns Russian, single-word accuracy is "vocabulary recognition, not generalization" rather than a real detection signal, and brand names and version strings have no correct answer at all. That is a more complete account of where a model breaks than any of the other sixteen cards in this family publish, on a model that is, by the evidence available, the one built without a third-party base underneath it. ## Clips: replacing Claude Sonnet, according to a page with no quality figures This is the launch post's boldest claim: "We replaced Claude Sonnet with Clips, our 284MB model that turns a 10-minute video into a dozen clips in 5 seconds — 10x faster and using 470x less energy than Sonnet, with the same quality." Three separate numbers, three separate things to check, and the model's own SDK documentation contradicts the premise before you reach any of them: From `docs/models/clips.md` in Desert Ant's own SDK repo, verbatim: "**Status: Internal testing.** This card carries no quality or latency figures: the evaluation behind this checkpoint has not completed independent review, and an unreviewed number on a public card gets quoted as if it had been." The same page adds that the LiteRT (Android/Linux/Windows) build "do[es] not work with the Desert Ant SDK yet... No clip has ever been read from the LiteRT files, on any platform" — its only gate is a synthetic random-token batch that the training repo's own manifest marks `is_a_quality_result: false`. That is Desert Ant, in its own developer documentation, saying this specific checkpoint has not cleared internal review — about the model its launch post uses to claim parity with Claude Sonnet. Both things are true of the same release. The "same quality" line in the blog post traces to a single sentence on the `/about` page: "The same job as the Claude Sonnet call in Detail's auto-edit, scored at parity in a blind read" — a blind human comparison, which is a legitimate methodology, but with no stated sample size, rater count, or agreement score, on a checkpoint the SDK docs say hasn't finished review. The energy claim is the one with an actual published methodology, and it's worth checking because the methodology is public enough to check: The published total (0.3kWh for Clips against Sonnet's 140kWh) matches the published ratio (470x) almost exactly — 140 ÷ 470 ≈ 0.298. What it doesn't match is the methodology note printed next to both numbers on the same page: "Clips: 2.4s on an iPhone 17 Pro at an assumed 3W." Multiply that out — 2.4 seconds × 3 watts × 100,000 jobs — and you get 0.2kWh, not 0.3kWh, which is a 700x ratio rather than 470x. And the 2.4-second per-job figure doesn't reconcile with the only other per-job latency Desert Ant has published for Clips: 9.19 seconds, for a 25-minute, 12-clip video on the same iPhone 17 Pro, in the model's own README. Substituting that number instead gives roughly 183x — a real advantage over Sonnet, on the estimate we're given, but not the number in the headline. Sonnet's side of the ledger is itself "energy estimated from published MLPerf runs," not a metered measurement — so this is an estimate compared against an estimate, and the estimate's own inputs don't reproduce its own output. None of this means Clips is slow, or bad, or that a local model can't beat a hosted LLM at a repetitive, deterministic task like clip selection — that's a plausible outcome for exactly the reasons the launch post gives. It means the flagship comparison of the entire launch is not, on the evidence Desert Ant itself published, a comparison that's finished being checked. ## Clear: the fastest number on the page, and the metric nobody published Clear's numbers are the least ambiguous in the family, and also the ones missing a column every reader in speech ML will notice is gone. The speed claim is specific and reproducible in principle — "enhance, master, and re-encode a 60-second clip, best of three, on the device": 302x realtime on an iPhone 16 Pro, 345x on a MacBook Pro (M5), all 492 Core ML operations confirmed resident on the Apple Neural Engine via `MLComputePlan`. The model itself is 9MB (Core ML, fp16 compute with a 6-bit weight palette) or 24MB as cross-platform ONNX. Speech enhancement has standard, decades-old objective metrics for exactly this — PESQ, STOI, and the newer DNSMOS SIG/BAK/OVRL triad that DeepFilterNet's own papers report. None of them appear anywhere on Clear's model card, its docs page, or the launch post. The model's own page says why, in a sentence that is unusually direct for a launch-week product page: **"we have not published an audio-quality score against the cloud tools."** The "replaced Dolby for better, faster audio enhancement" line in the blog post is, on the evidence Desert Ant has released, a speed and size claim wearing a quality claim's clothes — "better" describes the character of the sound (denoised, dereverbed, "warm and present," per the card's own subjective description), not a number anyone can check against Dolby's own output. ## Size vs. quality, across the family Put the models that *do* publish a head-to-head quality number on one chart, and the shape of the whole launch becomes visible at once — including the four models that can't be plotted honestly because no such number exists for them: That's the actual story here, and it's a more interesting one than "the marketing checks out" or "the marketing is fake." Where Desert Ant publishes a matched benchmark — Tongue against lingua, Voz against Whisper, Redact against GLiNER-PII on two separate axes — the pattern is consistent: a size reduction of one to two orders of magnitude, next to a quality difference of a few points, sometimes in Desert Ant's favor and sometimes not. That's a genuinely good trade for most on-device use cases, and it's the trade smaller specialized models are supposed to make. Where the launch's two most quotable numbers live — Clips beating Sonnet, Clear beating Dolby — there's no matched benchmark at all, and in Clips' case, the company's own SDK documentation says the checkpoint behind the claim hasn't finished being evaluated. ## Downloads measure something, but not quality One more number worth sitting with: `emo`, the emoji suggester, has 24,044 downloads and 0 likes. `voz`, the launch's flagship model and the one with a published WER table against a leaderboard, has 0 downloads and 12 likes. That inversion isn't a quality signal either way — it's mostly a packaging story. `emo` ships an 11MB LiteRT file that runs anywhere `onnxruntime`-adjacent tooling reaches, including plain automated crawling and CI pipelines that pull small classifier weights by the thousand; `voz` is Apple-only, requires the Swift SDK, and is a 488MB download nobody's script fetches by accident. Hugging Face's download counter has always measured "how many things — scripts, mirrors, CI runs, people — pulled these bytes," not "how many people evaluated this model and kept it." Sixteen models into one company's launch week is a small enough sample that the gap is more a lesson in what the counter is than a finding about either model. ## The SDK, for real The install story is the one part of the launch that's straightforward to verify by just reading the code. Swift, from the Voz docs: ```swift import Voz let voz = try await Voz() let result = try await voz.transcribe(url) result.text // the transcript result.words.first?.start // 80 ms resolution result.realtimeFactor // seconds of audio per second of wall clock ``` Kotlin and JavaScript, from `desert-ant-core`'s own README: ```kotlin // build.gradle.kts dependencies { implementation("ai.desertant:emo:3.1.0") implementation("ai.desertant:redact:3.1.0") } ``` ```bash npm i @desert-ant-labs/emo @litertjs/core # browser, WebAssembly + LiteRT.js npm i @desert-ant-labs/emo # Node, prebuilt native core ``` Each model is its own Swift product and its own npm package — "you only pay for what you add" is a real property of the packaging, not marketing, since Tongue in particular ships as a dependency-free 2MB file with no wasm and no native core at all, small enough to bundle rather than download. The one sharp edge worth flagging for anyone actually integrating: Clips' LiteRT files use `int64` inputs where the SDK's LiteRT backend builds `int32`, and name their tensors `args_0`/`args_1` rather than the `ids`/`mask` names the SDK expects — which is the concrete mechanism behind the "does not work with the SDK yet" warning above, not just a caveat in prose. ## What this article can and can't stand behind - **"84 languages from 3 words, 0.933 vs. 0.887"** — confirmed, on Tongue's own published FLORES-200 table, but specifically on the 20 languages the compared detectors share, not the full 84. The config's separate `0.9112` figure is a different population (59 languages, internal validation split) and isn't the same measurement. - **"88.8% of personal data, close to 2.3GB GLiNER-PII"** — confirmed as stated, and the fuller table (which the launch post doesn't quote) shows redact ahead on precision by 9 points. The 198x size gap is roughly 25x fewer parameters and 8x lower-precision quantization, not purely architecture. - **"4.7x faster than Whisper"** — confirmed on Voz's own model page as whisper.cpp large-v3-turbo, same podcast audio, unspecified hardware beyond "a Mac." The blog post's own 30-minute/M3-Ultra chart implies a different 6.4x ratio against an unspecified Whisper runtime — the two aren't the same benchmark, and neither discloses which Whisper build the RTF (not WER) comparison ran. - **"302x / 345x realtime" for Clear** — confirmed on the model's own page. **No PESQ, STOI, or DNSMOS number exists anywhere in the released materials**, and the model's own page says so outright: "we have not published an audio-quality score against the cloud tools." - **"10x faster, 470x less energy, same quality" for Clips vs. Sonnet** — could not verify. Desert Ant's own SDK docs describe this checkpoint as "internal testing" with "no quality or latency figures" pending independent review. The energy methodology's own stated inputs (2.4s × 3W × 100,000 jobs) compute to 0.2kWh, not the published 0.3kWh — a 700x ratio, not 470x — and a different published latency figure for a similar job (9.19s) implies roughly 183x. "Same quality" traces to an unspecified blind read with no sample size given. - **"We trained the models ourselves"** — true without qualification for `tongue`. For `voz`, `title`, `clips`, `redact`, `toxic`, and `toxic-en`, the models' own cards name a third-party open checkpoint (NVIDIA Parakeet, IBM Granite, XLM-R, or a MiniLM distillation) as the base, with Desert Ant's original contribution being conversion, quantization, truncation, fine-tuning, or new heads on a reused trunk — real work, but not "from scratch." `clear`'s base is inferable from tags (`deepfilternet`) but not formally disclosed anywhere on its card; `emo` sits between the two, with an original architecture wrapped around a distilled third-party embedding table. I did not independently verify GLiNER-PII's, Rampart's, or the OpenAI privacy filter's own published numbers against redact's table — that would need running those systems on the same rows, which is outside what's checkable from public model cards alone. Where this article says a number "holds up," it means Desert Ant's own materials are internally consistent and the arithmetic checks out — not that a third party has reproduced it.