Typesafe recently released its first System One model, Jev. The model is designed not for chat/communication, but for fast, structured decisions. The crazy part is that Typesafe prices it at a tenth of the cost of a traditionally cheap model like Haiku 4.5 while Typesafe claims it performs at the same benchmarks as GPT 5.6 Terra and Sonnet 5. Each response comes with confidence scores and probabilities so you don't have to waste time with evaluating reasoning, and it eliminates format errors (though not judgment errors — it can still be confidently wrong). At $0.042/M input tokens and free output ("too cheap to meter" according to Typesafe), we might as well test it out!
The Setup
Our latest work has us running through article titles and doing some filtering/categorization so to test the model, I created a quick evaluation based on some known results. I ran it through both Haiku 4.5 and Jev. The flow we're implementing is processing articles about NFL teams into a graph database through two steps. First we want to do a quick pre-filter to eliminate articles that are just fluff pieces and likely don't contain any signal about players. The second step is we need to extract data from articles to populate our graph.
With Haiku, we have an output that can be structured and we can ask for an explicit "why" reasoning. However, we do risk higher levels of hallucination due to the nature of the output. Jev on the other hand gives us structured output as its only option. There are no free-text responses. And because every field needs its own question, I expected the cost to balloon past the savings. So how does it perform?
Layer 1: Title Triage
There's a constraint worth naming first: Jev batches many questions about one state, not many states per call. Three hundred titles means three hundred calls, and the full instruction set rides along on every one of them. Haiku does the opposite — I can pack fifty titles into a single prompt and send the instructions once.
That's a real advantage for Haiku, and it eats into the price gap. Per token Jev is roughly 24x cheaper on input, with output free. End to end on this workload, after paying to re-send the instructions 300 times, it came out 13x cheaper. Still lopsided, just not as lopsided as the sticker price suggests.
It also changes what you optimize. You can't batch, so throughput comes from concurrency — I run 12 requests in flight against a 1,200/min limit. And since you're paying for the instruction on every call anyway, additional questions are nearly free: asking all 14 of mine cost 1.5x what asking one did.
questions = {"triage": Choice(instructions=INSTRUCTIONS, criteria=CRITERIA)}
for name, instr in ALL_QUESTIONS.items():
questions[f"tag_{name}"] = Noul(instructions=instr)
resp = client.system_one(state=_state(row), questions=questions, model=MODEL)In the first layer - Jev dominates. We can easily pass in the title of the article and give a handful of possible tags/questions to Jev and get scores/probabilities assigned to each question. Choice picks one label from a set, while Noul returns an independent 0–1 score for each tag. Asking 10 dimensions costs roughly 1.4x what a single question does, so even with ten scored dimensions Jev is still ~9x cheaper than a batched Haiku request, and the output is significantly more useful.
The other thing you get is the full distribution, not just the winner:
"confidence": round(a.confidence, 4),
"p_drop": round(a.probabilities.get("drop", 0.0), 4),
# the full distribution, not just the argmax: an article at quote .45 /
# drop .40 is a different animal from one at quote .95, and both record
# as "quote" if we keep only the winner.
"probs": {k: round(v, 4) for k, v in a.probabilities.items() if v >= 0.005},Across 170 titles both engines classified, they agreed on keep/drop 83% of the time. Jev is the more generous of the two — it kept 116 where Haiku kept 97 — which suits us, since a wrongly kept article costs one cheap body read and a wrongly dropped one is gone for good.
Layer 2: Extraction
The second layer is where we see Jev's shortcomings. From each article that we process, we have a non-deterministic set of questions that we want to ask. We want to extract injury severity, player quotes, name relationships, etc. The articles could include multiples of this type of output. So we need to know who we're asking questions about first - which player or coach is mentioned and what is the article saying about them? Extraction will emit a variable length array of rows, but Jev only answers a fixed question set about a fixed state.
Here's the shape of a single row we're pulling out:
Each quote row:
speaker : name, or "" if unattributed
subject : the player or coach the statement is ABOUT
claim_types : array — availability | usage | evaluation | relational
specificity : generic | comparative | situational | concrete
hedging : committed | qualified | vagueN quotes per article, and N is unknown until you've read it.
There are several ways to iterate on this with Jev. I could take all the names that I think could be in this article and ask the questions about them. But this would significantly increase the token count used to parse the article, defeating one of the key wins from this model. I could do other types of pre-processing or do text matching for which of the players you know of are in the article, but there's too much complexity added by each option to be worth implementing.
Developing solutions with LLMs often gives you the nuance you need through what is generally a simple interface. So an increase in complexity tends to defeat the benefits.
Where else could you use Jev?
When developing against various LLMs and configurations, you often need to write an eval harness to ensure that your prompt consistently performs the way you expect. If I tell the LLM to write me a report on Josh Allen's performance in his win last night over the Lions, I need a way to evaluate that the output generally fits the style and doesn't hallucinate stats. Typically we would write a judge LLM and pass the output and a prompt for how the judge should evaluate the output (but who judges the judge?).
Jev's structured output is fantastic for this. When an LLM produces an output, you should be able to answer "does this output follow the prompt I gave it?" You might create specific scoring questions like "Does this hallucinate data?" Or "Did we extract fields A, B and C?". Each of these is a scorer and provided as a question to Jev. Using the confidence score and its structured output simplifies the flow significantly.
One caveat from running my own suite: the answers aren't deterministic. The same 18 pinned cases scored 18/18, 18/18, 17/18 on an unchanged prompt — roughly one borderline case flips per run. A single green run isn't proof a change worked. Score pass rates across repeats, not one run.
What Ships?
Jev wins at triage/categorization and evals, but it can't express the variable-length shape that extraction needs, so that step stays with a general-purpose LLM. Consider it the next time you reach for a Flash or Haiku model to be a simple filter over your inputs.