TypeSafe AI and Diogo Almeida
A ChatGPT co-inventor spent two years in stealth asking why superhuman chat models never produced superhuman automation. Jev is his answer.
- Company
- TypeSafe AI
- Founder
- Diogo Almeida
- Background
- ChatGPT co-inventor, formerly at OpenAI
- Launched
- September 15, 2026
- Time in stealth
- 2 years
- Access
- Early access, waitlist at typesafe.ai
The founder behind Jev AI
Diogo Almeida is credited as a co-inventor of ChatGPT, having worked at OpenAI on the methods that turned a research capability into something people could use. That is a genuinely unusual starting point for the company behind Jev AI whose entire pitch is that conversational models were the wrong tool for the job everyone tried to use them on — the critique carries more weight coming from someone who helped build the thing being criticised.
His framing of the problem, repeated across the launch materials, is a question rather than a claim: if models have been superhuman at chat for years, why has automation not followed? The answer he spent two years building toward is that the industry kept reaching for deliberation when what the work needed was fast, cheap, calibrated judgement.
Why the name TypeSafe fits Jev AI
The name is a borrowing from programming languages, and it is doing real work rather than sounding clever. In a type-safe language, a whole class of errors cannot be expressed: you do not check at runtime whether a string snuck into an integer field, because the compiler made that state unreachable. TypeSafe makes the same claim about Jev AI output. You do not validate that the answer is one of your categories, because a value outside them is not representable.
Anyone who has wrapped a language model call in a parser, a validator, a retry loop, and a fallback will recognise what that promises. All of that scaffolding exists to defend against output that might be anything at all. Remove the possibility and the scaffolding has nothing to do.
It is worth being precise about the boundary of the guarantee, since the name invites overreading. Type safety in a language does not mean your program is correct; it means certain errors are impossible. The same applies to Jev AI. Fabrication is off the table. A wrong answer inside your schema is not.
What to watch next for Jev AI
Three things will tell you whether this holds up. The first is independent evaluation: launch numbers come from the vendor, and until outside teams publish accuracy and calibration figures on their own data, the performance story is a claim rather than a result.
The second is whether pricing survives contact with real load. An early-access rate card is a hypothesis about unit economics, and the test is what it looks like a year after the waitlist opens.
The third is whether anyone else builds one. A category with a single occupant is a product; a category with three is a shift in how this class of work gets done. That question will resolve itself over the next year without anybody having to argue about it.
Reading a stealth launch carefully
Two years of silence followed by a launch with a named category, a named training method, and a rate card that undercuts the field by two orders of magnitude is a well-constructed debut. That is not a criticism — it is what a serious company does — but it is worth separating what has been demonstrated from what has been asserted, because at launch almost everything is the latter.
Demonstrated: the model exists, developers are being let in off a waitlist, and the published interface does what it says. Asserted: the accuracy, the calibration quality, the per-decision cost comparisons, and the claim that the economics hold without subsidy. None of those are unreasonable, and none of them are yet checkable by anyone outside the company.
The good news is that this particular product is unusually easy to evaluate yourself. You do not need a benchmark suite or a research team. You need a few hundred cases you already have labels for, an afternoon, and the willingness to look at a calibration curve. For a fraction of a cent per case, the cost of finding out is lower than the cost of the meeting where you would have debated it.
The one risk that is not resolvable by testing is dependency. A single-vendor, closed, waitlisted model with no alternative supplier is a concentration of risk regardless of how well it performs, and it is worth designing the integration so the decision layer can be swapped — a thin interface, your thresholds in your own code, and your labelled evaluation set kept somewhere you control.