Most of the models Coolhand tracks are LLMs: you send them text, they generate text back. A System One model works differently. You give it some state and a set of named, typed questions, and it returns typed answers — a category, a boolean, a score — each with a probability. It never writes a sentence.
TypeSafe's Jev is the first System One model — and represents a new type of AI model "primitive" that Coolhand is excited to help you analyze and leverage in your AI & agentic workflows.
What a System One request looks like
An LLM request is a conversation: a system prompt, a messages array, and a generated completion you then have to parse and validate. A System One request is a form.
Conceptually, you send:
- a state — the thing being judged, as text
- a set of named questions, each with a declared answer type
and you get back one typed answer per question, with a confidence attached.
Classifying an inbound support email, for instance, is one state (the email) and two
questions (intent, one of a fixed set; urgent, a boolean) answered in a single
pass. See TypeSafe's API documentation for the exact
request format — Coolhand does not wrap or proxy the call, it records it.
Because the answer types are declared up front, the shape of what comes back is guaranteed. There is no "please respond with JSON only," no retry when the model opens with "Sure! Here's the classification," and no parser to maintain.
How the three compare
| LLM | System One model | Custom ML model | |
|---|---|---|---|
| What it returns | Generated text you parse and validate | Typed values matching a schema you declared, with probabilities | Typed predictions with probabilities |
| How you steer it | A prompt, in prose | Named questions with declared answer types | Labeled training data, then retraining |
| Implementation effort | Lowest — write a prompt and call it | Low — declare your questions and call it | Highest — label a dataset, train, evaluate, deploy, then monitor for drift and retrain |
| Cost | Per input token and per output token — the most expensive per call | Per input token; output is free | Near-zero per call, but real fixed cost in labeling, training and ML engineering time |
| Latency | Highest — tokens are generated one after another | Low — every question is answered against the state in one parallel pass | Lowest — a small purpose-built model can answer in milliseconds |
| Accuracy on a narrow task | Good, with no training data required | Good and calibrated, with no training data required | Potentially the highest — but only once you have enough labeled examples |
| Specialized or domain-specific tasks | Handled by putting context in the prompt | Handled through the state and each question's criteria. Jev is not fine-tuned on your data; the same weights serve everyone |
Strongest — it learns your domain's idiosyncrasies from your own labels |
| Can it explain itself? | Yes — reasoning, citations, prose | No. You get the answer and a confidence, not an argument for it | No natural-language rationale |
| Conversation | Multi-turn, with history | None. Each call is self-contained | None |
The three aren't strictly alternatives — TypeSafe documents using Jev's probabilities as labels to train a downstream classical model, which turns the middle column into a cheap way to reach the third without hand-labeling a dataset first.
The pricing difference is the reason most teams will look at this at all. At current catalog rates, Jev 1.13 is $0.042 per million input tokens with free output, against $1.00 in / $5.00 out for Claude Haiku 4.5 — a model teams commonly draft into exactly this kind of work.
For a classification call carrying ~2,000 tokens of input and returning a one-word answer, that is roughly $0.0021 on Haiku 4.5 against $0.000084 on Jev — about 25× cheaper. Check the live figures for yourself in the inference API catalog; prices change and the catalog is what we keep current.
When to use an LLM
- The output is prose: a summary, a draft, a reply, an explanation.
- You need the reasoning, not just the verdict — a triage note a human will read, or a justification that has to hold up.
- The task is open-ended, or the set of possible answers isn't known in advance.
- It's a conversation, with state carried across turns.
- The input is large. Jev takes 64k tokens per request, with a tighter 32k budget for the state plus the longest single question — a fraction of what a modern LLM holds.
When to use a System One model
- High-volume classification, routing, tagging, scoring or sorting.
- The "job" is really one narrow judgment call, with a known set of answers.
- Latency or per-call cost is the binding constraint rather than answer depth.
- You want several independent judgments about the same input, and you'd otherwise make several LLM calls or ask for a compound JSON object and hope it holds.
Using both together
An LLM and a System One model aren't alternatives so much as different layers.
Triage, then generate. Use a System One model to decide what kind of thing an input is, and hand only the cases that need writing to an LLM. Most inputs never reach the expensive model.
Pull the decision out of the prompt. A long LLM prompt often contains one narrow question doing a lot of the work — which of these ten repos is this bug most likely in? — wrapped in a lot of instructions for the generation around it. That question can often move to a System One model, leaving the LLM a smaller job.
Route between models. A cheap decision layer picks which model handles the rest, so the expensive one only sees the requests that justify it.
What Coolhand records for a Jev call
Jev calls are ingested like any other provider, with three mappings worth knowing: the state is recorded as the user prompt, the questions as the system prompt, and the answers as the response. The provider specifics are in TypeSafe Best Practices; field-by-field detail for every provider is in What every field on an LLM request log means.
Beyond that:
- Jev logs are grouped as
system_one, a group of their own, so they don't get mixed in with ordinary chat templates. Similarity search scores both the state and the questions, because for a System One call the questions carry as much of the identity as the input does. - Evaluations and correctness scoring work normally on System One templates.
- Bakeoffs do not — Coolhand compares them a different way. A bakeoff swaps a different model in for the original, and an LLM can't stand in for a System One call, so System One models are excluded from bakeoff selection. To compare the two anyway, Coolhand translates the task into both shapes, runs the System One call over the same inputs your LLM saw, and scores both against your existing correctness evaluations and human feedback, alongside the cost and latency difference. See TypeSafe Best Practices.
- Some fields are always blank, structurally rather than by mistake: temperature, cached input tokens, reasoning tokens, and whether the response was truncated. TypeSafe's responses don't carry them.
- There's no provider request id. TypeSafe's response doesn't include one, so feedback on a Jev output can't use provider-id matching — the fastest and most reliable tier. Send the Coolhand request log id with your feedback instead. See What is feedback match rate?.
To find System One models through the API or an agent, filter the catalog on model type:
curl "https://coolhandlabs.com/api/v2/inference_apis?q[model_type_eq]=system_one"
The same filter is available as model_type on the list_inference_apis MCP tool.
Limits worth knowing before you commit
- It cannot write anything. If the step needs words, a System One model is at best half of the answer.
- It cannot explain itself. You get a confidence, not a rationale. If your workflow depends on showing a human why, that has to come from somewhere else.
- "Typed" is not "correct." A schema-guaranteed answer is guaranteed to be well-formed, not right. Run it against your own evals and your own feedback before you route real traffic through it.
- It holds much less than an LLM. 64k tokens per request, and only 32k for the state plus the longest single question — two separate budgets, so a long state with one verbose question can fail well before you approach 64k. Test with your longest real inputs.
Related
- TypeSafe Best Practices — what Coolhand captures for Jev calls, the request shape, rate limits, and which fields are always blank
- Jev: The Working Man's Classifier — why we think this category matters, and what we're building around it
- What every field on an LLM request log means — every field on a request log, and who leaves it blank
- What is feedback match rate? — how feedback gets linked back to the call that produced it