An LLM writes. A decision model chooses. A Contrastive Language Model (CLM) is one specific way to build the chooser. Treating all three as rivals is the most common mistake in agent design today, and it leads to paying for generated tokens on steps that only needed a pick.
This guide separates the three labels, compares them on cost and speed using published figures, and ends with a rule you can apply to each step of a pipeline. If the terms are new, our guides to what decision models are and what a CLM is give the background. For the category's launch, see TypeSafe's Jev launch.
TL;DR
| Question | LLM | Decision model | CLM |
|---|---|---|---|
| What is it? | A model that generates text token by token | A model that returns a typed choice or score with a probability | A decision-model design that matches state and action embeddings |
| What axis? | General capability | The job and the API | The training method and architecture |
| Output | Free text, code, tool calls | A pick from your list, a score or a yes/no probability | A score per candidate you supply |
| Can it write? | Yes | No | No |
| Typical cost | Pay for input and output tokens | Pay for input only, about 0.02 to 0.24 dollars per million tokens hosted | Self-hosted embedding calls plus dot products |
| Typical latency | Seconds for long answers | Tens to hundreds of milliseconds | 16.5 ms in one reported zero-shot case |
| Best for | Writing, reasoning, planning, open-ended tool use | Routing, gating, verifying, scoring, classification | Many cached candidates, reuse across states |
| Weak at | Cost and latency on repeated simple picks | Open-ended tasks, planning, unlisted options | Same as decision models, plus needs an enumerable set |
Are LLM, CLM and decision model the same kind of thing?
No. They answer different questions.
- LLM is about capability. It is a large model trained to predict text and then tuned to follow instructions. It can do almost anything you can phrase in words, at the price of generating tokens.
- Decision model is about the job and the interface. You pass an input and a closed set of answers. You get a probability for each, with no free text to parse. The term spread after TypeSafe AI launched Jev on September 15, 2026, and Perplexity, OpenAI, Cloudflare, Liquid AI and others shipped their own versions in the weeks after.
- CLM is about the method. A Contrastive Language Model trains a state encoder and an action encoder with a contrastive loss, then scores candidates by embedding similarity. It is one architecture that produces a decision model.
So the useful picture is a stack, not a triangle. An LLM is a general generator. A decision model is a narrow tool with a fixed output shape. A CLM is one recipe for that narrow tool.
One more trap. In much NLP code, CLM means causal language modeling, the next-token objective that trains GPT-style LLMs. That is a different meaning of the same letters, covered in our CLM explainer and the causal language model dictionary entry. In this post, CLM always means contrastive.
How does an LLM make a decision, and how does a decision model do it?
An LLM can pick from a list if you prompt it to. It reads the prompt, generates a few tokens such as the label name, and you parse them. This works, but you pay for output tokens, you wait for generation, and you handle malformed answers. Some teams read token log probabilities to get a confidence, which works well on some models and not on others.
A decision model skips generation. It reads the input and the options, then returns scores in a single forward pass. There are two main designs in the field:
| Design | How it decides | Examples from our coverage |
|---|---|---|
| Decision head on a language backbone | A trained head reads the backbone's hidden state and outputs option scores or probabilities | Cloudflare's Clef freezes a Qwen3.8-27B backbone, trains a rank-256 LoRA and adds a routing and classification head. Perplexity's pplx-decider is a multimodal fine-tune of Qwen3.8-27B with a separate decision head |
| Contrastive embedding match (CLM) | Two encoders embed the state and each action, and similarity picks the winner | CLM-8B: a frozen LLM backbone plus a roughly 20M-parameter trained head per encoder |
Both are decision models by interface. The difference shows up in cost structure. A decision-head model re-reads the whole input and all options on every call. A CLM can cache the action embeddings and only embed the new state, so cost per decision falls as the option list stays fixed and the number of options grows.
A signpost with three arrows representing a decision model choosing one option from a fixed list
How do cost and speed compare?
Published figures are vendor or author claims, not our measurements, and the vendors use different benchmarks. Treat the table as orders of magnitude.
| Model or class | Reported price or latency | Source of the claim |
|---|---|---|
| Jev (hosted decision model) | 0.042 dollars per million input tokens, output free; 70 to 500 ms end to end | TypeSafe AI |
| OpenAI Decisions API (gpt-6-luna) | 0.10 dollars per million input tokens | OpenAI; day-one testers measured about 2.4 times Jev's list price |
| pplx-decider v1.1 | About 0.02 dollars per million input tokens | Perplexity's developer account; confirm on its pricing page |
| Clef and Clef-flash | About 0.24 and 0.09 dollars per million input tokens | Early October threads; Cloudflare reports about 38.8 ms median for Clef-flash |
| CLM-8B | 16.5 ms against 149.8 ms for Jev on the T-Rex game; 79 ms against 449 ms as a DeepSWE verifier | Contrastive-LM README, self-reported |
Two cautions apply. First, "up to 9x faster" for CLM-8B is the best case, the T-Rex game. Other tasks showed about 1.6x to 4x. Jev was slightly more accurate on tool calling and WikiRacing. Second, a hosted median on short prompts is not a latency distribution; one Hacker News tester found hosted Clef slower than Jev on their workload. Run your own test on your own traffic.
For the head-to-head numbers on named products, see our Clairic vs Jev vs OpenAI Decisions vs Clef vs Microsoft-Decision-1 comparison and the ranked list of ten decision models.
What can each one not do?
LLMs are weak on cost and latency when the same simple pick repeats thousands of times. Their free-text output also needs parsing, validation and retries.
Decision models cannot write text, plan, or create an option you did not provide. If the correct answer is missing from your list, they still pick the nearest one. Jev's own documentation, as summarized by InfoQ, says it is unreliable at counting, arithmetic and date comparison. Their scores are also not automatically calibrated. Check calibration on your own data before setting a threshold. See where Jev actually fails.
CLMs inherit the decision-model limits and add one more. They need a candidate set you can enumerate and describe in text. The benchmark evidence is also thin so far: the CLM-8B README reports 38 held-out DeepSWE tasks and 30 held-out Terminal-Bench 2.1 tasks, so 81.6 percent is 31 of 38, and the results are self-reported.
Which one should you use for each task?
Use the lab below. Pick a task and see which tool fits and why.
The rule behind the lab is short. Ask three questions about a step:
- Is the answer one of a known list? If not, use an LLM.
- Does the step run often, or on a latency budget? If yes, a decision model is worth testing.
- Is the list long and reused across calls? If yes, a CLM-style matcher with cached actions is the strongest fit.
| Task | Best fit | Why |
|---|---|---|
| Write a customer reply | LLM | New prose |
| Route 50 tickets per second to 6 queues | Decision model | Closed list, high volume |
| Choose the best of 5 generated patches | Decision model as verifier | Generate with an LLM, select with a fast scorer |
| Plan a 40-step migration | LLM | Open-ended reasoning |
| Flag prompt injection in tool output | Decision model | Yes or no on every call |
| Choose among 300 tools | CLM-style matcher | Many reusable candidates |
| Summarize a contract | LLM | Long-form generation |
How do they work together in one pipeline?
The strongest pattern is not "pick one". It is LLM for the creative step, decision model for the repeated step.
A coding-agent example:
- A decision model reads the task and routes it to a queue or a model tier.
- An LLM generates several candidate patches.
- A CLM-style verifier scores the candidates and picks one.
- A decision model gates the result with checks such as "does this touch secrets?".
- An LLM writes the pull request description.
This is the structure behind the CLM-8B verifier results. A strong generator produced candidates (Opus 5 for DeepSWE, Fable 5 for Terminal-Bench 2.1) and the fine-tuned CLM picked among them, lifting DeepSWE from a 73.7 percent pass@1 baseline to 81.6 percent. The lift came from selection, not from a smaller model beating a bigger one. For the pattern in practice, read cheap verification checkpoints for agent pipelines and Jev-style agent routing.
A prompt shape that works for any decision step, whichever model you choose: give the state as a short factual paragraph, give each option a label plus one sentence of mutually exclusive criteria, and ask for nothing else. Ambiguous option text is the leading cause of a weak pick, because the model matches meaning, not your intent.
What are people asking?
Should I just ask my LLM to classify? For low volume, yes. It is simpler and you already have it. Move a step to a decision model when volume, cost or latency becomes the problem, and compare accuracy on your own labeled examples before switching.
Is a CLM better than Jev? Not across the board. On the published zero-shot charts CLM-8B is faster, while Jev is a bit more accurate on tool calling and WikiRacing. As a verifier after light fine-tuning, CLM reported higher scores on two small benchmarks. Which is better depends on your task, your hardware and whether you can self-host.
Can I run these locally? Several can. CLM-8B is Apache 2.0 and needs Linux, Python 3.10 or later and an NVIDIA GPU. Open decision models include Strands Decider 2B and GLiNER2.5-Decide, and Ollaya is a local runtime for them.
Do they replace classic classifiers? Partly. A decision model behaves like a zero-shot classifier with typed output and no training set required. A classic classifier trained on your data can still win on a stable, well-labeled task. The decision model's edge is that you can change the options by rewriting text.
What does this mean for what you build or pay?
If your agent makes many small choices, review your logs for steps where an LLM returns one of a few labels. Those steps are the candidates to move. Keep the LLM for generation and planning. Budget a small labeled test set for each moved step so you can measure accuracy and calibration before you cut over, and keep a fallback to the LLM for low-confidence cases.
Bottom line
Do not choose between an LLM, a CLM and a decision model. Choose a model per step. Use an LLM when the output is new text or open-ended reasoning, a decision model when the output is a pick from a list, and a CLM-style matcher when that list is long and reused. Most real pipelines use two of the three.
Prices, latencies and benchmark figures are vendor or author claims reported between September and November 2026, were accurate as of the publication date, and may change.
Related reading
- What is a Contrastive Language Model (CLM)?
- What are decision models? A practitioner guide
- Top 10 decision models ranked
- Clairic vs Jev vs OpenAI Decisions vs Clef vs Microsoft-Decision-1
- What is a System One model?
- CLM-8B launch coverage
- How does Jev work? RLCD explained
- Cheap verification checkpoints in agent pipelines