The 322M multilingual model returns typed answers and probabilities, but its 1,024-token limit makes compact inputs essential.
Listen
AI narration
10:47
0:00 / 10:47
AI SummaryGenerated from this article
AnyRouter now offers free API access to HAL-X's THX-01, a 322-million-parameter model that returns typed decisions with probabilities for classification, routing, and scoring across 18 languages. The model uses non-autoregressive scoring to select among named options or provide yes-or-no decisions, but its 1,024-token input limit—combining question, options, and state—requires compact inputs. Developers need an AnyRouter API key but face no per-request costs. Before automation, teams should validate calibration and confidence thresholds on their own data, as provider benchmarks don't guarantee accuracy across different queues, taxonomies, or languages.
Developers can now classify a short support ticket through AnyRouter for $0 per request, receiving a typed decision with probabilities instead of a generated reply. The new endpoint hosts HAL-X’s THX-01, a specialized model for tasks such as routing, classification, scoring, and agent control.
AnyRouter’s October 11, 2026 release lists the 322 million-parameter model as free, with no bring-your-own provider key required. Developers still need an AnyRouter API key, but they don’t have to run the weights themselves or connect a separate paid model account.
The practical attraction is a narrower interface than chat generation: supply the current state, define the question and permitted answer type, and receive a decision that software can act on. The main restriction deserves equal attention. THX-01 reads up to 1,024 tokens per question, and longer state is truncated.
That makes this release worth testing for compact operational decisions, not for passing an entire conversation or document into another general-purpose assistant.
Typed Decisions Fit Tasks With Defined Outcomes
THX-01 is a non-autoregressive model, according to the HAL-X model card. Rather than generating an answer token by token, it scores the available outcomes in a forward pass. Its published architecture combines an mmBERT-base encoder with a decision head.
AnyRouter exposes three question types:
choice selects among named options and supplies probabilities for those options.
noul expresses a yes-or-no decision as a probability of yes.
score returns an ordinal level and its probability distribution.
Those types cover a useful category of application logic. A support system might choose between billing and technical queues. A workflow might assess whether a message requires escalation. An agent controller might select the next permitted step from a predefined set.
For these jobs, an unrestricted paragraph creates extra work. The application ultimately needs a category, boolean-like assessment, or ordered score, not an explanation that must be interpreted afterward. A chat model can also produce structured output, but THX-01’s interface is built specifically around decisions and their probabilities.
It is a poor substitute when the actual task is drafting a response, explaining a complicated issue, or synthesizing a long record. A sensible division of labor is to use a decision model to select the route, then call a generative model only when that route requires generated text.
Work with Zeniteq
Let’s work together
We’re open to thoughtful collaborations with teams building in AI. Explore the ways we can work together.
AnyRouter says THX-01 was post-trained in 18 languages and supports more than 100. That broad coverage is relevant to multilingual queues, but it is a provider claim, not evidence of equal accuracy in every language or business domain. A deployment serving several languages should evaluate each important language separately.
Free Access Still Requires an AnyRouter Key
The AI pricing detail is straightforward: AnyRouter lists THX-01 at $0 per request, without requiring another provider’s key. Free pricing does not mean unauthenticated access.
The published request example uses bearer authentication with an AnyRouter API key. The dedicated endpoint is:
POST https://anyrouter.dev/api/v1/decisions
It is not a chat-completions request with a different model name. The request contains state, model, and a questions object describing the decisions to make.
Here is a server-side JavaScript call following AnyRouter’s request example, with an HTTP error check added:
const response = await fetch(
"https://anyrouter.dev/api/v1/decisions",
{
method: "POST",
headers: {
Authorization: `Bearer ${process.env.ANYROUTER_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
model: "hal-x/thx-01",
state: "I was charged twice this month.",
questions: {
category: {
type: "choice",
instructions: "What is this ticket about?",
criteria: {
billing: "billing issue",
bug: "software bug",
},
},
},
}),
}
);
if (!response.ok) {
throw new Error(`Decision request failed: ${response.status}`);
}
console.log(await response.json());
Set ANYROUTER_API_KEY in the server environment before running it. Keep that credential out of browser code and public repositories. The example prints the response rather than assuming an undocumented response layout or inventing a result.
The release also documents a native CLI route through anyr login followed by anyr decision --model hal-x/thx-01. Developers already using AnyRouter’s tooling can use that to explore the model before integrating HTTP calls.
The two-option example is intentionally simple. In a real ticket queue, billing and bugs will not cover every incoming message. Define options around the actual workflow, test ambiguous cases, and provide an application-level fallback when confidence is insufficient.
The release establishes launch pricing, not unlimited capacity or a permanent pricing commitment. It does not specify request quotas, a service-level guarantee, or data-retention terms. Those details should be checked before building a production dependency around free access.
The 1,024-Token Budget Includes the Question and Options
AnyRouter warns that the hosted model cuts longer state. The model card gives an important clarification: the 1,024-token input limit includes the question, options, and state together, for each question.
A developer should therefore not treat 1,024 tokens as an allowance solely for the source text. Long instructions and verbose category descriptions consume space that could otherwise hold evidence.
Consider a support workflow that sends a customer’s latest message, earlier correspondence, account details, and a lengthy routing taxonomy. Even if the latest message is short, the complete input can exceed the budget. If a decisive fact sits in material that gets truncated, the model cannot base its answer on that fact.
A safer design is to construct a compact decision record:
Include the current message and only the metadata necessary for that decision.
Keep question instructions and option descriptions concise and distinguishable.
Check the full input budget, rather than counting only the state.
Send oversized or incomplete records to a separate handling path.
Token counts are not interchangeable with word or character counts. Multilingual text makes a fixed character limit especially unreliable as a proxy. Leave headroom for the question and options instead of assuming that a short-looking record will fit.
For agent control, the state should describe the immediate decision: relevant tool results, current status, and available next actions. Passing the entire agent trace is a poor fit for this endpoint.
Summarizing a long record first is possible as an application design, but it introduces another failure point. If the summary drops the fact needed for routing, a well-formed answer from THX-01 does not repair that omission. The token limit should influence what the application sends, not merely how it trims an oversized payload.
Calibration Needs Validation on Your Own Decisions
HAL-X and AnyRouter describe THX-01’s probabilities as calibrated. The intended interpretation is that, across comparable predictions assigned a probability near 0.8, roughly 80% should be correct.
That is more useful for automation than an answer without a usable confidence measure. An application can accept sufficiently confident decisions and send the rest to a person or another model. The threshold becomes part of the operating policy.
But calibration is a population-level property. It does not establish that one particular ticket is safe to automate, nor does calibration measured on a provider’s evaluation automatically carry over to a different queue, taxonomy, or language mix.
Before setting a threshold, developers should collect representative examples with known outcomes and measure both classification accuracy and confidence behavior. Two practical questions matter: how often does the model make a wrong decision, and how many cases can the application automate at an acceptable error rate?
A hypothetical 0.95 threshold is only a starting policy to test. It is not a recommendation supported by this release. The cost of a wrong route also matters: misdirecting an ordinary product question is different from mishandling a security report.
For agent control, confidence should inform routing without replacing permission checks. A model’s probability that an action is appropriate is not authorization to execute that action.
Speed claims require similar care. The model card reports about 10 milliseconds for inference on one GPU, and AnyRouter repeats an approximately 10-millisecond figure. Neither establishes end-to-end latency for a hosted API call, which also involves network and service overhead. The supplied evidence contains no independent hosted latency or calibration benchmark.
Start With a Narrow Workflow and an Explicit Fallback
The most useful first experiment is a decision with short inputs, clearly defined outcomes, and existing labels against which to compare results. Support-ticket routing is a better starting point than a broad instruction such as “decide what the agent should do.”
Test normal cases alongside ambiguous messages, unfamiliar phrasing, multilingual inputs, and records approaching the token limit. Keep the returned probabilities and actual outcomes so that the application’s automation threshold reflects observed behavior rather than the model’s marketing description.
THX-01’s small size and free hosted access reduce the cost of that experiment. They do not remove the need to define the task carefully.
The release’s strongest practical contribution is access to a specialized decision component without a self-hosting project or another provider account. Whether it deserves a production role depends on how well it handles the application’s real boundaries: incomplete evidence, overlapping categories, unfamiliar inputs, and cases that should be deferred rather than confidently routed.
