TypeSafe AI came out of stealth on 15 September with $40M and a model called Jev, built by Diogo Almeida, who co-invented ChatGPT. The pitch is odd enough to be interesting: Jev does not generate text. Not "is bad at it" — cannot do it. You hand it program state and a set of typed questions, and it returns typed answers with calibrated probabilities. There is no string to parse, because there is no string.
They call it a System One model, after Kahneman's fast, automatic thinking. The framing is marketing, but the shape underneath it is real, and it lands on a problem I actually have.
A disclaimer before anything else: I have not run this in production. It is six days old and gated behind a waitlist. What follows is the API surface, the arithmetic against my own numbers, and where I think it fits — not a field report. I'll write that one when I've made real calls through it.
The shape of it
One endpoint, POST https://api.typesafe.ai/v1/systemone, and three question types:
- Noul — a yes/no question, answered as a probability between 0 and 1.
- Choice — categorical, up to 255 options, returning the pick plus per-option probabilities and a confidence.
- Score — a rubric with 2 to 10 levels, returning the level, its legend, probabilities and confidence.
Every question in a request is evaluated in parallel. The raw request looks like this:
{
"model": "jev-latest",
"state": { "transcript": "I've been waiting three days for the refund" },
"questions": {
"intent": {
"type": "choice",
"instructions": "What does the caller want?",
"criteria": {
"billing": "Money, refunds, charges",
"technical": "Something is broken",
"human": "Explicitly asking for a person"
}
},
"frustrated": {
"type": "noul",
"instructions": "Does the caller sound frustrated?"
}
}
}
The response carries the answers and usage, with the model pinned to the exact version that served it:
{
"model": "jev-1.13.0",
"answers": { "intent": { "choice": "billing", "confidence": 0.94 } },
"usage": { "input_tokens": 210, "output_tokens": 31 }
}
There are first-party SDKs. In TypeScript, the question types are helper functions:
import { choice, noul, TypeSafeClient } from '@typesafe-ai/sdk'
const client = new TypeSafeClient()
const { answers } = await client.systemOne({
state: { transcript },
questions: {
intent: choice('What does the caller want?', {
billing: 'Money, refunds, charges',
technical: 'Something is broken',
human: 'Explicitly asking for a person',
}),
frustrated: noul('Does the caller sound frustrated?'),
},
})
if (answers.intent.choice === 'human') await transferToAgent()
And in Python, which is where my agent code lives:
from typesafe_sdk import Choice, Noul, TypeSafeClient
client = TypeSafeClient()
response = client.system_one(
state=transcript,
questions={
"intent": Choice(
instructions="What does the caller want?",
criteria={"billing": "Money, refunds, charges",
"technical": "Something is broken",
"human": "Explicitly asking for a person"},
),
"frustrated": Noul(instructions="Does the caller sound frustrated?"),
},
)
There is also a Vercel AI SDK provider, @ai-sdk/typesafe-ai, exposing it through experimental_evaluate. Routes are jev-latest for stable and jev-preview if you want to be ahead of it; you can pin an exact version like jev-1.13.0.
Why this is interesting for voice specifically
I've written before that the hard part of a phone agent is not intelligence, it's the budget. You have somewhere around a second between the caller finishing their sentence and needing to make a sound back, and every stage of the pipeline takes a bite. I built a latency budget calculator precisely because people keep blaming the language model for delays that are coming from somewhere else.
Inside that budget there's a hop that is pure overhead: deciding what kind of turn this is before you answer it. Is this a billing question or a technical one? Does it need the knowledge base? Is this person asking for a human? Should the compliance disclosure fire?
Today I do that with a small chat model — Claude Haiku 4.5 — and it costs me somewhere around 300 to 500 ms. That is money spent on classification, before the model that actually answers has even started. TypeSafe quotes most Jev queries landing around 100 ms, with a range of 70 to 500 ms end to end.
If that holds up, swapping the router is worth roughly 250 ms on every single turn. For reference, moving from ElevenLabs Flash to Cartesia Sonic — a change people write blog posts about — is worth about 35 ms. Drag the two routing presets in the calculator against each other and the gap is embarrassingly large.
There's a second reason it fits. A chat model asked to classify will occasionally return "billing." with a full stop, or "Billing" capitalised, or a sentence explaining its reasoning. You write a parser, then you write a retry, then you write a fallback, and each of those is a branch that can fire mid-call. A model whose output is typed by construction deletes that entire category of bug. answers.intent.choice is one of your options or the request failed. Nothing in between.
The arithmetic
Jev is priced at $0.042 per million input tokens, with output tokens free — which makes sense, since there aren't any in the usual sense. Rate limits at launch are 250,000 tokens per second and 1,200 requests per minute. State plus the longest single question has to fit in about 32,000 tokens.
Against my own cost model, where the whole cascaded AI stack runs about $0.0293 per minute, the routing layer was never the expensive part — speech synthesis is roughly two-thirds of that bill. So this is not a cost story for me, and I'd be suspicious of anyone selling it as one for a voice pipeline. It is a latency story that happens to also be cheaper.
Where it is a cost story is high-volume classification outside the call path: scoring every inbound lead, triaging a ticket queue, filtering a firehose. TypeSafe claims 20–200× faster and 40–400× cheaper than frontier LLMs on this class of task, which is a wide enough range that you should read it as "depends entirely on what you're comparing against" — but even the bottom of that range changes what you can afford to run on every record.
What it cannot do, which is the useful part
The documented limitations are more specific than most launch posts bother with, and they map neatly onto things you would absolutely try on day one. Jev cannot reliably:
- count items
- do arithmetic
- compare dates or times
- handle double negatives
- generate text or code
- process images, audio or video
Read that list again with a voice agent in mind. "How many times has this customer called?" — no. "Is this appointment before the cutoff?" — no. "Is the account balance sufficient?" — no. Those are database queries pretending to be questions, and the right answer is to compute them in your own code and put the result into the state you hand over.
It also gives you no rationale. A chat model classifying a turn can tell you why, which is genuinely useful when you're debugging a script at two in the morning. Jev gives you a label and a confidence and nothing else. You get calibration instead of explanation, and whether that's a good trade depends on whether you were actually reading those explanations or just logging them.
The audio limitation matters for anyone imagining this replacing more of the stack: it takes text, so your speech-to-text still runs first. This sits after transcription, not instead of it.
Where I'd put it, and where I wouldn't
Would: the routing hop, intent classification, escalation detection, deciding whether a turn needs retrieval, scoring lead quality between calls, flagging turns for human review. Anything that is a decision with a known answer space, on the critical path, where a typed answer with a confidence score is strictly more useful than a sentence.
Wouldn't: anything the caller hears. The actual conversation still needs a model that can compose language, handle an interruption gracefully and say something sensible when the knowledge base comes back empty. Jev does not compete for that job — it isn't built for it.
The honest framing is that this is a complement, not a replacement, and TypeSafe are refreshingly direct about that. Use the expensive model for the part that needs judgement and language. Use the cheap typed one for the twenty decisions surrounding it that were never really language problems — they were classification problems wearing a chat interface because that was the only interface available.
That's the part I find genuinely interesting. We have spent three years routing structured decisions through a text-generation API because it was the only tool on the shelf, parsing strings back out at the other end and calling it engineering. A model that returns a typed value is not a breakthrough in intelligence. It is just the right shape, finally.
I'll report back when I've run real traffic through it.
References: TypeSafe AI · Jev deep dive — Flavio Copes · System One models explained — DataCamp · Latent Space launch coverage · Building a harness with Jev — LangChain · Made with Jev · awesome-jev