For about three years, every new model release has promised the same thing: better text, produced faster and for less money. The interface stayed the same the whole time. You send a string and get a string back. If your program needed anything else, you wrote a parser, a JSON schema validator, and a retry loop around all of it.

TypeSafe came out of stealth on 15 September 2026 with a model that works differently. Jev can't write you a function, summarise a document, or hold a conversation, because it doesn't generate text at all. You give it the state of your program and a set of typed questions, and it hands back typed answers with calibrated probabilities, in roughly the time a Postgres query takes. The company calls this category a System One model. I think it's worth a look even if you never send it a single request, because the argument underneath is about where the boundary between code and model should sit.

What is a System One model, and how is it different from an LLM?

The name is a nod to Kahneman. System Two is the slow, deliberate reasoning that chain-of-thought prompting tries to simulate. System One is the fast judgement you make before you notice you made it. Is this email angry or this transaction weird? Does this sentence belong in the billing bucket or the technical one?

TypeSafe's claim is that most decisions inside production software are System One decisions, and that we've been paying System Two prices for them. Say a Rails app asks a frontier model "is this comment spam" and gets back a paragraph explaining that yes, this comment does appear to be spam. Nearly all of that computation was overhead. The model wrote an explanation that no human will ever read, your code threw it away, and you were billed per token for it.

An LLM is trained to produce text a human will approve of, because that's what RLHF optimises. It makes the model a good assistant and a mediocre component. "What a human would rate highly" and "a calibrated probability your code can threshold on" are different objectives, and optimising the first one hurts the second. Models trained on human preference are systematically overconfident, since confident-sounding answers get better ratings.

Jev is trained with something TypeSafe calls Reinforcement Learning for Calibrated Decisions, or RLCD. It rewards epistemically honest probabilities on System One tasks where RLHF rewards preferred text. The architecture matches: Jev doesn't emit tokens one at a time, it uses a parallel sampler that produces every output in a single pass. That explains the latency numbers, and also why the model can never write a sentence, since there's no autoregressive loop to run.

How does Jev work?

It's simpler to think about than an LLM. You send two things, state and questions.

State is the context. It can be a bare string or structured data, and in practice it's whatever your program already has in memory at the decision point: a ticket body, an exception payload, a diff, the current DOM. Questions are typed, and there are exactly three types.

Choice selects one option from a set you define. You get back the selected option, a probability for every option, and a confidence number. Score rates state against ordered descriptive levels, and returns a continuous score, the legend you supplied, and confidence. Noul is the odd one out. It asks whether a statement is true and returns a single probability between 0 and 1. Noul answers carry no confidence field, which makes sense, since the probability already is the answer's uncertainty.

You can mix all three in one call. Every question is evaluated in parallel and in isolation against the same state, so you get many decisions out of one round trip and they don't interfere with each other.

The wire format is a plain HTTP POST. That's handy, because there's no official Ruby SDK yet, only Python and JavaScript.

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"state": "...", "model": "jev-latest", "questions": {}}'

How to call Jev from Ruby

No Ruby SDK means you write the client yourself. It takes about forty lines, and I'd argue it's clearer than depending on one. The endpoint is a single POST, the auth is a bearer token, and the response is ordinary JSON.

Sidekiq retries are blunt: a job either raises or it doesn't, and the retry policy can't tell a transient DNS blip from a payload your code will never be able to process. Telling those two apart is a System One judgement, and you'd never spend an LLM call on it because the latency would defeat the purpose.

require "net/http"
require "json"

module SystemOne
  ENDPOINT = URI("https://api.typesafe.ai/v1/systemone").freeze

  Error = Class.new(StandardError)

  # Sends one state blob plus a hash of typed questions, returns the
  # "answers" hash keyed the same way the questions were.
  def self.ask(state:, questions:, model: "jev-latest", timeout: 2)
    http = Net::HTTP.new(ENDPOINT.host, ENDPOINT.port)
    http.use_ssl = true
    http.open_timeout = timeout
    http.read_timeout = timeout

    request = Net::HTTP::Post.new(ENDPOINT)
    request["Authorization"] = "Bearer #{ENV.fetch('TYPESAFE_API_KEY')}"
    request["Content-Type"] = "application/json"
    request.body = JSON.generate(state: state, model: model, questions: questions)

    response = http.request(request)
    raise Error, "#{response.code}: #{response.body}" unless response.is_a?(Net::HTTPSuccess)

    JSON.parse(response.body).fetch("answers")
  end
end

Two choices in there are on purpose. The timeout is two seconds, where you'd normally set thirty. A System One call that takes two seconds has already failed at its one job, so you want the circuit to break and not wait. The method also returns the plain answers hash with no wrapper object around it, because there's no streaming, tool loop, or conversation state to model.

The triage class sends the exception and the job as state:

class FailureTriage
  RETRYABLE = "transient"

  def initialize(exception, job)
    @exception = exception
    @job = job
  end

  def verdict
    @verdict ||= SystemOne.ask(
      state: {
        job_class: @job["class"],
        error_class: @exception.class.name,
        error_message: @exception.message,
        backtrace: @exception.backtrace&.first(8),
        attempt: @job["retry_count"].to_i
      },
      questions: {
        failure_kind: {
          type: "choice",
          instructions: "Classify the root cause of this background job failure",
          criteria: {
            "transient" => "Network blip, timeout, deadlock, or upstream 5xx that will likely succeed on retry",
            "poison_payload" => "The job arguments themselves are invalid and no retry will ever succeed",
            "bug" => "A defect in our own code, such as NoMethodError or a type error",
            "downstream_outage" => "A dependency is fully down and retrying soon will only add load"
          }
        },
        pages_someone: {
          type: "noul",
          instructions: "This failure indicates customer-visible data loss"
        }
      }
    )
  end

  def retry?
    verdict.dig("failure_kind", "choice") == RETRYABLE &&
      verdict.dig("failure_kind", "confidence") >= 0.7
  end

  def page?
    verdict.dig("pages_someone", "noul") >= 0.9
  end
end

Both questions go in one request because of how the pricing works. Input tokens cost $0.042 per million and output tokens are free, so the state blob is billed once no matter how many questions you attach to it. Asking five questions costs almost exactly what asking one costs. If you're used to batching decisions to save on LLM spend, do the opposite here and ask everything you might plausibly want, including questions whose answers you'll probably discard. TypeSafe calls this pattern speculative fan-out, and it only makes sense because output is free.

What does "it cannot hallucinate" actually mean?

I'd be most sceptical about this claim, because the marketing is a lot broader than the guarantee. The guarantee is a type property. A Choice question can only return one of the options you defined. With no token stream, the model has no way to invent a fifth category, misspell one of your enum values, wrap the JSON in a markdown fence, or stop mid-object. So the parse-validate-retry code that every production LLM integration carries goes away, and that's a real engineering win.

Nothing guarantees that the option it picks is the right one, or even a sensible one. If none of your options fits the state, the model still has to return one of them. An early tester tried exactly that and asked a support-routing setup about cafeteria opening hours, with only billing, technical and sales available. Jev returned sales with a confidence of 0.31. I wouldn't call that a hallucination. The question it got was "which of these three", and nobody asked it "is any of these three appropriate".

So always include an explicit escape hatch option, always read confidence, and never treat a type guarantee as a correctness guarantee. I'd write the other branch before anything else.

criteria: {
  "billing" => "Payment, invoice, or subscription issues",
  "technical" => "Bugs, integrations, or outages",
  "sales" => "Pricing, plans, or upgrade questions",
  # Without this, a question about the cafeteria becomes a sales lead.
  "other" => "None of the above categories genuinely fits this message"
}

How to use confidence to gate actions

Confidence is a single number from 0 to 1, derived from the probability distribution the answer already contains. A distribution concentrated on one option is confident and a flat one isn't. TypeSafe computes it for you, but you also get the full probabilities hash, so if their definition doesn't suit your problem you can compute your own entropy or margin and ignore theirs.

Confidence gets useful once you treat it as a second output. The answer tells you what the model decided, and confidence tells you whether your code is allowed to act on it without a human in the loop. That also means there's no single threshold. It scales with the cost of being wrong, so it belongs next to the action and not next to the model call.

class RefundGate
  # Each action names its own tolerance. Issuing money needs near-certainty;
  # adding a label to a ticket does not.
  THRESHOLDS = {
    auto_refund: 0.95,
    auto_close: 0.85,
    apply_label: 0.60
  }.freeze

  def initialize(answer)
    @choice = answer.fetch("choice")
    @confidence = answer.fetch("confidence")
  end

  def permitted?(action)
    threshold = THRESHOLDS.fetch(action)
    @confidence >= threshold
  end

  # Anything the model is unsure about becomes a human's problem.
  def route(action)
    permitted?(action) ? [:act, @choice] : [:escalate, @choice, @confidence]
  end
end

Early testers keep warning that a confidence of 0.9 doesn't mean the model is correct 90 percent of the time on your data. Calibration describes the model's training distribution, which isn't your ticket queue. The only way to know where to put your thresholds is to run a few hundred of your own labelled examples through it and look at the curve.

Is Jev as fast and cheap as it claims?

Speed and price are published and verifiable, and nobody is really arguing with them. End-to-end response time lands between 70 and 500 milliseconds. Input is $0.042 per million tokens with free output, against $0.20 to $10 per million for LLM input, where output typically costs about five times input on top. The headline "40x to 200x faster" compares that 70-500ms band against 3 to 329 seconds for frontier models on the same tasks.

The first fair objection is about that comparison. A commenter on the launch thread put it bluntly: 70 milliseconds against 329 seconds isn't apples to apples if the baseline is running full chain-of-thought. That's true. It also doesn't change the buying decision much, because you were going to pay for that chain-of-thought whether you wanted it or not.

The intelligence claim is much softer. TypeSafe's workflow evals don't use ground-truth labels. They "use the predictions of the largest, smartest, and most expensive external models as reference probabilities", specifically the average of GPT-6 Astra and Fable 5.1. In practice, agreement with two frontier LLMs was treated as correctness. The company says so openly, and also notes that the workflows were built by its own model capabilities team and represent "the higher end of real world gains". They deserve credit for publishing the caveat, but a high score still measures conformity with GPT-class models and not whether the answer was right. There's no calibration paper, no reliability curve, no expected calibration error figure, and no ablation separating the RLCD training from the architecture. For a model whose entire pitch is calibration, that's a strange gap.

Independent evidence has started to come in, and it's more favourable than the sceptics expected. Someone benchmarked Jev against a frontier model with reasoning disabled on standard multiple-choice sets and found it competitive on MMLU and GPQA, and ahead on WinoGrande and HellaSwag, which is surprising for a non-chain-of-thought model. It lost substantially on mathematical reasoning, which is what you'd predict from an architecture with no room to think step by step. Production reports point the same way. Vercel's Malte Ubl ran Jev against an existing classifier eval that previously used Gemini 2.5 Flash Lite and reported that it saturated the eval while running about six times faster. The open source Jev Ultrafast browser agent cut a flight search from 9.45 to 7.1 seconds and median browser protocol calls from 1,092 to 101, though that compares two versions of the same agent, both already running on Jev, over only three paired runs.

Where does Jev fit in an existing system?

I see five places, roughly in order of how quickly they pay for themselves.

Model routing comes first. Classify the incoming request in 100 milliseconds, then send the easy 80 percent to a small model and the hard 20 percent to a frontier one. The router used to cost you a model call of its own, which made the maths marginal. With free output tokens it doesn't.

Guardrails and output verification come second. You no longer spend a second frontier call to check whether the first one's answer is supported by the retrieved context. You ask a Noul question and get a probability back before the user notices a pause. Early testers report that basic prompt injections embedded in the state didn't flip the classification when the instructions explicitly framed message content as untrusted, though one passing test is no security guarantee.

Agent action selection is third, and to me the most interesting. A browser agent that has to pick the next element to click makes thousands of tiny System One decisions, and decision latency is the whole cost the user sees. Both versions behind the 91 percent drop in protocol calls already used Jev for decisions, though, and the gain came from reading common page controls in one browser call per DOM snapshot, where the older version re-read the accessibility tree on every mutation. Fast decisions pay off only once the loop around them stops being the bottleneck.

Triage and routing is fourth, boring and reliable: tickets, exceptions, alerts, inbound leads. Fifth is real-time control loops. Someone had it playing DOOM at ten decisions per second for about seven dollars an hour, a silly demo that still shows the latency budget is real.

What Jev is bad at

It can't write anything at all, including an explanation of its own decision. If your product has to show a user why something was classified the way it was, Jev hands you probabilities and stops there, and you're back to paying a text model to narrate them.

Multi-step reasoning is weak, as the maths benchmarks show. A decision that needs intermediate steps is a System Two problem and belongs to a System Two model.

It's bounded by your question design, which is the failure I expect people to hit in production. The model can't do better than your criteria descriptions and your option set allow. A badly framed Choice with a missing escape hatch will keep producing confident-looking nonsense and will never warn you, because from its point of view it answered correctly.

Jev is also closed and hosted, while the architecture turned out to be reproducible. Within days of launch there were open reimplementations, one scoring options in a single pass on top of a 4B Gemma, another replicating the approach on Qwen. The top-voted thread in the local model community that week was someone pointing out they'd open-sourced the same architecture, with paper and dataset, a year earlier. The idea is already public, so whatever moat TypeSafe has comes from the training run, the calibration quality and how long the price stays at four cents.

How to evaluate Jev on your own workload

  1. Pick one decision your code already makes with an LLM call, ideally one whose output you parse and throw the prose away.
  2. Write the Choice or Noul question for it, and include an explicit other or unknown option before you write anything else.
  3. Pull 200 to 500 real examples from production and label them by hand, or with a frontier model you then spot-check.
  4. Run them through Jev and record the answer, the full probabilities hash, and the confidence for every one.
  5. Plot accuracy against confidence in buckets, and find the threshold above which you are comfortable acting without a human.
  6. Wire that threshold into the action, not into the model call, and send everything below it to a review queue.
  7. Measure the money and the milliseconds against the LLM call you replaced, and keep the review queue instrumented so you notice when the distribution drifts.

If you want the decisions on record, log them yourself and don't rely on a dashboard. A decisions table keyed to the entity is enough to answer "what did the model think" three months later.

SELECT
  question_key,
  width_bucket(confidence, 0, 1, 10) AS confidence_decile,
  count(*) AS decisions,
  avg((answer = human_label)::int) AS agreement_rate
FROM system_one_decisions
WHERE created_at >= now() - interval '30 days'
  AND human_label IS NOT NULL
GROUP BY question_key, confidence_decile
ORDER BY question_key, confidence_decile;

That query is your calibration audit. If agreement_rate doesn't climb as confidence_decile climbs, the model isn't calibrated on your data, whatever the vendor's evals say, and your thresholds mean nothing.

FAQ

Is Jev a replacement for GPT or Claude?

No, and TypeSafe doesn't claim it is. It can't generate text at all. It replaces the specific LLM calls where you only used the model as a classifier, scorer, or router and discarded the prose.

How much does Jev cost?

Input is $0.042 per million tokens and output tokens are free in 2026. Every question in a request is evaluated against the same state, so the state is billed once no matter how many questions you attach, and asking ten questions costs roughly what asking one costs.

Can Jev really not hallucinate?

It can't produce a value outside the options you defined, and it can't emit malformed output, because there's no token stream. It can still pick the wrong option, and if none of your options fits it will still return one of them. Include an other option and gate on confidence.

Is there a Ruby SDK for Jev?

Not at launch. Official SDKs cover Python and JavaScript. The API is a single POST to https://api.typesafe.ai/v1/systemone with a bearer token, so a Ruby client is about forty lines of Net::HTTP. You have example above as ready-to-go client to get results.

What is RLCD?

Reinforcement Learning for Calibrated Decisions, the training method TypeSafe uses in place of RLHF. It optimises for honest probabilities on System One tasks, where RLHF optimises for text a human rater would prefer. There's no published paper on it yet, which is the main gap in the launch.

Are there open source alternatives to Jev?

Several appeared within days, including single-pass option scorers built on small open models and reimplementations of the architecture. None of them match the hosted model's calibration yet.

For what it's worth, I think the interesting number here is the free output tokens, more than the 200x. That one line in the pricing table turns "ask the model a question" from something you ration into something you do everywhere, and I expect it to shape how people build with these models more than the latency does. Go replace one classifier call and measure it.

Happy Jev-ing!