Almost every model launch is a bid for the same job: produce better prose than the last one. Kev-4B is not doing that. It produces no prose at all. You hand it a state and some named questions, and it hands back numbers — the probability a statement is true, a choice from options you defined, a position on your own rubric. It is now live on Phala in beta.
Generating no text is a feature
It is a LoRA fine-tune of Qwen3.5-4B-Base with a pointer head that reads the answer out of a single forward pass. Because there is no decoding step, the answer cannot fall outside the options you supplied. If you ask for a choice among four labels, you get one of those four and a probability over all of them — never a fifth label, never a refusal, never a paragraph explaining itself.
Anyone who has tried to make a general chat model emit strict JSON for a classification task will recognise what is being removed here. The usual failure is not that the model is wrong, it is that it is unparseable: a stray apology, a markdown fence, a confidently invented category. Constrained decoding and retries paper over it. A pointer head makes it structurally impossible.
Three question types, each with a defined confidence measure. Bool returns p(yes). Choice returns the most likely option plus the full distribution, with confidence scaled against chance so that a coin flip across two options reads as zero rather than 0.5. Score returns an expected value over your levels, with confidence falling as the distribution spreads away from its mode.
The number that actually matters
The model card leads with accuracy: 83.8% on a locked out-of-distribution transfer set of 656 questions, 90.3% on a 936-question document set. Those are fine numbers. They are not the interesting one.
The interesting one is 70.1% coverage at 5% error. Read that as an operating contract rather than a benchmark: if you are willing to accept five percent mistakes, the model will confidently handle about seven in ten of your cases and decline the rest. The declined thirty percent is not waste — it is the queue you route to a bigger model, or to a person.
- •Coverage is a dial you set, not a property you receive. Tighter error budget, less coverage.
- •The 30% it declines is the valuable output: a defensible reason to escalate.
- •Those figures are self-reported at fp32, on their sets, not yours. Phala says to validate thresholds on labelled examples from your own workload, which is the correct advice and the part everyone skips.
This is the same shape as the problem a router solves. Antbase's own classifier runs a small model first and escalates to a larger one only when its confidence falls below a threshold — the whole design question is where to put that line. A model that reports calibrated confidence as its primary output is built for exactly that decision, rather than having confidence inferred from logprobs after the fact.
Confidential compute, and what it does not mean
Phala serves it inside NVIDIA Confidential Computing, so the prompt is encrypted in use and not merely in transit and at rest. For triage over documents that carry personal data, that closes a real gap: the usual objection to sending a case file to a hosted classifier is that the host can read it.
It does not, however, change what you are allowed to decide. Phala's own note is blunt about it — keep human review for consequential decisions about people — and that is not boilerplate. A calibrated probability makes a decision auditable; it does not make an automated adverse decision about someone appropriate. If the output affects a person's money, housing, employment or access to a service, the 30% the model declines is not the only part that needs a human.
Where this sits on Antbase today, honestly
It is in our catalogue as phala/jaredpalmer/kev-4b at $0.042 per million input tokens with free output, which matches Phala's announced pricing. What it will not do is answer a chat completion. We checked:
// POST /v1/chat/completions with model "jaredpalmer/kev-4b"
{
"error": {
"message": "no route available for model jaredpalmer/kev-4b",
"type": "model_not_found"
}
}That is not a misconfiguration, it is the design. Kev-4B serves a different contract — POST /v1/systemone, which takes a state and a set of named questions rather than a message array. An OpenAI-compatible proxy has nothing useful to do with a request shaped like that, and pretending otherwise would mean inventing a translation layer that silently throws away the probability distribution, which is the only reason to use the model.
So for now this is a direct-to-Phala integration, using their endpoint and the typesafe-sdk client. We have deactivated the catalogue entry for chat routing rather than leave a very cheap model sitting where a cost-weighted pool could pick it and get a 404 — that is the kind of entry that looks like a bargain to a router right up to the moment it fails.
Whether a typed-decision endpoint belongs behind a chat-completions proxy at all is a fair question, and we do not think the answer is obviously yes. If you are building triage on Antbase today, the honest recommendation is a small cheap chat model with a tight schema, measured against your own labelled set — and Kev-4B called directly when you want the distribution rather than a token.
When to reach for a decision model
The fit is narrow and worth stating plainly. You want this when the output is a label or a number, you have labelled examples to calibrate against, and you care about knowing when the model is unsure. You do not want it when the output is text, when your categories shift weekly, or when you have no ground truth — an uncalibrated confidence score is worse than no score, because it invites you to trust it.
