Contents · 5 sections
On September 15, 2026, a San Francisco lab called TypeSafe AI came out of stealth with a model named Jev. The pitch was unusual enough that we wanted to try it ourselves: Jev doesn't generate text. You send it some state (a headline, a review, a command) and a handful of typed questions, and it answers all of them in one pass, each answer with a probability for every option and a confidence score. No sentences, no parsing, no waiting for tokens.
TypeSafe calls this a System One model, after the fast, intuitive kind of thinking in Daniel Kahneman's work. The idea is that most decisions inside software are small and quick (which category, how urgent, is this allowed) and that they deserve a model built for exactly that. We build an image studio, so we care about small fast decisions: is this prompt about to get our account flagged, is this person asking for a picture or talking to a chatbot, which of these files is the one they mean.
Rather than read about it, we gave ourselves a day, an API key, and a rule: real data only, and every number goes in the write-up. This post is the overview. Each experiment has its own article with the setup, the results, latency, cost, what we'd change, and the raw run as a download.
The three questions Jev answers
Everything in the API is built from three question types. A Choice picks one option from a set you define (up to 255 of them) and returns a probability for each. A Score places something on a scale you describe in words ("calm, irritated, furious") and returns a position that can fall between levels. A Noul is a yes/no question answered as a single probability. You can send many of them in one call; they run in parallel and the answer for ten questions arrives about as fast as the answer for one.
POST /v1/systemone
{
"state": { "ticket": "I was charged twice. Fix it today or I'm cancelling." },
"questions": {
"team": { "type": "choice", "instructions": "Which team should handle this?",
"criteria": { "billing": "charges, refunds", "technical": "bugs", "other": null } },
"frustration": { "type": "score", "instructions": "How frustrated is the customer?",
"criteria": ["calm", "irritated", "furious"] },
"wants_refund":{ "type": "noul", "instructions": "Do they explicitly ask for a refund?" }
}
}
→ team: billing (1.00) · frustration: 1.98 · wants_refund: 0.07 · 401 ms · 441 tokensThat shape turned out to matter more than any single result. Because you define the answers up front, the model can only ever pick one of them. Your code owns the workflow; the model supplies judgment where a rule would be brittle.
The six experiments
We picked six jobs that are boring to do by hand and hard to do with rules, each one leaning on a different part of the model. Click any of them for the full write-up.
What we learned, in plain words
- It listens to what you tell it: we scored the same 90 headlines for two opposite people and the rankings came out mirror-imaged (rank correlation −0.71). The interest number means "interesting to this person", not "interesting in general".
- It gives the same answer every time: three runs on the same input moved scores by a few hundredths and never changed a category.
- It reads meaning, not keywords: three reviews were flagged as blaming an app update without ever using the word "update". Language detection beat the word list we used to check it.
- It's honest about ambiguity: when the probabilities are split, the input really is ambiguous. A review titled "No ads" whose body complains about ads came out 53% complaint, 32% praise.
- Confidence is not a separate opinion: on Score and Choice questions it tracks how concentrated the probabilities are (correlation −0.87 to −0.96 with entropy). Look at the spread, it tells you more.
- The probability is calibrated where it matters: on 5,574 labeled SMS, answers under 5% or over 95% (71% of messages) were right within three points. The middle of the range leans a little toward "spam".
- It fills whatever you leave out: topics a profile didn't mention scored "a little interesting"; reviews with no area got squeezed into the nearest one because we forgot a "none" option. The rubric is the product.
- It is fast and close to free: 174 to 192 ms median per call whether we asked 2 or 17 questions, and every experiment in this series together cost about a dollar.
How we tested
We built a small local lab: a Node server that holds the API key, calls the SDK, and streams each answer to a browser page as it lands, so we could watch a ranking rearrange itself in real time. Every run is saved with the full response (every probability, every token count) and each write-up links the raw data. Model version throughout: jev-1.13.0. Prices are TypeSafe's published rate, $0.042 per million input tokens with output free.
A few things we didn't do, so you can weigh the results: we wrote the rubrics ourselves, and a differently worded scale gives different numbers; we didn't compare against other models; and one day of testing is a first look, not a verdict. What we can say is that everything below is reproducible with the scripts in the download, on public data.
Why an image studio cares
Two of the six experiments came straight out of Nano Studio Pro. We looked at 148 real prompts people typed into our prompter and asked the model, prompt by prompt, whether the person was talking to a chatbot, whether they assumed the last result was still in memory, and whether the request was something an image provider would refuse. The answers were specific enough to design a pre-flight check from, and that check now runs in about 190 milliseconds per prompt. The pre-flight article has the details, the line search one is where the "find the file they mean" idea started.