basal-1.0 — a dynamic classifier
An open classifier for Polish and English. How it works, what it can do and how long a decision takes — from a B300 server to a desktop HP ZGX Nano (Nvidia DGX Spark).
In many workflows, the most important answer is short: which team, how urgent, or whether the information collected is sufficient for the next step. These are the tasks behind basal-1.0 — a family of open decision models specialised in Polish, also supporting English.
You define the classifier dynamically in every request, according to your needs — without training the model for a new task. Provide context, a question and allowed answers; basal returns a probability distribution and a result in a defined format.
You can run the model locally, on your computer or infrastructure, without entrusting your data to another organisation.
One question, a concrete decision
Imagine a shared contact form for several teams. Send the message to basal, ask which department should handle it and describe the available queues. The response identifies one, with probabilities for the other options. That is enough for your application to route the case.
The model reads probabilities assigned to permitted answers, without generating text. The result stays within the defined set and is easy to use in code. By default, the engine evaluates two option orders and averages the results, reducing sensitivity to ordering.
choice- Choose one option. Which team, document category or agent tool?
noul- Probability of “yes”. Is the description complete? Does the text contain the specified condition?
score- Rate on a described scale. For example, urgency from 0 to 3. The response includes probabilities for each level and their expected value.
A question can have 2 to 10 options. The name basal refers to the basal ganglia, brain structures involved in action selection. The interface is described in the API documentation on GitHub.
Two sizes, the same interface
basal-1.0-4.5B is the highest-quality variant in this family. basal-1.0-1.5B needs fewer resources and usually makes decisions about twice as fast on the tested devices, at some cost to accuracy. Both use the same API and question types.
The label 1.5B means 1.5 billion parameters — the smaller model in the basal-1.0 family. FP8 and NVFP4 weight variants are also available; choose them according to hardware and acceptable quality changes.
The weights and inference engine are released under Apache 2.0. You can run the model on your own infrastructure and use it commercially under the licence terms. Model provenance and attribution requirements are described in LICENSE and NOTICE.
Polish specialisation visible in the results
On a set of 7,081 Polish test decisions the 4.5B variant reached 88.4% accuracy, and 1.5B 84.9%. The larger model scored 10.5 percentage points above the best of 11 compared open decision systems.
| Model | PL decisions | EN decisions |
|---|---|---|
| basal-1.0-4.5B | 88.4% | 74.1% |
| basal-1.0-1.5B | 84.9% | 73.4% |
| Jev 1.13.0 · API | 78.0% | 73.6% |
| AutoJev-27B | 77.9% | 75.3% |
PL: 7,081 examples; EN: 1,479. basal results use the engine in fast mode, averaging two option orders. Source: quality table in the README.
On English decision tasks, differences between basal-1.0-4.5B, Jev and the best open models fall within the report's 95% confidence intervals. On the general public English benchmark, however, basal-1.0-4.5B scores 74.0%, compared with Cygnet's 87.9%. Specialisation in Polish decisions does not imply an advantage on every task.
This evaluation uses generated, source-grounded or verified data. The test set was consulted during model development, which also matters when interpreting the results. Validate on your own examples before deployment. The full comparison is in the basal-1.0 technical report.
Milliseconds on the server and the desktop
In offline measurements, one 4.5B decision takes 8.8 ms on B300 in bf16 and 44.6 ms on HP ZGX Nano (Nvidia DGX Spark) (GB10) in FP8. The smaller model needs 18.1 ms on the same device.
| Device and mode | 4.5B | 1.5B |
|---|---|---|
| NVIDIA B300 · bf16 | 8.8 ms | 4.7 ms |
| NVIDIA H100 · bf16 | 12.5 ms | 6.2 ms |
| GeForce RTX 5090 · FP8 | 19.4 ms | 9.3 ms |
| HP ZGX Nano (Nvidia DGX Spark) (GB10) · FP8 | 44.6 ms | 18.1 ms |
Batch 1, both option orders, a private sample of 500 PL/EN cases. HTTP measurements include additional overhead: for 4.5B on B300 in fast mode, the median is 9.7 ms. Conditions and full hardware measurements.
Lower weight precision can improve speed but changes some decisions. In tests, FP8 changed about 2–4% of choices relative to the reference, while NVFP4 reduced accuracy by about 3 percentage points. Validate the mode and confidence thresholds together on your target hardware.
From message to the right queue
Start with one small task. Ticket routing, document categorisation, urgency assessment and selecting an agent's next tool are good examples. Make categories mutually exclusive and add an option for cases that do not fit the others.
After installing the engine and starting a local server , a Python call can look like this:
from basal.client import Basal
model = Basal("http://127.0.0.1:8000")
answer = model.choice(
"I cannot access my account after changing my phone.",
"Which queue should handle this ticket?",
{
"account": "Account access",
"payments": "Payments and billing",
"other": "Other topic",
},
)
print(answer["choice"])
print(answer["confidence"])HTTP exposes the same decision through POST /v1/systemone. Send state and questions; the response contains answers, including the choice, probabilities and confidence. The website also has TypeScript and cURL examples.
The application handles the next step: map a label to a queue, call an allowed function or route an uncertain case to a person. The catalog of 18 use cases provides ready-made input definitions and illustrative JSON responses.
Confidence helps. Verification still matters.
A high probability does not guarantee a correct decision. The engine calibrates each question type separately, but documented thresholds were validated for a specific input format. After changing descriptions, option-key visibility or weight precision, select a threshold on labelled examples from your process.
- Leave calculations to code. The model can get a sum, precise numerical boundary or complex rule wrong, even with high confidence. Supply computed values and break difficult assessments into simpler questions.
- Provide facts and current rules. A small model has limited knowledge. The
statefield should contain the information needed to decide. - Check known errors. The basal-1.0 documentation describes, among other things, an incorrectly learned notice-period case. Correcting a benchmark label does not automatically fix the model weights.
- Keep oversight of consequential decisions. Permission checks, action execution and cases with serious consequences for people remain the responsibility of the application and its operators.
The report also describes training-data provenance and traceability limitations. Before production use, read the full list of limitations and evaluate the model on cases relevant to your application.
Resources for your first deployment
Find more information in the basal-1.0 project documentation — from setup instructions and the API to detailed test results and hardware measurements.