.lambda: tool calls for every model, on any runtime · .txt

Does your provider break your tool calls?
Every model speaks its own tool-calling language. .lambda describes each one once, enforces it while the model writes, and reads the call back when it stops. No parser per model, no retries, no call that fails to parse.
For inference providers, model labs, and on-device teams.
Each writes the call in its own format, so a parser for one is useless for the next, and a new model breaks them all.
.lambda knows the native format of every model it supports. Your engine hands it the request’s tools; the model writes the call its own way, and what comes out is valid, parsed, and the same whatever the model wrote it. When a new model ships, we add its format. Nothing changes in your engine.
We add each model’s native format as it ships. All you have to do is update .lambda and your users get valid tool calls. Ask us which models are supported today.
A valid call is guaranteed. Whether it is the right call is measured. On the Berkeley Function Calling Leaderboard, the same models pick the right tool and arguments more often with .lambda, even with the baseline allowed two retries.
The baseline runs the same models unconstrained, with up to two retries when a call fails to decode or to match its schema. A wrong tool or a wrong value counts as a failure in both arms. The models are small open-weight Qwen3 models: the evaluation measures what constraining changes for one model, not which model is best.
.txt’s tool-calling evaluation, 30 April 2026. Baseline success is counted after its retries; schema corrections were applied to both arms.
On Reflection’s Beam 1.0, run on the model’s release day across BFCL v3 with no retries for the baseline, schema violations went from 151 to 0. Where .lambda stepped in, success rose 3.2 points; overall, 1.0. See the full results.
Nothing changes for your users. .lambda sits in your engine’s decoding loop and hands back a parsed call. The integration is minimal: a few hours of work at most.
The model’s format definition, its tokenizer, the tools offered in the request, and their argument schemas.
The constraints decide which continuations are allowed. The model chooses among them.
The tool name and arguments, mapped into your engine’s response format.
vLLM · SGLang · TensorRT-LLM · ONNX Runtime GenAI.
A Python wheel for vLLM, SGLang and TensorRT-LLM, and a binary library for ONNX Runtime GenAI and other native runtimes. Each comes with a patch for the engine.
No. Outlines is our open-source library, and it stays open source. .lambda is a commercial product built on a separate engine. It knows each model's tool-call format, parses calls as they stream, supports new models on launch day, and its time per token doesn't depend on the model. We maintain and support it in production.
Everything our .json engine supports, which is more than anyone else’s. The .json product page lists the features.
Most likely we already support it. If not, we’re happy to add it as part of the initial deployment.
Yes. .lambda brings its own parser, so there is no engine parser to patch and nothing to keep in step across engines.
Yes. .lambda parses tool calls as the model generates them.
No. Open-source libraries slow down or speed up depending on the model’s tokenizer or tool call format. .lambda has the same speed guarantees whatever the model.
Yes, and that’s where .lambda’s speed shows most. Checking a run of draft tokens needs a mask for each of them in the same step, so a slow mask adds up fast.
Single and parallel tool calls, parallel where the model’s format allows it, and both the auto and required modes.
Yes. The model thinks freely, and constraints apply once the thinking block ends.
Yes. .lambda guarantees the structure and the schema. The model still chooses the tool and the values, and it can choose wrong. Nevertheless, constraining can only improve quality.
Each page covers what you need in place, how .lambda runs there, and how we evaluate it with you.
Runs inside vLLM, SGLang and TensorRT-LLM, in your cluster. No slowdown. Pilot on one model. Serve it in weeks.
Before release, get a report on where your model breaks its own format, and how often. We run paired benchmarks with and without .lambda, for you to publish. Your result becomes the reference.
Qwen3-0.6B goes from 46.9% to 55.1% on BFCL, with no repair retries. Runs on your hardware and inside your runtime, offline.