Play the video (opens in a new tab)Video on YouTube by RepoChad
- Views
- 85,403
- Duration
- 8:10
Read from YouTube on . Counts change daily.
Reported by the author
- Latency
- 70-500 ms
why Typesafe claims 70–500 ms latency, 0% type errors, $0.04 per million input tokens, and free output tokens
youtube.com - Choice cap
- 255 options
direct choices are capped at 255 options
youtube.com
RepoChad reads TypeSafe’s launch material with a skeptical eye. Jev takes unstructured state and a schema defined in code, and returns typed values with a calibrated probability for each in one parallel pass. The video is careful about what “0% type errors” means. Jev cannot return broken JSON or an invalid enum, because the sampler only produces values the schema allows. It can still pick the wrong answer, which is why each decision comes with a probability. That probability comes from RLCD, TypeSafe’s training method for making stated confidence match real accuracy.
The video repeats TypeSafe’s published figures: 70 to 500 ms latency, $0.04 per million input tokens, free output, and a workflow evaluation reporting Jev as 193.6 times faster and 444.6 times cheaper than frontier models. It then points out how those were measured: from laptops on the US West Coast near the servers, and against LLMs wrapped in a probability adapter. It covers the two demos. The Doom bot makes about 10 queries a second for roughly $7 an hour, and TypeSafe admits a simple script plays better. Wiki Racing gets around the 255-option cap on a choice by scoring links in batches first, and the competing LLMs ran with little or no reasoning.
The caveats section lists what is not public: benchmark results, model size, weights, and whether it could ever run locally. Access was waitlist-only at the time.



