xLAM: Salesforce's Function-Calling Model Family and the ActionStudio Training Stack
xLAM: A Family of Large Action Models to Empower AI Agent Systems
At a glance
- What is it?
- xLAM bundles a set of downloadable function-calling models with a trajectory-unification training pipeline and the ActionStudio codebase. It is a research release, and the repository says so in plain text.
- Who is it for?
- Adopt xLAM if you need an open-weight model that emits structured tool calls and you want the training pipeline that produced it, or if you are reproducing the multi-turn data synthesis described in the APIGen-MT paper. Do not adopt it as a general-purpose chat model; the repository frames the whole family around function calling and agent trajectories, and the README states the repository is for research purposes only.
- 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 last received commits 105 days ago.
- 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 problem xLAM targets: turning heterogeneous agent traces into trainable data
Agent traces arrive in incompatible shapes. One environment logs a tool call as a JSON object, another as a bracketed string, a third as a sequence of assistant turns with no explicit call boundary. The README states the motivation directly: fully harnessing LLMs for agent-based tasks is hard because data sources are heterogeneous and feature multi-turn trajectories. xLAM's answer is to aggregate trajectories from distinct environments, standardize them into one format, and expose a generic data loader for agent training. The audience is narrower than the model list suggests. This is for people who train or fine-tune function-calling models, or who need an open-weight checkpoint that emits structured calls rather than prose. If you want a chatbot, the framing here does not match your use case.
Trajectory unification and the training pipeline's partitioning behaviour
The pipeline has two visible stages. First, trajectories from different environments are normalized into a consistent format; second, training runs against that unified representation. The README describes one detail that matters more than it first appears: the training pipeline maintains equilibrium across different data sources and preserves independent randomness across devices during dataset partitioning and model training. That is a statement about sampling weights and about sharding. If a run mixes a large single-turn dataset with a small multi-turn one, unweighted sampling lets the large source dominate; the equilibrium claim is that the pipeline corrects for this. The randomness claim targets a subtler failure, where each device partitions the dataset differently and the effective batch becomes inconsistent. The README does not publish the sampling formula or the sharding implementation, so treat both as documented intent rather than verified behaviour.
The xLAM model family and what the release table actually lists
The repository ships models rather than a single artifact. The model instruction table in the README has columns for total parameters, context length, release date, category, a model download link, and a separate GGUF download link. The one row visible in the supplied material is Llama-xLAM-2-70b-fc-r at 70B parameters. Other names appear in the news entries: xLAM-1b-fc-r and xLAM-7b-fc-r, released in July 2024; xLAM-8x22b-r; and xLAM-2-fc-r, which the README says reached Top-1 on the Berkeley Function-Calling Leaderboard on 2025-04-15. The GGUF column is the practical detail. A GGUF build means the checkpoint can be served by llama.cpp-family runtimes without a full PyTorch stack, which changes the deployment cost for the smaller sizes. The README does not say which sizes have GGUF files published, so check the table row by row before planning an inference setup.
ActionStudio, APIGen-MT, and the data synthesis half of the project
xLAM is not only a model release. ActionStudio is a separate codebase inside the repository, open-sourced on 2025-04-15 with its own paper and a README at the actionstudio path. The news entries describe a later update with improved training configuration tracking. Alongside it, APIGen-MT is the multi-turn data synthesis method, with a paper and a project website, and the APIGen-MT-5k dataset is published on Hugging Face as a compact set for exploring multi-turn function calling. An earlier dataset, xlam-function-calling-60k, is also referenced. The practical consequence is that you can adopt the models without touching the training stack, or adopt the training stack without serving the released checkpoints. Those are different commitments, and the repository keeps them in separate directories, which is the right layout for that split.
Installation and training commands as the README presents them
The README links an Installation section and a Train section, and the badge at the top states Python 3.9 or later. The repository layout puts ActionStudio under its own directory with a separate README, so the install path for the training stack is documented there rather than in the top-level file. The supplied material does not include the literal install commands, the config keys, or the training entry point, so I am not going to invent them. What can be said from the material: the project is Python, the minimum interpreter version is 3.9, and both a top-level README and an ActionStudio README carry the setup instructions. If you are evaluating this for adoption, open the ActionStudio README first, because that is where the training configuration and its tracking live. Model usage is a separate path: the README points to a chat template example notebook on the xLAM-8x22b-r model card for interacting with the models, which is the closest thing to a canonical prompt format the repository offers.
Where xLAM is the wrong tool
The README carries a note that the repository is provided for research purposes only, and that data related to xLAM is partially released due to internal regulations. That single sentence rules out treating this as a supported product with a compatibility guarantee. There is a second constraint: no releases were retrieved for the repository, so there are no tagged versions to pin against. You track the main branch or you vendor a commit hash. Third, the model family is specialized. A checkpoint named with the fc-r suffix is a function-calling model; using it as a general assistant means fighting its training objective. If your workload is open-ended conversation, summarization, or long-form reasoning without tools, the smaller xLAM checkpoints are the wrong choice and a general instruction-tuned model of similar size is the better fit. The partial data release also matters if your goal is end-to-end reproduction of the published results rather than fine-tuning on your own traces.
How this differs from Gorilla and the Berkeley Function-Calling Leaderboard ecosystem
The obvious comparison is Gorilla, because xLAM's news entries cite the Berkeley Function-Calling Leaderboard that Gorilla maintains, and because both projects address tool use by language models. The difference is in what gets shipped. Gorilla's public identity is the leaderboard plus an API-calling model line, evaluated against hosted APIs. xLAM ships a training pipeline as a first-class artifact: trajectory aggregation, format unification, a data loader, and a source-balancing scheme, with ActionStudio as the training front end and APIGen-MT as the data synthesis method. So the choice is not which model scores higher on a shared benchmark. It is whether you need a checkpoint, or a pipeline you can point at your own traces and your own tool schemas. If you only need a model, the leaderboard rankings are the relevant signal. If you need to produce a model from your own environment logs, the pipeline is the reason to look here, and the model rankings are secondary.
Maintenance cost, versioning, and the Apache-2.0 terms
The licence badge in the README reads Apache, and the repository metadata confirms Apache-2.0. That is a permissive licence, which matters for the code and for anything the repository distributes under it, but it does not automatically settle the terms of the model weights. Those live on Hugging Face under their own model cards, and the collection link in the README is where you check them. I am not giving legal advice; read the model card for the specific checkpoint you deploy. On maintenance: with no tagged releases retrieved, there is no upgrade path expressed as versions, so the cost of tracking upstream is the cost of diffing main. The ActionStudio update in August 2025 changed training configuration tracking and general code, which is the kind of change that can shift a config schema. Budget for reading the ActionStudio README again after you pull, rather than assuming your existing training config still parses.
Editorial conclusion
Adopt xLAM if you need an open-weight model that emits structured tool calls and you want the training pipeline that produced it, or if you are reproducing the multi-turn data synthesis described in the APIGen-MT paper. Do not adopt it as a general-purpose chat model; the repository frames the whole family around function calling and agent trajectories, and the README states the repository is for research purposes only. Before you commit, verify three things on the Hugging Face collection: the exact model card for the size you intend to serve, the chat template shipped with that checkpoint, and the context length listed for it. Also confirm whether the dataset you plan to train on is fully published, because the README notes that data related to xLAM is partially released due to internal regulations.
Community notes