Basal-omni: a decision model you can run yourself
What it is, why it leads JevBench’s open-weights board, and where it belongs in an agent stack. One engineer, an open base and 640,000 typed decisions — and a probability that is still not a permission.
Basal-omni is a family of open-weights decision models built by Remigiusz Kinas. Its largest member, basal-omni-1.0-ultra (31B), took first place on JevBench’s open-weights board on 17 October 2026 with a Capability Score of 82.5 — ten accuracy points ahead of TypeSafe’s Jev at equal calibration. It is not a chatbot. It reads a text or an image, takes a question with a fixed list of allowed answers, and returns a calibrated probability for each answer in one forward pass. That makes it a fast, self-hostable controller for routing, triage, compliance checks and agent next-step decisions. Below: what it is, how to read the benchmark without the headlines, what hardware you need, and how its shipped error thresholds map onto a consequence ladder.
Five weeks ago we wrote that the agent stack is growing a reflex layer: a tier of models that return a typed decision with a probability instead of a sentence, and that TypeSafe’s Jev had named the category without publishing weights. We said the weights would catch up in public, fast. On Saturday 17 October, at nine in the morning Warsaw time, they did — from a direction nobody in the category was watching.
A 31-billion-parameter model fine-tuned by one person, after hours, on an open Google base, went to the top of the open-weights board of JevBench, the one third-party leaderboard the category has.[1] Two Polish outlets ran it as a national win.[10][11] It is one, but that is the least interesting thing about it. The interesting things are what the model actually does, which parts of the result survive a careful reading, and what a team that runs agents should do with a decision model it can host on its own GPU.
- 01What basal-omni is, and what it is not
- 02Reading the JevBench result properly
- 03Werdykt: the author’s own benchmark
- 04Why this is more than a Polish success story
- 05Where it sits in an agent stack
- 06Six jobs, four non-jobs, and the hardware
- 07A rollout for a business team
- 08Who built it, and what to watch
01 · What basal-omni is, and what it is not
If your mental model of an AI model is ChatGPT or Claude, it is the wrong model for basal-omni. Those are generative: you give them a prompt and they write. Basal-omni belongs to the class TypeSafe calls System One models, after Kahneman’s fast, intuitive thinking,[8] and the neutral name is a decision model. The contract has three parts.[3]
- State in. A customer email, a contract clause, a retrieved passage, an agent trace, a web page as JSON — or, for the omni line, an image such as a photographed receipt.
- Typed question in, with the allowed answers spelled out by your application, per request. The next request can describe a completely different process.
- Calibrated probabilities out. One number per allowed answer, in one forward pass, no text generated. The answer can never fall outside your list, and the probability says how sure the model is.
The project site calls it an intelligent IF / CASE statement: a classifier that is redefined on every call.[4] You do not train a new model per category list; you describe the categories in the request. That is why the right comparison is Jev, not GPT, and why the “beats OpenAI and Microsoft” headlines need the reading in section 02.
Six question types, one call — the whole surface area of the model
The family at a glance
Basal is two lines served by one open inference engine through a single endpoint, POST /v1/systemone. You can swap the model without changing the integration.[4][5] Everything is Apache 2.0, published on Hugging Face and GitHub, and answers in Polish and English.
| Model | Base | Params | Inputs | GPU memory, approx. | Status |
|---|---|---|---|---|---|
| basal-2.0 mini / 4.5B / max | Bielik v3 (SpeakLeash) | 1.5B / 4.5B / 11B | text | NVIDIA GPU, Mac via MLX, or Ollama | Main text line, released 14 Oct 2026 |
| basal-omni-1.0-mini | Gemma 4 (E4B) | ~4B effective | text, image, audio ≤ 30 s | ~16 GB | Experimental |
| basal-omni-1.0-max | Gemma 4 | 12B | text, image, audio ≤ 30 s | ~24 GB | Experimental |
| basal-omni-1.0-ultra | Gemma 4 31B-it | 31B | text, image (no audio) | ~62 GB bf16 on an 80 GB card; FP8 ≈ 33 GB, text only | Experimental · JevBench #1 open weights, 17 Oct 2026 |
↔ scroll table · sizes and memory from the project site and the model card[3][4]
Two details from the model card are worth carrying forward. Ultra was trained on text decisions only; its image reading is inherited zero-shot from Gemma 4’s own encoder, and the author says so plainly. And the whole line is labeled experimental, with a request to validate it on your own documents before relying on it.[3] Hold both thoughts; they decide what the benchmark result is worth.
02 · Reading the JevBench result properly
JevBench is a leaderboard for decision models published by Benchmark Heaven, a third-party site that also compares general models on cost and capability.[1] It is not TypeSafe’s. Each system answers 1,500 decisions — 1,200 of them sealed, so they cannot leak into training data — and is scored on four axes: Intelligence (accuracy, corrected for guessing), Calibration (whether the reported probabilities match how often the system is right), Speed and Cost.
Two things about the board’s construction change how every headline should be read. First, Capability Score, the number in the news, is the average of Intelligence and Calibration, and only Jev-class systems are ranked on it: those costing at most twice, and answering at most twice as slowly as, the Jev 1.13.0 reference. Second, open-weights models and hosted APIs are ranked on separate boards. There is no single table on which basal-omni is “second overall”; there is an open board it leads and an API board it is not on.[1][2]
Two boards, one cap — Capability Score, read 20 October 2026
The numbers behind the bars
| System | Board | Intelligence | Calibration | Capability | $ per 1,000 |
|---|---|---|---|---|---|
| basal-omni-1.0-ultra | open weights, #1 | 74.1 | 91.0 | 82.5 | 0.045 est. |
| Quyet-1.0-Large | open weights, #2 | 73.4 | 90.0 | 81.7 | 0.045 est. |
| Jeff-1.0-Large | open weights, #3 | 71.9 | 91.1 | 81.5 | 0.049 est. |
| kettei-fat (Sqwish) | API, #1 | 79.8 | 92.8 | 86.3 | 0.026 est. |
| d1-ultra (Liquid AI) | API, #2 | 69.7 | 91.3 | 80.5 | 0.018 est. |
| Jev 1.13.0 (TypeSafe) | API, reference | 63.6 | 90.6 | 77.1 | 0.032 |
| Jev 1.14.0 (TypeSafe) | API, #6 | 59.9 | 90.1 | 75.0 | 0.032 est. |
| OpenAI Decisions (gpt-6-luna) | API, #11 | 56.9 | 90.1 | 73.5 | 0.052 |
| Microsoft-Decision-1 (Azure) | API, #13 | 57.2 | 84.4 | 70.8 | 0.019 |
| GPT-6 Luna, low reasoning | API, unranked | 96.6 | 99.0 | 97.8 | 0.11 |
↔ scroll table · board v1.7.46, read 20 October 2026[1][2]
Three readings follow from the table, and they are not the three in the headlines.
1. The gap to Jev is accuracy, not calibration. Basal-omni scores 74.1 on Intelligence against 63.6 for the Jev 1.13.0 reference — a 10.5-point lead — while both sit at about 91 on Calibration. In plain terms: it picks the right answer more often and is just as honest about when it is unsure. The newer Jev 1.14.0, measured on the same draw, is lower still at 59.9.
Where the ten points live
2. It leads the open board by a hair, and the field is tight. 0.8 points over Quyet-1.0-Large, 1.0 over Jeff-1.0-Large, both also on 31B Gemma 4 bases. This is a leader, not a runaway, and the board moves. Its own FAQ text still named Quyet the open-weights leader on the day we read it, from an earlier board version.[1]
3. “Beats OpenAI and Microsoft” is true only inside the Jev-class box. OpenAI Decisions and Microsoft-Decision-1 do score below basal-omni on Capability, but they are on the other board. And a plain GPT-6 Luna call at low reasoning effort scores 97.8 on the same page — at $0.11 per 1,000 decisions, outside the cost cap, so it is shown and not ranked.[2] Basal-omni wins the fast and cheap category. That is exactly the category a controller has to win, and it is a smaller claim than the one circulating.
The cost advantage is not per decision. JevBench estimates basal-omni at $0.045 per 1,000 decisions on rented GPU — 1.38× the Jev reference, inside the cap but costlier — against $0.032 listed for Jev 1.13.0. Its advantage is zero license fees, no per-call tariff and data that never leaves your hardware, not a lower per-call number.[1]
Self-hosted latency is estimated. The board times open models on its own GPU over loopback (basal-omni: 102 ms p50) and adds a flat network assumption for the ranking; API latency is measured end to end. The two are not directly comparable, and the board says so.[1]
The row is young. Basal-omni was scored on a question draw from 12 October that is still being anchored against earlier ones; the methodology notes that such rows are, if anything, understated. The benchmark measures one task type — choosing from a list — and says nothing about chat, writing or coding.[1]
03 · Werdykt: the author’s own benchmark
Separately from JevBench, Kinas publishes Werdykt v1: 5,000 hidden decisions in ten categories, Polish and English, run under one protocol against his own models and a set of outside references.[4] It is the author’s benchmark, so treat it as a second opinion rather than an independent one; it is still the only place the whole family is measured side by side with a frontier generative model doing the same job.
Accuracy, cost and latency on Werdykt — what a frontier model costs for the same decision
Two things stand out. The obvious one: a frontier generative model is better at the task — 99.6% — and costs about fifty times more per decision and a hundred times more in latency, which is the entire argument for a decision layer in one row. The less obvious one is in the model card. Ultra’s weakest Werdykt categories are rules with exact thresholds and dates (0.550), contracts (0.822) and long documents (0.854). The author’s advice is blunt: compute exact arithmetic in code, not in a one-pass model.[3] That is the same failure mode the first independent write-up found in Jev, and it is a property of the class, not of this member.
04 · Why this is more than a Polish success story
Basal-omni was built after hours, by one person, with no grant, no national program and no corporate backing — on top of Google’s open Gemma 4 31B, with LoRA fine-tuning on roughly 640,000 typed decisions and soft targets distilled from the earlier Bielik-based basal-1.5.[3] The text line, basal-2.0, stands on Bielik v3, the Polish open model whose technical reports Kinas co-authored.[9]
For scale: on 9 October, eight days before ultra shipped, TypeSafe AI announced it had raised $870 million at a $7.5 billion valuation, led by Andreessen Horowitz with Sequoia and DCVC, four weeks after launching Jev.[6][7] One engineer with a good base model and a disciplined data recipe then out-scored the category creator on its own benchmark’s accuracy axis.
We say this to clients regularly and it is rarely welcome: nobody in Europe out-spends Silicon Valley or Beijing on frontier compute, and nobody should try. But the layers that make an agent governable — the decision layer, the verification layer, the routing layer — are bounded problems with bounded data. They are winnable by small teams, and basal-omni is now the proof point we will point at.
05 · Where it sits in an agent stack
In every agentic system we design there is a component we call the controller: the part that decides what happens next — which queue, which tool, which person, whether to proceed at all. Today that layer is usually either hard-coded rules, which are brittle, or a full generative call, which is slow, expensive and not calibrated. A decision model is the natural owner of it. In the vocabulary of agent-first architecture, it is the component that owns the bounded decisions, and nothing else.
The controller, with a decision model in it
The threshold is the important part, and basal-omni ships something most decision models do not: certified ones. Its CALIBRATION.json carries confidence thresholds fitted for 1% and 5% error among the decisions accepted above them. On the held-out test, the 1% threshold auto-decided 56.8% of cases with an observed error of 0.47%; the 5% threshold auto-decided 94.2% at 3.8%.[3] That is a trust architecture you can put in front of a risk committee, provided you do the one thing the author asks: refit it on your own data.
It also maps directly onto the Action Heat Ladder, where the consequence of an action decides who pulls the trigger. Consequence sets the band by design; confidence moves behavior inside the band at runtime; confidence never promotes an action to a hotter band. With two certified thresholds, that rule becomes a table.
Two certified thresholds on three rungs of the ladder
A certified 1% threshold means that among the decisions the model accepts, about one in a hundred is wrong. It does not say which one. For a low-heat action that is a cost of doing business; for an action that binds money, one in a hundred is a hundred incidents a quarter at modest volume. The number belongs in the AI agent operating model as a parameter per action, with a named owner — never in a prompt, and never as a replacement for the mandate.
06 · Six jobs it does well, four it should not do, and the hardware
Six concrete jobs
- Inbox and ticket triage. One email, several questions in one call: which team, urgency one to five, which topics. The project’s own banking example returns the department and a “customer blocked: yes” with probabilities and no prose.[3][4]
- Document routing and field decisions. Which document type is this scan — order, delivery note, invoice, other? Was it paid by card? What is the highest VAT rate on the receipt? Ultra reads rendered documents almost as well as their text (0.894 against 0.931 on the author’s probe), and 12.5 points better than untrained Gemma 4. Phone photos, by contrast, gained nothing from the text training.[3]
- Policy and compliance checks in plain language. “Is the damage report missing?” → yes or no, against a rule you wrote in a sentence, with no classifier to train.[4]
- RAG grounding and answer verification. Does this retrieved passage answer the question? Is the generative model’s answer covered by the source — fully, partly, not at all? This is the cheapest guardrail you can put between an LLM and a user, and the basal 2.1 engine exposes it as a
verifytask.[4] - Agent next-step and tool selection. Given OpenAI- or MCP-style tool definitions, which tool applies — or “no suitable tool”, or “ask the user”? In the author’s test ultra answered “no suitable tool” correctly on four of six out-of-scope requests and sat near a coin flip on one. Good, not perfect: route the uncertain band to a person.[3]
- Judging other models’ outputs. Ordinal scores and pairwise judgments. Ultra scored 0.700 on JudgeBench against 0.600 for the 12B sibling.[3]
Where not to use it
- Anything that needs exact arithmetic, dates or numeric thresholds. Compute those in code and pass the result in as state.[3]
- Writing of any kind. Pair it with a generative model: basal decides the path, the LLM writes the email.
- Audio on ultra, which has no audio encoder. Use omni-mini or omni-max for recordings up to 30 seconds; on the author’s probes mini reads recordings better than max.[4]
- Consequential decisions about people without review. The model card says so.[3] So do we.
Hardware and deployment
What each tier needs, in GPU memory
| Tier | Card in the test | Latency, one question | Throughput, 32 clients | Note |
|---|---|---|---|---|
| basal-omni-1.0-ultra | one H200, bf16, eager | 80 ms p50 · 188 ms p95 | 8.6 decisions / s | FP8 checkpoint runs text-only on vLLM |
| basal-omni-1.0-max | one H100, bf16, eager | 66 ms p50 | 19.0 decisions / s | images and audio |
| basal-1.5-max (11B) | fast engine | 27.3 ms p50 | 33.4 decisions / s | the previous text line, for scale |
↔ scroll table · one question per request, one option order; asking both orders costs about twice as much[3]
For a triage queue that is thousands of decisions a minute on one card. And the line that matters for regulated clients is the shortest one in the documentation: weights run on your hardware, and inference needs no external API.[4] For a bank, an insurer or a public body, that sentence is the whole procurement argument.
Quick start, text
# 1. environment (uv)
uv venv --python 3.12 --allow-existing ~/basal-env && source ~/basal-env/bin/activate
uv pip install torch==2.11.0 torchvision==0.26.0 --index-url https://download.pytorch.org/whl/cu128
uv pip install "basal[media] @ https://github.com/rkinas/basal/archive/refs/tags/v2.2.0.tar.gz"
# 2. serve
basal-serve --model Remek/basal-omni-1.0-ultra --mode eager --media on --port 8000# 3. ask: one state, two typed questions, one call
curl -s localhost:8000/v1/systemone -H 'content-type: application/json' -d '{
"state": "Customer: since yesterday I cannot log in to online banking, the system shows a password error.",
"questions": {
"dept": {"type": "choice", "instructions": "Which department should handle this?",
"criteria": {"cards": "Card complaints", "online": "Online banking support", "loans": "Loans"}},
"urgent": {"type": "noul", "instructions": "Is the customer unable to use the service?"}
}}'For images, add a "media" array with base64 data and set "lang"; the same questions work over a photographed invoice. Note that the answers come back tagged "calibration": "text" — the thresholds were fitted on text, so validate them on your own images before automating on them.[3]
07 · A rollout for a business team
The temptation with a model this cheap to run is to wire it into everything. The sequence that works is narrower, and it is the same sequence we use for any Process Brain: one decision, one evaluation set, one threshold, one shadow period, then autonomy by heat level.
Six steps from a labeled export to auto-approval
Step five is where most pilots should spend longer than they want to. A shadow controller produces the one dataset nobody has at the start — where the model and the person disagree, and who was right — and that dataset is worth more than any benchmark in this article. It is also the evidence an AI agent readiness assessment asks for before anything is allowed to act on its own. The wider sequence — vision, ownership, processes, stack, trust — is in Five Steps to Becoming an Agentic Organization; this is the processes layer of it, on one decision.
08 · Who built it, and what to watch
Remigiusz “Remek” Kinas is the sole author of the basal model family and its inference engine, published under the ai5 label, and a co-author of the Bielik v3 technical reports, where he is credited with conceptualizing and coordinating the reinforcement-learning training, data preparation, benchmarking and quantizations for the SpeakLeash team.[3][9] The first basal-2.0 and basal-omni models were released on 14 October 2026; ultra and the 2.1 engine followed on 17 October, and the 2.2 engine with calibration on your own data on 19 October.[4]
The honest list of open questions is short.
- Calibration on your documents. Every figure above is the author’s or the board’s test set. Three hundred labeled cases from your own traffic will tell you more than this article, and the 2.2 engine now makes that a one-afternoon job.
- Images, properly. Ultra’s image reading is zero-shot from the base model. The author says media training comes in the next releases; until then, rendered documents are good and phone photos are not.[3]
- The board after the next draw. Basal-omni’s row is from a question draw still being anchored, with two 31B rivals within a point. The ranking on 20 October is a snapshot, not a settlement.[1]
- Whether your platform can host it. A decision layer needs a GPU it is allowed to use, permissions it cannot exceed and evidence of what it decided — the test in agent-first platform, and one an open checkpoint does not pass by itself.
The AUX takeaway
Five weeks ago the question was whether the decision-model category would exist outside one vendor’s API. It now exists as an Apache-licensed checkpoint you can run on one card, with certified thresholds and a calibration workflow for your own data. What has not changed is the rule that makes any of it safe to deploy: the model estimates, the system governs. A probability above a threshold is permission to act only on the rungs of the ladder where design put that permission in advance.
Code where certainty exists. A decision model where the answers can be listed. A generative model where something has to be written. A person where consequence demands judgment.
Basal-omni does not change that assignment. It makes the second line of it cheap, local and, for the first time, open.
Terms used here
- Decision model
- A model whose output space is declared in the request: it reads a state and a typed question with allowed answers, and returns a probability per answer instead of generating text. TypeSafe calls the class System One models; basal-omni is an open-weights member of it.
- Typed question
- A question whose answer type is fixed in advance: choice (one option from a list), noul (a yes/no probability), score (an ordinal value), and in the basal engine also multi, act and tool. The answer can never fall outside the declared options.
- Calibrated probability
- A reported probability that matches observed frequency: of the decisions a model scores 0.9, about 90% should be right. Basal-omni ships per-type temperatures that make its probabilities calibrated on the author's text data; calibration on your own documents has to be checked separately.
- Certified threshold
- A confidence cut-off chosen on calibration data so that the decisions accepted above it carry a target error rate, such as 1% or 5%. Basal-omni ships two in its CALIBRATION.json; the basal 2.2 engine can fit new ones on a team's own labeled examples.
- JevBench
- A third-party leaderboard for decision models run by Benchmark Heaven. Each system answers 1,500 decisions (1,200 sealed, 300 public) and is scored on Intelligence, Calibration, Speed and Cost. Open-weights models and hosted APIs are ranked on separate boards.
- Jev-class
- JevBench's eligibility rule for its Capability ranking: a system counts only if it costs at most twice and answers at most twice as slowly as the Jev 1.13.0 reference. Systems outside the caps are shown but not ranked.
- Controller
- auxfirst's name for the component of an agent that decides what happens next: which queue, which tool, which person, whether to proceed at all. A decision model is the natural owner of that layer; the consequence of each action is still set by design.
Questions people are asking this week
What is basal-omni?
Basal-omni is a family of open-weights decision models built by Remigiusz Kinas on Google's Gemma 4. A decision model does not write: it reads a text or an image, takes a question with a fixed list of allowed answers, and returns a calibrated probability for each answer in one forward pass. The largest member, basal-omni-1.0-ultra (31B), was released on 17 October 2026 under Apache 2.0 and works in Polish and English.
Is basal-omni a Polish AI model?
The author and the decision fine-tuning are Polish, and the training data is Polish and English. The ultra base is Google's Gemma 4 31B, and the separate basal-2.0 text line is built on Bielik v3, a Polish open model. Every model answers typed questions in both languages.
Can I chat with basal-omni like ChatGPT?
No. It cannot generate text. Your application sends a state plus one or more typed questions with their allowed answers, and the model returns a probability per answer. To write an email or a summary you still need a generative model; basal-omni decides the path, scores the input or checks the result.
Is basal-omni a Jev alternative?
Yes. It answers the same typed questions, and on JevBench it scores 74.1 on Intelligence against 63.6 for the Jev 1.13.0 reference, with calibration level at about 91. The difference in kind: Jev is a hosted API, basal-omni is open weights you run on your own hardware. JevBench ranks the two on separate boards, open weights and API, so the comparison is between rows, not a single ranking.
Is basal-omni cheaper or faster than Jev?
Not per decision at the leaderboard's prices. JevBench estimates basal-omni-1.0-ultra at $0.045 per 1,000 decisions on rented GPU against $0.032 listed for Jev 1.13.0, and its self-hosted latency is estimated, not measured end to end. The cost advantage is different in kind: no license fee, no per-call tariff and no data leaving your infrastructure. For a workload that already owns a GPU, the marginal decision is close to free.
What hardware do I need to run basal-omni?
basal-omni-1.0-ultra needs one 80 GB GPU in bf16 (about 62 GB for the weights); an FP8 checkpoint of about 33 GB runs text-only on vLLM. basal-omni-1.0-max (12B) needs about 24 GB and basal-omni-1.0-mini (4B) about 16 GB. The basal-2.0 text models also run on Apple Silicon through MLX and through Ollama or llama.cpp.
What is JevBench and who runs it?
JevBench is a third-party leaderboard for decision models published by Benchmark Heaven, a site that also compares general models on cost and capability. Each system answers 1,500 decisions, 1,200 of them sealed, and is scored on Intelligence, Calibration, Speed and Cost. Its Capability Score averages Intelligence and Calibration for systems within twice the cost and latency of the Jev reference. Open-weights models and hosted APIs are ranked on separate boards.
Is basal-omni production-ready?
The author labels ultra experimental and asks users to validate it on their own documents. auxfirst's reading: ready today as a shadow controller that decides while a person still acts, and ready as an auto-approver for low-consequence decisions once a team has fitted confidence thresholds on its own labeled cases with the basal 2.2 engine. High-consequence decisions stay with a named person whatever the probability says.
Method · Every source was fetched and read on 20 October 2026. Leaderboard figures are from JevBench board v1.7.46 on that day and will move; model-card figures are the author’s own measurements and are labeled as such; Werdykt is the author’s benchmark and is presented as a second opinion, not an independent one. The outputs in Figure 1 are illustrative, and the threshold-by-heat table in Figure 6 is auxfirst’s reading built on the Action Heat Ladder, not a published standard. The TypeSafe funding figures are as reported by TechCrunch and confirmed on TypeSafe’s own blog. Where a claim in circulation could not be traced to a source — a per-decision cost advantage over Jev, a latency multiple — it was left out rather than repeated.