Liquid4All/cookbook: LFM and LEAP SDK examples you can actually run

What the Liquid4All cookbook is for

This is a collection of examples, end-to-end tutorials and applications built with Liquid AI Foundational Models and the LEAP SDK. The README frames the goal plainly: help you build with the open-weight LFMs on laptops, mobile and edge devices. The intended reader is an application developer who has already decided to run inference locally and now needs to know what the integration looks like.

The repository is organised by target rather than by model. Desktop apps, browser apps, mobile apps split into Android and iOS, fine-tuning examples, guides, third-party apps and community projects each get their own section. That structure tells you something about the project's centre of gravity: the interesting problem is not the model call, it is the packaging. A voice assistant on a Mac, a chat app on iOS and a WebGPU demo in a browser share a model family but almost nothing else.

If you are looking for a Python package to add to requirements.txt, this is the wrong repository. Nothing in the README describes an installable library. The unit of reuse is a directory you read and copy from.

How the examples are organised across desktop, browser and mobile

Three deployment paths run through the catalogue, and they do not share a runtime.

The desktop path is Python and CLI. The README lists an invoice parser using LFM2-VL-3B, an audio transcription CLI using LFM2.5-Audio-1.5B with llama.cpp, a flight search assistant using LFM2.5-1.2B-Thinking with tool calling, and LocalCowork, described as an on-device agent for file operations, security scanning and OCR powered by LFM2-24B-A2B. The presence of llama.cpp is the tell: these are local inference processes you drive from a script.

The browser path is zero-install by design. Applications run through WebGPU and ONNX Runtime Web, with entries for in-browser tool calling, a voice assistant, live video captioning with LFM2.5-VL-1.6B, chain-of-thought reasoning with LFM2.5-1.2B-Thinking, and a hand and voice controlled driving game. Several of these are hosted as Hugging Face Spaces, so the code and the demo are separate links.

The mobile path is the LEAP Edge SDK, written for Android in Kotlin and iOS in Swift. The README states the SDK's goal directly: make small language model deployment as easy as calling a cloud LLM API endpoint. That is the claim to test against the sample apps, because the samples are where the abstraction either holds or leaks.

Installing a first example: the audio transcription CLI

There is no repository-level install step. You clone the repository and work inside one example directory. The README points the audio transcription CLI at examples/audio-transcription-cli/ and describes it as real-time audio-to-text using LFM2.5-Audio-1.5B with llama.cpp.

Start by getting the repository and moving into that directory.

git clone https://github.com/Liquid4All/cookbook.git
cd cookbook/examples/audio-transcription-cli

From there, read the example's own README before running anything, because the top-level README does not document the flags, the audio input device or the model download path for this entry.

cat README.md

For a browser example the workflow differs: the README links the code at a Hugging Face Space and a separate demo URL, so there is nothing to install locally. For the mobile examples, the code lives in the separate Liquid4All/LeapSDK-Examples repository rather than in this one, and the Android and iOS entries are grouped by language, Kotlin and Swift respectively. If your target is a phone, expect to open two repositories.

One practical note on scope. The README lists twenty example directories under examples/, plus finetuning/ and guides/ at the top level. The top-level README is an index, not a manual. Per-example setup instructions live in each example's own README, and the top-level file does not summarise them.

Where the cookbook stops being useful

The repository carries no releases. The releases list is empty, which means there is no versioned artefact to pin and no changelog describing what changed between states of an example. If you copy a pattern out of an example and it later changes upstream, you have no release note to consult.

The licence is the sharper problem. The repository metadata does not name a licence, and the top-level entries listed are .gitignore, .pre-commit-config.yaml, README.md, examples/, finetuning/ and guides/. No LICENSE file appears among them. For a collection of code you intend to lift into a product, that is the first thing to resolve with the maintainers, not the last.

There is also a hardware mismatch hidden in the model list. The catalogue spans LFM2-350M in the home assistant example up to LFM2-24B-A2B in LocalCowork. Those are not interchangeable targets, and an example that runs comfortably on one machine may not be a useful starting point on another. The README does not publish per-example hardware requirements, so you are reading the model name and inferring.

Finally, this is not a place to look for a supported API surface. It is example code. Treat divergence between examples as expected rather than as a bug.

How this differs from a general model-serving stack

The obvious alternative is a general local inference stack such as llama.cpp or Ollama driving a model you choose yourself. The difference is where the work sits.

A general stack gives you a runtime and leaves the application architecture to you: prompt handling, tool-call parsing, audio capture, streaming into a UI. The cookbook assumes the opposite starting point. It gives you the application architecture for a specific set of models and leaves the runtime choice partly pre-made, which is why the audio transcription CLI is described as using llama.cpp while the browser entries use WebGPU and ONNX Runtime Web.

That is a real trade-off. You get working reference code for voice input, structured output, tool calling and vision on edge hardware. You give up the freedom to swap in an unrelated model family without rewriting the integration. The LEAP SDK examples make the same bargain more explicitly, since the SDK is the thing being demonstrated.

If your constraint is the model, the cookbook is the faster path. If your constraint is portability across model providers, it is not.

Maintenance, licensing and what to check before you copy code

The repository is not archived, and the last push was on 2026-09-18. That is recent enough that the examples reflect the current state of the LFM and LEAP SDK work rather than a frozen snapshot, but recency of commits is not the same as a support commitment, and the absence of releases means there is no upgrade contract to rely on.

Upgrade cost is therefore manual. When a model identifier in an example changes, you find out by reading the repository, not by resolving a version conflict. For a project you intend to maintain, that argues for copying the smallest example that demonstrates your integration and tracking the upstream file yourself.

On licensing: no licence identifier is visible in the repository metadata or among the top-level files. The models are described as open-weight and are hosted on Hugging Face, but the model licence and the code licence are separate questions and neither is answered by the README. This is not legal advice; it is a statement that the information needed to make the call is not in the repository, and that asking the maintainers is the concrete next step.

Editorial conclusion

Adopt the cookbook if you are building an on-device application on LFM models and want a working reference for the LEAP SDK or for llama.cpp based desktop pipelines. Skip it if you need a supported library with releases and an upgrade path, because the repository ships no releases and no licence file is visible at the top level. Before committing, open the README section for the example closest to your target and confirm that the model it names is the one you intend to ship, since the entries span LFM2-350M up to LFM2-24B-A2B and the hardware assumptions differ sharply between them.

Frequently asked questions

Official sources

1. Issues
2. Liquid4All/cookbook on GitHub
3. Project website
4. README