CLM chooses among answers you supply
Give CLM a support message and descriptions of possible departments, and it returns a choice with a distribution over those options. Give it candidate agent solutions, and it ranks them against the state. The README's Python interface makes that boundary visible through Choice, Noul, and Score question types. Our 46-file checkout contains a decision service and research code. You still need an application that supplies useful candidates and acts on the result.
Separating the state from the action lets CLM reuse representations of an unchanged action catalog. That fits a routing problem where departments stay fixed while messages change. It also fits selecting among solutions that another model has already produced. CLM cannot select an answer absent from that set. I would start with a narrow labeled decision problem, because a bad candidate list can make a confident ranking useless before the model itself enters the discussion.
What happened when we ran it
Our run installed CLM commit d5f9ef0 in 133 seconds, pulling 224 packages and occupying 8,153 MB on disk. The build passed in 5 seconds. We used an unprivileged Python 3.12 Bookworm container on October 12, 2026, with 3 CPUs, 8 GB of RAM, and no secrets. These measurements cover repository setup. They supply no inference benchmark or evidence of a working GPU encoder.
The lab skipped tests because it found no script or target. Pip-audit reported 2 known vulnerabilities, but the supplied results do not identify packages, affected versions, severity, or exploit conditions. Calling those findings harmless would be guesswork. So would calling them remotely exploitable. The scan found 1 CI workflow file, no Dockerfile, and no tests directory. None of those signals turns the skipped test step into a passing suite.
A small checkout expands into a large Python environment
The source checkout occupied 1.2 MB and contained roughly 6,793 source lines. After installation, the environment used 8,153 MB. That gap matters when you are budgeting a development container or deciding whether to try the project on a constrained machine. The short pip command in the README hides the size of the environment we measured. Reserve that disk space before considering any separate model assets the serving path requires.
A successful 5-second build settles a packaging question, while the quick start asks you to operate another process. Its Qwen3-8B encoder runs through vLLM, and the CLM API sends embedding requests to it. The projection heads can run on CPU or CUDA. CPU support for those heads does not make the documented encoder route a CPU-only service. Keep the encoder and head checkpoint matched, since the README says a head depends on its training encoder and pooling method.
Typed probabilities need task-specific validation
The API reference defines a choice distribution, an expected score over ordered levels, and a confidence value derived from the top probability and the others. Those are precise response formats, but they do not establish calibration against your own labels. A department selector needs examples of messages that belong to each department, including ambiguous ones. An agent verifier needs candidate solutions with outcomes you can check independently.
Our 224-package install and skipped tests provide no evidence about those decisions. The README publishes its own research results, which we did not reproduce in this sandbox. Its coding-verifier examples select from solutions produced elsewhere, so a useful comparison must include candidate generation as well as selection. Before replacing a simpler rule or reranker, compare both on the same labeled cases. A response containing probabilities is still a prediction that can be wrong.
Long-state truncation can remove the question
The README says states beyond the default token limit are truncated and explains how to raise both service limits. Open PR 29 reports a more specific problem: context precedes the question, and right-side truncation can remove the question itself. That is directly relevant to long agent histories. The proposed fix remains a proposal in the fetched queue, so I would check the deployed revision rather than assume it is included.
The sandbox's 8 GB of RAM describes our environment, not a serving requirement. More context also means more encoder memory, according to the README, so raising limits has an operating cost the package build never measures. There is another deployment distinction in issue 32: the Python health helper can report a live API while ignoring encoder failure. A readiness check should examine the encoder field or make a representative decision request before directing application traffic to it.
October activity shows work, while deployment reports remain open
The repository was pushed on October 5, 2026, and GitHub returned 3,001 stars and 28 open issues and PRs. Issue updates on October 8 concern readiness, encoder credentials, and score interpretation. That combination shows recent work and unresolved questions. The latest-release endpoint returned no release, which is insufficient evidence of abandonment. For this project, the commit and issue queue explain more about readiness than a missing release tag does.
Issue 22 reports weak Chinese choices, while issue 31 asks the service to expose a separate encoder API key. Both concern the current CLM package, and neither is a failure from our lab. With 2 audit findings and no executed test target, I would keep the first deployment isolated and use real labels from the intended workload. Choose CLM when candidate scoring is your actual problem, then require it to earn its place against the simpler selector you already have.