# AnySpeechRecognizer and AnyDecisionModel Bring More Local AI Options to Swift

Two open-source Swift packages make speech engines and typed model decisions easier to integrate, but backend choice still changes latency and reliability.

By Paras Madan | 2026-10-30

Developer Mattt introduced AnySpeechRecognizer and AnyDecisionModel in an October 29 Hugging Face post. The open-source Swift packages let developers integrate alternative speech engines and structured model decisions, including on-device inference, without treating every task as a conversation with a chatbot.

These are independent packages, not Apple product announcements. The [introduction](https://huggingface.co/blog/anydecisionmodel) presents a familiar Swift interface over a choice of underlying models. The practical question is how much that shared interface hides, and which differences an application still needs to handle.

## AnySpeechRecognizer: familiar API, different engines

[AnySpeechRecognizer](https://github.com/mattt/AnySpeechRecognizer) mirrors Apple's modern Speech API while supporting local Parakeet and Qwen3 ASR models through Core ML. It also supports speaker diarization, which assigns speech to different speaker labels. It does not replace the older `SFSpeechRecognizer` interface or capture microphone audio for the application.

The package requires Swift 6.2 and macOS 26 or iOS 26. Parakeet and Sortformer require Apple silicon. Its license is Apache 2.0, but model-weight licenses vary and need separate review.

Backend choice changes the product experience. Parakeet supports live provisional results and word timings. Qwen3 ASR supports more languages but can wait up to roughly 40 seconds for a final segment; it lacks provisional results, word timing and confidence output. That makes it a more natural fit for processing recordings than an interface that must update continuously while someone speaks.

Diarization handles up to four speakers. A speaker label should not be treated as verified identity.

## AnyDecisionModel: probabilities instead of generated prose

[AnyDecisionModel](https://github.com/mattt/AnyDecisionModel) returns typed choices, binary probabilities and ordinal scores. It supports local MLX, Core AI and llama.cpp paths, plus Jev and Ollama servers. Local execution therefore depends on the selected backend, not simply importing the package. The Core AI backend requires OS 27, and the announcement warns that its current dependencies cannot be combined with AnySpeechRecognizer in one package setup.

For its standard local language-model path, the package reads probabilities for permitted answer labels in one forward pass. A support-ticket router can receive an enum value directly instead of asking for a paragraph and extracting a category from it.

There are limits. The next-token-label approach allows up to 26 choices or ten score levels. Optional rotation-based debiasing averages across answer orderings, costing one prompt evaluation per rotation.

The repository also warns that local confidence measures distribution concentration, not the probability that an answer is correct. Calibration needs separate data, and confidence values should not be compared across backends as though they share a universal meaning. Typed outputs do not themselves prevent prompt injection.

## What this changes for app developers

These packages make it easier to keep the application interface stable while changing the inference implementation. They do not make the implementations interchangeable in every practical sense.

Consider a voice note that needs transcription and routing. The user may tolerate waiting for a completed recording to process, but not a long pause during live dictation. A routing decision can be well-formed and still incorrect. The application needs separate tests for transcription responsiveness, category accuracy and the point at which a person should review the result.

**A shared API reduces integration work; it does not replace evaluation.** That is the useful way to approach these releases: start with the workflow's acceptable delay and error rate, then choose the backend that meets them. Switching models becomes valuable when that decision can be measured rather than made from an impressive demo.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help developer-tool founders explain technical tradeoffs and turn product updates into stories developers actually find useful.

[Book a 30-minute call](https://cal.com/paras-madan/30min).