AI agents often use LLMs to choose between a fixed set of tools or rank candidate outputs. In each case, the model processes a prompt and generates tokens even though the application only needs a bounded decision.
Researchers from Stanford and Nvidia have released Contrastive Language Models (CLM), a new approach designed for these kinds of decisions. Instead of generating sequences of tokens, their CLM-8B model creates representations of the current state and the available actions, then selects the action that best matches the state.
This design can be especially useful in applications where agents often make the same types of decisions repeatedly across a workflow. CLM can cache reusable action representations and avoid recomputing them for every request.
In the team’s zero-shot tests across computer use, gaming and tool calling, CLM-8B ran up to 9x faster than TypeSafe’s Jev and matched its success rate on two game tasks. It gave up some accuracy on the other two: it scored 95.2% to Jev’s 99.2% on the BFCL v4 tool-calling benchmark and finished 26 of 30 WikiRacing tasks to Jev’s 30. The largest speedups appeared when the model could reuse actions across many states or choose from a large set of candidates.
CLM also arrives amid growing interest in what TypeSafe calls “System One” models, a category it introduced with Jev earlier this month. CLM adds a contrastive approach to this emerging stack.
How CLM turns decisions into a matching problem
CLM is composed of state and action components. The state is what the model currently knows about a task. The actions are the available choices. CLM learns a shared embedding space for those states and actions. During training, it moves correct pairs closer together and pushes incorrect pairs farther apart.
At inference time, the model does not need to generate the name of the action one token at a time. It encodes the current state, compares that representation with those of the candidate actions, and picks the closest match.
The researchers implement this using a contrastive training method called InfoNCE. InfoNCE trains the model by giving it one correct state-action pair alongside several incorrect ones and rewarding it for assigning the highest similarity to the correct match.
The researchers trained CLM in three stages. They start with around 60 million question-answer pairs to teach broad semantic matching. They then add around 30 million synthetic “hard negatives,” such as multiple-choice questions where answers are semantically similar, but only one is correct. Finally, they post-train on roughly one million agent trajectories to adapt the model to agent decisions.
The released CLM-8B uses a frozen Qwen3-8B backbone with separate projection heads for states and actions. That separation enables a deployment optimization. If an application repeatedly chooses among the same actions, CLM can encode them once and cache the embeddings. Each new request then requires encoding the changing state and comparing it with the cached actions.
For example, an enterprise might want to use CLM for an internal IT agent with 50 approved actions, such as resetting a password, provisioning access, opening a ticket or escalating to security. Instead of repeatedly processing all 50 options as part of a generative prompt, CLM can keep their representations ready and score each new situation against them.
Where CLM fits in an enterprise AI stack
The released model supports several bounded decision patterns: choosing between options, returning a yes/no probability, scoring against an ordered scale and ranking arbitrary candidates. That makes CLM applicable to tasks such as tool routing, ticket triage, retrieval shortlisting and selecting between several proposed outputs.
Generative models can already be constrained to choose from a fixed set of tools or outputs. Structured-output and function-calling APIs have made those responses much more reliable, but they are still constraining a generative model to behave like a decision system. CLM starts with the decision problem itself: given a state and a fixed set of actions, rank the available actions and choose among them.
This could also change the economics of multi-model systems. Routing a request through a generative LLM requires the model to process the prompt and then generate an answer, even when the required output is only the name of one tool. CLM avoids autoregressive output generation.
The researchers do not provide an apples-to-apples dollar-cost comparison with frontier APIs, so the release does not establish a specific hosting-cost reduction. CLM-8B still runs an 8-billion-parameter encoder. But its inference pattern removes computation that generative models perform for bounded decisions.
One of CLM’s important advantages is reducing latency in multi-step agentic tasks. The delay in one routing call might be negligible. But when an agent makes dozens of routing, ranking and checking decisions before returning an answer, those costs compound.
Another advantage is that adapting CLM to a specific task does not require fine-tuning the entire 8-billion-parameter model. The Qwen3-8B backbone remains frozen while developers train the much smaller state and action projection heads.
In comments to VentureBeat, project lead Jacky Kwok of Stanford said the contrastive training objective also has advantages for domain-specific decision tasks. “We found that the contrastive objective can be especially effective for decision-making tasks compared with standard supervised fine-tuning (SFT) using cross-entropy loss,” he said. “We also found that initializing from a pretrained CLM checkpoint enables the model to adapt quickly to downstream/domain-specific tasks.”
For example, a support agent might have to choose whether to issue a refund, escalate to a human, ask for more information, or close a ticket. With CLM’s contrastive objective, the model is trained to pull the correct state-action pair closer together while pushing competing actions farther away.
The team tested this approach by fine-tuning CLM as a verifier for coding tasks. In the team’s coding experiments, larger models first generated several candidate solutions. Opus 5 produced candidates for DeepSWE and Fable 5 for Terminal-Bench 2.1. A fine-tuned CLM then ranked those candidates and selected one for submission.
On held-out subsets, the researchers report that CLM reached 81.6% on 38 DeepSWE tasks and 87.6% on 30 Terminal-Bench 2.1 tasks, compared with 71.1% and 83.1% for Jev on the same subsets. They report that CLM’s verifier latency was 4.1–5.7x lower than Jev’s. It is important to note that CLM did not solve the DeepSWE tasks from scratch. The larger model created the candidate solutions and CLM chose between them.
Kwok describes the broader division of labor this way: “Use large reasoning models to generate and reason, and use CLMs to cheaply select, verify, and monitor their outputs.”
One possible setup would have several cost-efficient open-source models generate candidate responses or actions, then use a CLM to quickly rank them and select the best one. Kwok argues that this can be more cost-effective than relying on a frontier model for most decisions.
CLM could also serve as a monitoring layer for agents. Kwok said the team often sees a clear separation between CLM scores for successful and failed trajectories. “A CLM could continuously score the actions or trajectories produced by an agent and flag unusual or potentially unsuccessful behavior,” he said. This could give enterprise systems another signal for detecting when long-running agents are going off track, though it should not be treated as a guaranteed safety mechanism.
It also sets a boundary on what “verifier” means. CLM only scores the candidates it receives, and its probabilities are relative to that candidate set. If every proposed action is wrong, the model still has to rank them.
There are also tasks where CLM is simply the wrong tool. “I would not use a CLM as a replacement for a general-purpose reasoning model on tasks that require substantial open-ended reasoning, such as solving a math problem, generating a long-form response, or doing high-level planning,” Kwok said. CLMs are better suited to cases where the available choices are already known and the model needs to select, rank or verify them.
Developers can test the pattern today. The team released the CLM-8B weights under Apache 2.0 alongside open-source code, a TypeSafe-compatible API, fine-tuning tools, and a playground for testing states, typed questions and candidate rankings interactively.
How CLM differs from other decision models
CLM is one of several projects released around the recent “System One” idea. TypeSafe introduced Jev on September 15 as a model for fast, structured decisions and trained it with a method it calls Reinforcement Learning for Calibrated Decisions. Laya takes a different approach based on smaller bidirectional encoders. CUA-S1 is narrower still, with its first model focused on choosing bounded actions for form-filling tasks.
But they differ in how they implement that decision layer. “A key difference between CLM and models like Jev or Laya is the architecture,” Kwok said. According to Kwok, Jev and Laya primarily support caching the state representation, while CLM’s dual-encoder architecture lets it compute and cache state and action embeddings independently.
That architectural difference becomes more important when both the context and candidate actions are long. CLM can encode the two sides separately and batch their computation. And when the possible actions are predefined, such as a company’s tools, APIs or workflows, their representations can be computed ahead of time and reused across requests. As Kwok puts it, “CLM is particularly well suited to applications with long context / reusable action spaces.”
The project is also moving beyond the current 8-billion-parameter model. Kwok said CLM-8B is part of a scaling ladder the team is using to study how performance changes with model size. He said a multimodal CLM-35B-A3B is now being trained with more data and compute, with a release planned for early October. The team is also adding substantially more agentic training data.
“We’re also post-training it on substantially more agentic data, with the goal of making it well suited for integration into existing harnesses and workflows,” Kwok said.