On-device AI with .lambda · .txt

Does your provider break your tool calls?
Small models get tool calls wrong far more often than cloud models. .lambda stops those mistakes as the model writes, on the device and offline. Works with any runtime, including your own.
Ask a small model to set the kitchen light and it may call a tool you never defined, or set the brightness to 500. With .lambda it can’t write either.
We ran three Qwen3 models on BFCL, with and without .lambda. With it, every completed call parsed and fit the schema. The models also solved more tasks, and the smallest gained the most.
Two retries each fixed none of them.
14% on Qwen3-1.7B. None on Qwen3-0.6B.
BFCL live_multiple, .txt blog. Without .lambda, each task with a broken call was retried up to twice. With .lambda, no call was broken and nothing was retried.
BFCL live_multiple, .txt blog, 30 April 2026. Share of tasks solved. Without .lambda, a broken call could be retried up to twice.
We worked with Liquid AI on function calling for LFM2-350M, a model built for edge devices. With .txt’s grammar-constrained generation, every call it writes is valid.
A phone generates one token at a time, and the person waits for each. Much of a tool call is fixed: the tool’s name, the argument names, the brackets. With coalescence, .lambda writes those parts without running the model, so the model only generates what carries information.
We also have optimizations for inference on CPU. Ask us about them.
Across every model we tested.
Constraining the call alone saves tokens.
BFCL live_multiple, .txt blog. Tokens generated with .lambda, against the unconstrained baseline, across the models tested.
.lambda runs next to the model, inside your app. Completely offline.
A binary library with C bindings, for ONNX Runtime GenAI and other native runtimes, including one you wrote.
Written in Rust, so it builds for any target Rust compiles to: phones, laptops, embedded boards.
Most of JSON Schema today. We confirm coverage for your schemas during the evaluation.
Compile new constraints on the device, or distribute precompiled artifacts. Tool definitions do not have to be fixed at release.
Strict by default. Or let the model fall back to unconstrained output and lose the guarantee for that call.
Your app decides whether to run a call, and runs it. The model still chooses the action and arguments.
Pick one model, one device and the requests that fail today. We run them with and without .lambda, and measure both the same way.
The runtime you use, your tool definitions, and the requests that fail today.
On your device, measuring valid calls, tasks solved, time to a completed call, and memory and size.
How each did on your requests, what we don’t support yet, and what shipping it would take, including updates after release.
Tell us your model, runtime and target hardware. We'll scope an evaluation with your team.
Your model, runtime, hardware and tool definitions.
Within one working day.
Model, runtime, test dataset.