Introducing Lapis SAL: bilingual tool-routing models

What we’re introducing, and why

Before an assistant can check the weather, create a reminder or search for information, it needs to make a decision: which tool fits the request? Sometimes, the right decision is to use no tool at all.

Today we’re introducing Lapis SAL, a family of bilingual routing models developed by Lapis Labs. We’re releasing a teacher, a smaller distilled student and an MLX version of the student. Their task is specific: select a tool from an English or Spanish request and the options supplied by a developer.

Giving this decision its own model lets us explore assistants in which each component has a focused responsibility. This research aims to support future Lapis developments, with more efficient assistants and local processing. These models are not integrated into the Lapis app.

How tool selection works

The developer supplies a menu of tool identifiers and descriptions, optionally with example phrasings. SAL compares the request with those options and returns the best-matching identifier, or None when no tool is appropriate. The runtime exposes a calibrated score and option scores, including its internal abstention option.

A menu might offer weather forecasts and calendar management. A question about rain would be routed to the weather option; a request outside the menu could lead to abstention. This illustrates the intended flow, rather than guaranteeing a result for every wording.

Selection is not execution. SAL does not call the tool, extract its arguments or generate a complete conversational response. The application using it handles those steps and the necessary permissions.

Adaptation and evaluation cover thirteen tool families and the option to use none:

CALCULATOR, CALENDAR, CLOCK, CODE, CONTACTS, HEALTH, LOCATION, MAIL, MAPS, MESSAGES, REMINDERS, WEATHER, WEB_SEARCH, NONE.

These are the evaluated categories, not a fixed output vocabulary. Applications supply their own identifiers and descriptions. New tools or different descriptions need independent evaluation.

How we built and trained them

The teacher is based on Laya / ModernBERT-large and has approximately 421 million learned parameters. The student uses an Ettin encoder from the 150M family: the encoder has about 149 million parameters, while the complete model, including the decision head, has approximately 164 million. The 150M name identifies the encoder family.

1. Supervised adaptation. The teacher is fine-tuned on bilingual tool-routing episodes.
2. Distillation. Its score distributions provide training targets for the student, combined with the correct labels.
3. Calibration. Scores are adjusted using development data reserved for that purpose.
4. Export and checks. Backends are prepared and checked before the final held-out evaluation.

The source dataset is synthetic and bilingual: 10,000 examples, split into 8,000 training, 1,000 validation and 1,000 final test examples. Preparation creates episodes with variable tool menus from training and validation rows; the final test stays separate. Source data and teacher soft labels are not redistributed.

The environment was configured with 2 × NVIDIA T4 GPUs and FP16 mixed precision. The retained trainer runs on a single device (world_size: 1); the environment configuration does not establish or imply distributed training across both GPUs.

Available models and formats

All three published repositories are licensed under Apache 2.0, retaining upstream notices. Each contains its own checkpoint or backend, tokenizer, runtime and instructions. You do not need to download the whole family to run one model.

• Student PyTorch — lapis-sal-150M. An FP32 checkpoint for research, further fine-tuning and conversion.
• Teacher PyTorch — lapis-sal-421M. An FP32 checkpoint for teacher inference and distillation target generation.
• Student MLX — lapis-sal-150M-MLX. FP16 weights for local inference on macOS with Apple Silicon and a Metal GPU.

MLX supports INT8 quantization at load time for eligible layers. It uses the same FP16 checkpoint: INT8 is not a separate download or a smaller stored weight file. Ineligible layers, including embeddings, keep their original representation.

The ONNX export has been validated internally but is not published. It is not part of this release’s downloads.

These models use a custom decision architecture. Follow the bundled runtime and each repository’s instructions; loading only the encoder or using a generic generation function does not reproduce the router.

Results and evaluation limits

We evaluated a private, synthetic benchmark of 1,000 held-out examples: 500 English and 500 Spanish. All thirteen tools and NONE are available, with shortlisting disabled and a threshold of 0.625. Accuracy is the proportion of requests routed to the correct option.

The student’s raw PyTorch checkpoint was not separately evaluated on this final test. The student results shown here belong to its MLX FP16 and load-time INT8 exports. Their equal aggregate accuracy does not prove equivalence for every possible input.

These numbers describe this particular benchmark; they do not guarantee performance on real traffic. Overlapping descriptions, ambiguous requests and long context can cause errors even with high scores. The total input budget is 512 tokens, shared by the request, tool menu and any supplied history.

Only English and Spanish have been evaluated. Selecting HEALTH or CODE does not validate subsequent health advice or generated code. MLX measurements cover macOS on Apple Silicon; they do not validate iPhone or iPad deployment. The model license does not provide access to the private training or evaluation data.

Where these models could help

SAL can provide a selection layer for personal assistants with calendar, reminder or email tools; for automations that must choose among several steps; and for local applications that want to make this decision on the computer itself.

The PyTorch checkpoints also support exploring domain-specific fine-tuning and new distillation strategies. In each case, evaluate abstention, calibrate the menu with representative data and keep action authorization and execution in the application.

What comes next for Lapis

We want to investigate how focused tool selection can contribute to more efficient assistants and more local processing. Next steps include evaluating representative requests, studying different tool menus and exploring possible uses in future Lapis developments.

Releasing the models lets others try the approach and examine its limits. We are not announcing an app integration or a release date for one. Product updates are documented separately in the Lapis changelog.