litert-samples: A Sample Tree for Google's On-Device Runtime, Not a Library
LiteRT and LiteRT-LM sample apps, model recipes, agent skills and utilities.
At a glance
- What is it?
- Google's litert-samples repository collects runnable apps, model conversion recipes, agent skills and shared Kotlin helpers for LiteRT and LiteRT-LM. It is a reference tree to copy from, not a package to install, and the README itself flags that many model recipes are still in progress.
- Who is it for?
- Adopt litert-samples if you are building an Android or iOS app on LiteRT or LiteRT-LM and want a working reference for the CompiledModel API, the Tensor API or the conversion path from a Hugging Face checkpoint. Do not adopt it if you want a versioned, installable SDK: this is a tree of examples under Apache-2.0, with no releases retrieved and a README note that many model recipes are still in process.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap litert-samples fills between a runtime and a shipped app
LiteRT is the runtime. LiteRT-LM is the orchestration layer for running LLMs on it. Neither tells you how to wire a camera pipeline into a CompiledModel runner, how to take a Hugging Face checkpoint down to a verified .litertlm bundle, or how to prove the converted model behaves on real hardware. litert-samples is the repository Google maintains for exactly those intermediate steps. It is aimed at Android, iOS and Python developers who already know they want on-device inference and now need a starting point that runs. The README is explicit that the contents are official and community contributed sample applications, model recipes, agent skills and utilities. The audience is narrow on purpose: the CompiledModel samples assume modern hardware acceleration through GPU or NPU, and the README tells you to have a device with a supported NPU or GPU such as a modern Pixel, Samsung, or Qualcomm/MediaTek device. If you are targeting a low-end phone with no accelerator, the legacy samples under samples/litert_interpreter are the ones that matter, and they are a different tree with a different API.
Two API paradigms, three sample directories, one repository
The layout splits on API surface before it splits on task. samples/litert/ holds applications built on the CompiledModel API, described in the README as designed for modern hardware acceleration and asynchronous execution. samples/litert_interpreter/ holds the older Interpreter API samples, positioned as broad compatibility examples for Android, iOS and Python covering image classification, object detection, image segmentation and audio classification. samples/litert_lm/ holds high-level Engine samples for LLMs and small language models. A fourth directory, samples/end_to_end/, holds complete pipelines such as ImageNet model conversion plus preprocessing plus classification, which is the closest thing here to a template for a production flow. There is also samples/tensor_api_playground/, a Web/WASM playground that runs Gemma 3, image segmentation, Mandelbrot and Game of Life directly in the browser. That spread is the repository's main structural decision: rather than one canonical app, you get the same problem solved at several API levels, and you pick the level that matches the hardware you can actually ship on.
What the agent skills actually carry, and in what order
The skills/ directory is the part that differs most from a conventional sample repo. The README describes them as custom AI agent skills that carry a model through the LiteRT deployment lifecycle, in order, and points to skills/README.md for the full index. Six are listed. litert-conversion-workflow takes a Hugging Face LLM or VLM checkpoint to a verified .litertlm bundle for LiteRT-LM. gpu-clean-conversion takes a PyTorch or Hugging Face model to a GPU-resident LiteRT model. accuracy-safe-quantization handles fp16, int8 and int4 quantization. on-device-verification is about proving the converted model on the actual device. compiled-model-app-scaffolding builds an Android app around the verified model. litert-compiled-model-migration covers moving an Android TFLite app to LiteRT CompiledModel V2 with NPU JIT acceleration and zero-copy buffers. The ordering is the useful part: verification sits before scaffolding, which means the repository treats a model that has not run on hardware as unproven rather than as a build input. Whether an agent framework actually executes these skills depends on the host you run them in, and the README does not specify one.
Getting a CompiledModel sample onto a device
The README gives a short procedure rather than a build script. Prerequisites are Android Studio at the latest stable version for Android, Xcode at the latest version for iOS, Python 3.9 or newer with pip install ai-edge-litert, and a modern browser with WebGPU or WebAssembly support for the web targets. To run a CompiledModel sample: navigate to samples/litert/<sample_name>, make sure you have a device with a supported NPU or GPU, and follow the setup instructions in that sample's own README.md. That last clause carries the weight. There is no top-level gradle task or make target documented for the whole tree, so each sample's README is the actual entry point and the repository-level instructions stop at navigation. For the web side you either visit the interactive page linked in the README or open samples/tensor_api_playground/index.html, or serve the root index.html through a local HTTP server. The Python path is the lightest: install ai-edge-litert and the conversion recipes under models/ become runnable, with models/conversion.md described as the step-by-step cookbook from a Hugging Face checkpoint to a verified .litertlm bundle or .tflite graph.
The GPU toolkit is a patch layer, and that tells you something
utilities/litert_gpu_toolkit/ is described as pre-conversion patches that rewrite common PyTorch patterns into forms the LiteRT GPU delegate accepts, plus a post-conversion checker. Read that as an admission about the conversion boundary. If a model needs its PyTorch source rewritten before conversion, the delegate does not cover every pattern a typical checkpoint contains, and the toolkit exists to close the gap by editing the graph before it is exported. The post-conversion checker suggests the failure is not always loud: you convert, you get a model, and the checker is what tells you whether the GPU path will actually take it. utilities/common/ is a separate concern, shared Kotlin helpers for Android samples covering the camera pipeline, audio capture, a CompiledModel runner, and image, tensor and math helpers. That is the kind of code every sample would otherwise duplicate, and its presence in a shared directory is a reasonable signal that the Android samples are meant to be read together rather than one at a time.
Where the repository is thin, and where it is the wrong tool
The README says plainly that models/ contains standalone conversion scripts, export recipes and model-specific utilities, and that many are working in process. That is the honest limitation to plan around: a recipe directory in flux is a starting point for your own conversion work, not a supported artifact you can pin. The second limitation is hardware. The CompiledModel samples are written for devices with a supported NPU or GPU, and the README names modern Pixel, Samsung, and Qualcomm/MediaTek devices as the target class. If your install base is older or lower-tier Android hardware, the CompiledModel path is the wrong tool and samples/litert_interpreter is the right one, at the cost of the asynchronous execution and accelerator support the newer API is built around. Third, there is no release artifact retrieved for this repository, so there is no version number to depend on. You consume it by copying or referencing files at a commit, and the surface you depend on can move under you. Anyone who needs a stable, versioned dependency should be looking at the LiteRT runtime itself, not at this sample tree.
How this differs from picking a single end-to-end example
The obvious alternative is to skip the sample tree and start from one worked end-to-end pipeline, the kind found in samples/end_to_end/ or in a framework-specific demo that ships its own conversion and inference code in one place. The difference is scope of decision. A single pipeline gives you one path that is known to work and hides the choices that produced it. litert-samples deliberately exposes the choices: the same problem appears against the CompiledModel API and the legacy Interpreter API, and the conversion material appears both as prose in models/conversion.md and as executable agent skills in skills/. That is more surface to read, and it is the reason the repository is useful before you have committed to an API level and less useful after. If you already know your API, your accelerator and your quantization scheme, a single narrow example will get you to running code faster. If any of those three is still open, the breadth here is the point.
Maintenance cost and what Apache-2.0 does and does not cover
The repository is licensed Apache-2.0, with the README pointing at LICENSE for detail. That covers the sample code, the utilities and the recipes as distributed here. It does not automatically cover the models the recipes point at: the README names Qwen3-TTS, Qwen3 ASR, Bonsai Image 4B, Gemma, MobileNet and Fast VLM among the targets, and each of those carries its own upstream terms that you need to check separately. This is not legal advice, and the licence file is the authority. On maintenance: with no releases retrieved, the practical cost is tracking a moving main branch. The README's own framing, that many recipes are working in process, means a recipe you adopt today may be rewritten. Budget for reading the diff rather than for upgrading a pinned version. The skills/ directory adds a second kind of maintenance, since agent skills are only as portable as the host that interprets them, and the README does not name one.
Editorial conclusion
Adopt litert-samples if you are building an Android or iOS app on LiteRT or LiteRT-LM and want a working reference for the CompiledModel API, the Tensor API or the conversion path from a Hugging Face checkpoint. Do not adopt it if you want a versioned, installable SDK: this is a tree of examples under Apache-2.0, with no releases retrieved and a README note that many model recipes are still in process. Before committing, read the individual sample README under samples/litert/<sample_name>, confirm your device has the NPU or GPU the sample targets, and check whether the recipe you need sits under models/ or only under skills/.
Community notes