For inference providers · .txt

Does your provider break your tool calls?
You serve the same weights as everyone else. What sets your endpoint apart is whether its tool calls parse.
.lambda defines each model's own call format once, and uses it both to constrain generation and to parse the result. Every tool call your endpoint returns is valid.
Every tool call looks fine to your endpoint: the request returned 200. The customer sees the failure: the model answered in text where a call was due, wrote malformed JSON, named a tool it wasn't offered, or passed arguments the schema rejects.
Tool calling is hard to get right. Providers serving the same weights end up with very different error rates.
OpenRouter's published tool-call error rate per provider endpoint, 27 October to 2 November 2026, for providers with at least 1,000 tool calls a day, from the .txt Tool-call index (providers.dottxt.ai).
Same weights, different endpoints.
For these, the provider matters more than the model.
From the .txt Tool-call index, on OpenRouter's published data, 3 to 9 November 2026. Broken calls: the 474 provider-model pairs with 1,000 or more tool calls a day. Gaps: medians over the 48 models served by at least two providers with 1,000 or more tool calls a day.
We tested .lambda on Reflection's Beam 1.0, a 501B open-weight model, across the BFCL v3 benchmark.
On about a third of the attempts, .lambda had to step in and correct the model's output. Those attempts got better: the share of tasks solved went from 66.5% to 69.7%. On the other two thirds, the model had already written a valid call and .lambda left it alone. The score there was 75.2% with and without it.
6,069 attempts. Nothing changed.
BFCL v3 with Reflection's Beam 1.0, run on the model's release day.
Constrained generation has to decide which tokens are allowed before each one is generated. .lambda does that while the GPU is still busy with the forward pass, so the answer is ready before it's needed.
We timed .lambda and the library most engines use by default for this, on the same public benchmark data, with GLM 5.3 at batch 32. At the slowest provider's speed, the default library adds 3.4%. At the fastest, it adds 50.6%. .lambda adds nothing at any of them.
The default library’s cost also depends on the model. Per token, at p90, it takes 268 µs on GLM-5.3 and 160 µs on Kimi-K2.6, so every new model needs benchmarking again. .lambda takes 25 and 29 µs.
GLM 5.3, batch 32, public benchmark data. We timed each library on its own: how long it takes to work out the allowed tokens, with anything beyond the GPU's time per token counted as slowdown.
Time per token to compute the next mask and accept the token, on the positions both libraries accepted: 787,107 on GLM-5.3 and 771,199 on Kimi-K2.6.
Developers judge a model, and the providers serving it, in its first week. A new open-weight model with tool calling ships about seven times a month, and the engines' parsers catch up over months.
We write the model's format definition before launch, from its documentation, chat template and raw generations, and qualify it on your engine before traffic.
Median of the 10 most-used open-weight models on OpenRouter, to 10 November 2026.
.lambda runs inside your cluster, alongside vLLM, SGLang, TensorRT-LLM or ONNX Runtime GenAI. Customer requests never leave it, and we collect no telemetry.
.lambda takes the default library's place behind the same interface. We maintain the format definitions, fix the bugs and add new models as they ship.
Pick the model and engine where your tool calls fail most. With the scope agreed, an engineer assigned and the workload ready, the evaluation takes under a week.
Integrating the library has taken clients under two hours.
One model and serving configuration, representative requests including known failures, required customer features and an assigned engineer.
One engineer on each side integrates the library, reproduces the failures and compares correctness, task quality, performance under load and operational coverage.
How each engine did on your requests, what we don't support yet, and what a rollout would take.
Your current setup keeps working, and it stays as your fallback. The real question is who fixes it when a new model's format breaks the parser, and how fast. With open source, that's your team waiting on upstream. With .lambda, it's us.
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.
Check how you're counting. Most monitoring catches bad JSON but misses the model answering in plain text when it should have called a tool. And a low rate today may not survive a new format or tokenizer.
Not necessarily. .lambda makes sure the call is well-formed. It doesn't make the model smarter. It also never rules out an answer the model could validly have given, so it doesn't make good answers worse: on BFCL with Beam 1.0, attempts where the model already wrote a valid call scored 75.2% with .lambda and 75.2% without. We measure task success separately so you can see both.
Not in our tests: timed on GLM 5.3 at 228 tokens a second, .lambda works out the allowed tokens before the GPU needs them. We timed the library on its own, so test it under your own batching during the pilot, because averages hide slow tails.
Usually just sample outputs from the model. We don't need the weights. Before release, we test it on your engine with your engineers.
A platform fee, tiered by traffic or by dedicated deployment. It includes bug and performance fixes, new model support and standard support.
Tell us which model and engine you serve and where its tool calls fail.
Your model, your engine, and where its tool calls fail.
Within one working day.
Model, engine, test dataset.
Under a week once the scope is agreed.