feat(constants)!: switch URLs to v0.9.0 layout + add MODEL_REGISTRY

[msluszniak]

Description

Refreshes every URL constant to the restructured HF layout under
resolve/v0.9.0 and adds the typed models accessor.

URL refresh

All URLs follow <model>_<size>_<backend>_<precision>.pte, files sit
under per-size and per-backend directories on HF.

• modelUrls.ts — every URL rewritten; multi-backend URLs hoisted here so the registry stays declarative. The lfm2_5_350m_xnnpack_8w4da.pte typo is corrected to _8da4w.pte.
• ocr/models.ts, tts/models.ts, tts/voices.ts — paths updated to the new shape.
• versions.ts — VERSION_TAG → resolve/v0.9.0; PREVIOUS_VERSION_TAG = resolve/v0.8.0 retained for the @deprecated Llama QLoRA aliases.

models accessor

New constants/modelRegistry.ts exports models, a typed accessor grouped one-to-one with hooks:

Group	Hook
llm	useLLM (includes vision-capable LLMs like lfm2_5_vl_*)
classification	useClassification
privacy_filter	usePrivacyFilter
object_detection	useObjectDetection
pose_estimation	usePoseEstimation
semantic_segmentation	useSemanticSegmentation
instance_segmentation	useInstanceSegmentation
style_transfer	useStyleTransfer
speech_to_text	useSpeechToText
text_to_speech	useTextToSpeech
text_embedding	useTextEmbeddings
image_embedding	useImageEmbeddings
image_generation	useTextToImage
vad	useVAD
ocr	useOCR / useVerticalOCR

Each entry is a function — call it (optionally with { quant, backend }) to get the resolved config:

models.llm.llama3_2_3b()                       // default (quantized, platform-default backend)
models.llm.llama3_2_3b({ quant: false })       // base
models.llm.lfm2_5_vl_1_6b()                    // vision-capable LLM (same hook)
models.text_embedding.distiluse_base_multilingual_cased_v2({ backend: 'coreml' })
models.ocr({ language: 'en' })                 // OCR is parameterized by language

• The backend parameter is typed to exactly the backends each model ships with — models.llm.llama3_2_3b({ backend: 'coreml' }) is a compile-time error (xnnpack-only).
• Defaults to the quantized variant when { quant } is omitted.
• text_to_speech exposes kokoro_small/kokoro_medium plus plain voice configs under voices.*.

ESLint's camelcase rule is relaxed to properties: 'never' so the snake_case property keys pass while bindings/functions stay camelCase.

Migration

// Before                                          // After
LLAMA3_2_1B_SPINQUANT                            → models.llm.llama3_2_1b()
LFM2_5_1_2B_INSTRUCT                             → models.llm.lfm2_5_1_2b_instruct({ quant: false })
LFM2_5_VL_1_6B_QUANTIZED                         → models.llm.lfm2_5_vl_1_6b()
EFFICIENTNET_V2_S                                → models.classification.efficientnet_v2_s()
PRIVACY_FILTER_OPENAI                            → models.privacy_filter.openai()
YOLO26N_POSE                                     → models.pose_estimation.yolo26n()
WHISPER_TINY_EN                                  → models.speech_to_text.whisper_tiny_en()
{ model: KOKORO_MEDIUM, voice: KOKORO_VOICE_AF_HEART }
                                                 → { model: models.text_to_speech.kokoro_medium(),
                                                     voice: models.text_to_speech.voices.af_heart }
OCR_ENGLISH                                      → models.ocr({ language: 'en' })
MODEL_REGISTRY.LLM.LLAMA3_2_3B                   → models.llm.llama3_2_3b()

Individual constant imports (LLAMA3_2_1B_SPINQUANT, KOKORO_MEDIUM, etc.) still work — the new accessor is the recommended path. The flat MODEL_REGISTRY = { ALL_MODELS: {...} } export from modelUrls.ts is removed; the internal getModelNameForUrl lookup is preserved.

Example apps + docs

• All example apps migrated to models.*(). Heavily-used groups are destructured at the top of the file (const segmentation = models.semantic_segmentation;).
• Picker entries compared by modelName to handle accessor-function values.
• bare-rn LLM demo switched to LFM-2.5.
• Every documentation code snippet that selected a model via a named constant is rewritten to use the typed models.<group>.<entry>() accessor across 03-hooks/**, 04-typescript-api/**, 01-fundamentals/**, etc. The webrtc-integration page intentionally keeps the named-constant style — the snippet reads cleaner alongside imports from other libraries.
• Model Registry docs page rewritten for the new accessor; the 0.8.x version's anchor is repointed to its own version to survive the rename.

Deprecations

• LLAMA3_2_3B_QLORA, LLAMA3_2_1B_QLORA — @deprecated; the .pte files stay at v0.8.0 and the constants still resolve those URLs. Use LLAMA3_2_*_SPINQUANT going forward.

Introduces a breaking change?

• Yes
• No

URL paths under ${VERSION_TAG} change — code that hardcoded resolve/v0.8.0 URLs through the constants keeps working only if it read them at runtime. The flat MODEL_REGISTRY export is removed in favour of the new models accessor.

Type of change

• New feature (change which adds functionality)
• Other (chores, tests, code style improvements etc.)

Tested on

• iOS
• Android

yarn typecheck and yarn lint clean across the monorepo. Every example app runs against the v0.9.0 HF state.

Testing instructions

yarn typecheck
yarn lint

In application code:

import { models } from 'react-native-executorch';

const llm = useLLM({ model: models.llm.llama3_2_3b() });
const emb = useTextEmbeddings({
  model: models.text_embedding.distiluse_base_multilingual_cased_v2({ backend: 'coreml' }),
});

Related issues

#431
#612

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings

[barhanc]

There are some problems with HF repos:

• https://huggingface.co/software-mansion/react-native-executorch-clip-vit-base-patch32/tree/v0.9.0/xnnpack doesn't have text encoder and the exported url points to the image encoder. The example app fails with {"code": 18, "message": "The model's forward function did not succeed. Ensure the model input is correct."}
• https://huggingface.co/software-mansion/react-native-executorch-distiluse-base-multilingual-cased-v2/tree/v0.9.0 not all models conform to the naming convention (the fp32 variants use "-" instead of "_")
• https://huggingface.co/software-mansion/react-native-executorch-paraphrase-multilingual-MiniLM-L12-v2/tree/v0.9.0 not all models conform to the naming convention (the fp32 variants use "-" instead of "_")
• https://huggingface.co/software-mansion/react-native-executorch-deeplab-v3/tree/v0.9.0 doesn't have all the variants that v0.8.0 had
• https://huggingface.co/software-mansion/react-native-executorch-fcn/tree/v0.9.0 doesn't have all the variants
• https://huggingface.co/software-mansion/react-native-executorch-fast-sam/tree/v0.9.0 silently drops the xnnpack from fastsam-x/ and fastsam-s/ and adds xnnpack/ and coreml/ without the size distinction

---

• https://huggingface.co/software-mansion/react-native-executorch-qwen-3.5/tree/v0.9.0 has both the 0_8b and Qwen3.5-0.8B (and the same for 2B) directories
• https://huggingface.co/software-mansion/react-native-executorch-detector-craft/tree/v0.9.0/xnnpack has both craft_xnnpack_int8.pte and xnnpack_craft.pte files

---

That's what I managed to find, probably someone else should also have a look at the updated HF repos. I will be testing example apps now.

[barhanc]

Regarding HF repos, the DeepLab and FCN are not categorized by size (the same case as FastSAM before). Other HF repos look fine :)

[msluszniak]

Regarding HF repos, the DeepLab and FCN are not categorized by size (the same case as FastSAM before). Other HF repos look fine :)

@barhanc I don't think these are sizes per se in this case. You have specified only the backbone of the final model. These models might be smaller or bigger but semantically do not indicate sizes immediately (in comparison where models from the same family have different number of parameters and the name derives from this number of is explicitly named s,m,l, xl etc.).

[barhanc]

In docs we have many snippets that use the old API for selecting the model, these should probably be changed as well.

[msluszniak]

The fact that currently models from both llm and lmm are used by useLLM and analogical for modules seems to be a bit off, what do you think, @barhanc @chmjkb?

[barhanc]

The fact that currently models from both llm and lmm are used by useLLM and analogical for modules seems to be a bit off, what do you think, @barhanc @chmjkb

We can just put all these models under llm and leave the hooks and modules unchanged, as the multimodal models are still language models at their core just with added capabilities for other modalities (in this option as a user I would probably want some easy way to see what modalities a given model supports). The other option would be to add useLMM hook and the rest of API mirroring the LLM, but this would lead to a lot of duplicated code, so imo the first option is better.

[msluszniak]

Agreed, I'm also in favour of moving them under llm. Also regarding this one:

in this option as a user I would probably want some easy way to see what modalities a given model supports

Do you have anything particular solution on your mind?

[barhanc]

I guess we already have something like this in place, since the user can check it like this

const LFM2_5_VL = models.llm.lfm2_5_vl_1_6b()
console.log(LFM2_5_VL.capabilities)

[msluszniak]

@barhanc @chmjkb I will rebase this PR once change to TTS will land on main. But you can review it and then only the rebase part.

[barhanc]

LGTM 🚀