CharmingGroot

TypeSafe AI's Jev and the System One Models Everyone's Talking About

ai-models4 min한국어

Korean version: 요즘 핫한 TypeSafe AI Jev와 System One 모델

TypeSafe AI unveiled Jev on September 15. Founder Diogo Almeida helped build the instruction-following methodology that underpinned ChatGPT at OpenAI, and for four years he’s been asking one question: “Models have been superhuman at chat for a long time now, so where did all the automation go?” Jev is the answer he’s shipping - the first public model in a new class TypeSafe calls “System One models.”

Why today’s LLMs don’t fit automation

Today’s LLMs are built for human-in-the-loop work - conversation, code generation. Wire one directly into a software pipeline to make decisions like “should this request be approved” or “which category does this item belong to,” and a few things get in the way.

  • The output is a string. You have to parse the answer to pull out the field you need, and the pipeline breaks if the format is off.
  • It’s slow. Tokens are generated one at a time in sequence, so a response can take anywhere from 3 seconds to over 5 minutes.
  • It’s expensive. Both input and output tokens are billed, and automation means calling this over and over at volume.
  • Confidence tends toward overconfidence. RLHF trains a model to produce answers humans will prefer - not to report its probabilities honestly.

TypeSafe’s framing is that these four problems are really one problem: using a chat-optimized model directly for automation is the wrong approach to begin with.

Jev returns typed probabilities, not sentences

TypeSafe describes Jev’s input-output relationship as “unstructured state in, typed probabilistic decisions out.” In practice, you send data alongside a list of questions whose types are already fixed. “Is this text spam?” gets a yes/no probability back; “which of these categories does it belong to?” gets one of your predefined options back, along with a probability. Because the answer always comes back inside the schema you defined, there’s structurally no way for a parsing failure or format mismatch to break the pipeline.

The name comes from Kahneman’s Thinking, Fast and Slow. The idea is to systematize fast, intuitive System 1 thinking into something you can actually trust.

How Jev differs from today’s LLMs

Today’s LLMsJev
Training objectiveRLHF (human preference) / RLVR (verifiable reward)RLCD (calibrated decisions)
Input emphasisSequential messagesStructured program state
OutputSequentially generated stringProbability distribution over defined options
SamplingSequential, token by tokenParallel, per question (single query)
Response time3-329 seconds70-500ms
Input token cost$0.20-$10/M$0.042/M
Output token cost~5x inputFree

Two things drive this. One is the parallel sampler: instead of generating each question’s answer sequentially, it pulls all the answers out of a single query at once, which is where the speed comes from. The other is RLCD (Reinforcement Learning for Calibrated Decisions): separately from getting the answer right, the training objective is making the probability itself honest - if the model says 90%, that prediction should actually be right about 90% of the time. Where RLHF optimizes for “an answer humans will like” and RLVR for “an answer a program can verify,” RLCD optimizes for “an answer whose probability is honest.”

How it’s actually being used

Two examples the company has published.

  • Doom: it looks at game state (text-structured data) and decides the next action in real time. Ten queries a second, at roughly $7 an hour.
  • Wikiracing: it picks the best path out of hundreds to thousands of links. Even at high cardinality - up to 255 options - every call still resolves to one of the defined choices.

TypeSafe built three new pieces of infrastructure for this kind of automation workload: a model architecture built for structured decisions, the parallel sampler, and the RLCD training methodology. Chatbots and copilots that need human interaction, verifiable problems like math proofs, and prototype demos, on the other hand, stay in today’s LLMs’ territory.

What kind of pipeline this actually fits

This model fits where the options are already fixed and the decision repeats. Spam filtering, content moderation, fraud detection - anything that asks “which category” or “risky or not” over and over, at volume, is the target. If you’re running an LLM in that kind of pipeline today, you’re stuck receiving the answer as a string, parsing it, and bolting on defensive logic to retry or fail when the schema doesn’t match. If Jev delivers what the company claims, the win in that spot is clear: parsing failures disappear structurally, response time drops from seconds to the low hundreds of milliseconds, and the probability attached to each decision becomes something you can use directly as the threshold for the next step (send to automated handling, or escalate to a human).

Just as clearly, there are places it doesn’t fit. Conversational work where the options themselves aren’t well-defined, or creative and explanatory work that doesn’t resolve to one correct answer, turn this structure into a constraint instead of a feature. “Can I even phrase this as a typed question” has to hold first, before Jev is worth considering at all.

It’s still in the early-access queue, so I haven’t been able to verify any of this directly. The judgment call is simple, though: if your automation pipeline is parsing LLM responses today, and either the parsing failures or the response latency are an actual bottleneck, there’s a reason to try it. If parsing is already stable and speed isn’t a problem, this model doesn’t solve anything you have.

Two questions remain open. Whether the published speed and cost numbers hold up against structured output under equivalent conditions, rather than free-form generation, and whether the “calibrated” claim actually reproduces across repeated real-world calls. Once early access opens, those are the two numbers I’d check first.

References