Desert Ant Core ships eight narrow models that never phone home

Small models that stay on the device, across three ecosystems

Desert Ant Core is a set of on-device model SDKs published for Swift, Kotlin and JavaScript, each backed by the inference runtime native to its platform: the Apple machine learning framework on Apple systems, the Google runtime on Android, and a WebAssembly build of that runtime in the browser. The stated consequence is the point of the whole thing: text, audio and images never leave the device.

What makes it interesting is that the models are small and narrow rather than general. Eight are listed, and each does one job: speech enhancement, spoken language identification across ninety-nine languages, emoji suggestion, topic tagging across a fixed taxonomy, personal information detection and redaction, single-stroke shape recognition, clip extraction from talking video, and word-timestamp refinement for a platform speech pipeline.

That focus is what makes on-device viable. A general model capable of all of these would not fit or would run too slowly; a model that only detects personal information can be small enough to ship in an application.

The audience is mobile and desktop application developers with a specific feature to add, particularly where sending user content to a server is undesirable or impossible.

The redaction example shows what these models are for

One short example in the README does more explaining than the model table, and its redaction half is the more revealing part.

import Redact

let clean = try await Redact().redaction(of: "Email Anna at [email protected].")
// Email [GIVEN_NAME_1] at [EMAIL_1].

Two details are worth drawing out. The interface is one type per model with a single method, which is about as small a surface as an SDK can present, and the calls are asynchronous, which is correct for anything loading a model. The same example pairs this with the emoji suggestion model in a single snippet, so the two compose without ceremony.

The redaction output is the more informative half. Replacing a name and an address with numbered placeholders rather than deleting them preserves the structure of the sentence and keeps distinct entities distinguishable, so a second occurrence of the same person can carry the same token. That is what makes redacted text still useful for downstream processing rather than merely safe, and it is a design decision rather than an implementation detail.

The example being multilingual, with a non-English domain, also signals where several of these models are aimed, since emoji suggestion, topic tagging and redaction are all described as multilingual.

Per-platform packaging, with support that varies by model

Distribution is per platform and per model rather than one bundle, which suits a library where you want one capability and not the other seven.

On Apple platforms the dependency is declared through the standard package manager.

.package(url: "https://github.com/Desert-Ant-Labs/desert-ant-core.git", from: "3.1.0")

On Android the release notes list per-model coordinates under a shared group, so a project takes only the models it uses. A JavaScript path covers both the browser and a server runtime, with the repository's workspace file explaining that the root package exists to link the local core into each model's package for testing rather than to be published itself.

Platform coverage differs by model and the table is explicit about it. Most of the eight run across Apple, Android, Linux, Windows, web and the server runtime. Two do not: the timestamp refinement model is Apple only, since it refines a platform-specific pipeline, and the clip extraction model omits Android and the web, which is unsurprising for the heaviest task in the list.

Checking that table for the specific model you want, rather than reading the platform badges at the top, is the step that avoids a late surprise.

Models are downloaded, and the offline path is documented

A section on model downloading and caching, with subsections on offline and air-gapped operation and on a serverless deployment target, tells you the default is to fetch weights at runtime rather than embed them.

That is the sensible default, since bundling eight models into an application would be wasteful when most applications use one, and it introduces a first-run network dependency that every adopter needs to plan for. An application whose privacy claim is that data never leaves the device still reaches out once to collect the model, and that distinction is worth being precise about with users.

The presence of a documented air-gapped path is the reassuring part. A privacy-oriented SDK that could not operate without a download would be self-defeating, and providing an explicit route for environments with no network access suggests the case was considered rather than discovered by a user.

The weights themselves are published on a public model hub under the project's own account, one repository per model, so the artifacts are inspectable independently of the SDKs. For a library asking to process personal information locally, being able to look at the model separately from the wrapper is a reasonable thing to offer.

The licence is the open question

The repository carries a licence document, and the platform reports no identified licence for the project, which means the terms are not one of the standard ones a scanner recognises.

For an SDK from a named laboratory, publishing eight models and three platform packages, that is the first thing to resolve and not a formality. A custom licence can say anything: it may be permissive, it may restrict commercial use, it may impose conditions on redistribution or on the models separately from the code. None of that can be assumed from the repository being public.

A third-party notices file sits alongside it, which is a good sign of diligence about upstream components and does not answer the question about the project's own terms.

So the practical order is to read the licence document itself before evaluating anything else, because it governs whether the rest of the evaluation is worth doing, and to check whether the model weights on the hub carry separate terms from the SDK code, which is common and would be easy to miss. This is not legal advice.

Beyond licensing, the project moves quickly, with version 3.1.0 published on 2026-08-28 and the last push on 2026-09-17, and a major version of three suggests the interface has already been through two rounds of change.

A cloud API is the alternative, and the trade is exactly the pitch

For every one of these capabilities a hosted service exists, and using one is the conventional choice.

The difference is the sentence the README leads with. A cloud service sends the user's text, audio or images to someone else's infrastructure, which brings a better model, no application size cost, no device performance concern and updates you receive without shipping a release. It also brings per-call billing, a network round trip in the user's interaction, a dependency on availability, and a disclosure obligation that gets harder as the data gets more personal.

Redaction is the case where this is sharpest. Sending text to a remote service in order to find the personal information in it means transmitting the very data you were trying to protect, which is an awkward position to defend even when the service is trustworthy.

On-device inverts all of it: no round trip, no bill, works on a plane, and nothing to disclose because nothing was sent. The costs are a smaller model, an application that must fetch and store weights, and device performance you do not control.

Take the cloud service when quality is the binding constraint and the data is not sensitive. Take this when the data is the sensitive part, when latency is in the interaction path, or when per-call cost would scale badly, which covers most of what these eight models do.

What the repository shows about how it is built

The tree is that of a genuine multi-platform project rather than one platform with bindings bolted on: Swift sources and a package manifest, a Gradle build with its own plugin project and an Android test project, a workspace for the JavaScript packages, a tools directory, examples, documentation with a page per model, tests, a version file and a third-party notices file. Instruction files for coding agents sit at the root.

Maintaining three build systems and three test paths for eight models is substantial ongoing work, and the per-model documentation pages are what make the varying platform support navigable.

Before adopting, three things in order. Read the licence document, since the terms are not standard and everything else depends on them. Check the platform table for the specific model you need rather than the project's overall badges, because two of the eight have narrower support. Then measure model download size and first-run behaviour on a real device, since the privacy claim holds after the weights arrive and the arrival is the part your users will notice.

Editorial conclusion

Desert Ant Core fits an application adding a narrow capability to sensitive content, where redaction or language identification happening on the device is the difference between a feature you can ship and one you would have to explain. A hosted service remains the better answer when model quality is the binding constraint and the data is not personal. Read the licence document before anything else, because the platform reports no identified licence and a custom one can restrict commercial use or the model weights separately, then check the per-model platform table rather than the project badges, since the timestamp model is Apple only and the clip model omits Android and the web.

Frequently asked questions

Official sources

1. Desert-Ant-Labs/desert-ant-core on GitHub
2. Issues
3. Project website
4. README
5. Releases