new post. there's a lot in it. i suggest you check it out

@mathfax @typesafeai I rejoined this website just to share terrible homebaked memes such as this #jev

Jev and the System One Model: RLCD, intelligence/$, reliable AI, & the end of chat-first AI latent.space/p/jev @typesafeai CEO @CompleteSkeptic explains why AI can solve extraordinarily hard problems yet still fail to automate basic work, why Jev is built for reliable decisions inside software instead of chat, why TypeSafe rejects public benchmarks and refusals at the API layer, why data and the right task matter more than brute-force compute, how System One Models could reshape coding agents and software, and why even with $1 billion he wouldn’t pre-train a model from scratch.

Realtime sentiment analysis with Jev and ElevenLabs. Each phrase takes on the color of the emotion it carries while the caller is still talking. Six meters on the right track the mood of the call.

We’re fixing this! That’s an outdated constraint from pre-launch.

pondooring what it's like to be a guy who hears "impossible" and thinks "yeah that's about 10%"

The Jev sweet spot. (when to use it, and when not to) Jev lives between rules and LLMs. The easiest mistake is treating Jev as a faster replacement for an LLM. It is better to think of Jev as the missing layer between deterministic software and open-ended generation. The graphic below maps that boundary using two dimensions. One is how constrained the answer space is. The other is how frequently the decision must be made. ↳ Use ordinary code when the rule is exact. ↳ Use an LLM when the answer must be created through writing, planning, explanation, or deeper reasoning. ↳ Use Jev when the possible answers are known, but choosing among them requires semantic judgment. A decision belongs in that sweet spot when four conditions are true. → The valid answers can be defined in advance. Jev should choose from known labels, ordered scores, or a yes-or-no decision. → The input is difficult to express as deterministic rules. A person could judge it quickly, but an if-statement cannot reliably understand its meaning. → The decision happens frequently. Model routing, ticket triage, retrieval reranking, guardrails, and high-volume labelling repeat often enough for latency and cost to compound. → Uncertainty should change what happens next. High-confidence results can continue automatically. Ambiguous results can be sent to a stronger model or a person. Consider support-ticket routing. The possible owners are already known. They might be engineering, billing, or sales. But customer messages arrive as unstructured language rather than clean database fields. An LLM can classify them, but generating and parsing text for every ticket is unnecessary. Deterministic rules are cheaper, but become brittle as the wording changes. Jev handles the fuzzy judgment and returns probabilities that application code can use. The same framework explains where Jev does not fit. If the task requires writing or multi-step reasoning, use an LLM. If arithmetic or an exact rule can determine the answer, keep it in code. If the possible answers cannot be defined in advance, Jev is the wrong interface. The practical rule is simple. Use Jev when code understands the possible values but not the meaning of the input. I wrote the full breakdown on Jev. The article is quoted below.

JEV PASSES WORM BENCH 🪱🪱🪱🪱

ask your local jev about seaweed today!

Sir what is going on here

Here's food for thought @simonw one thing unique about jev is that you can do so many evaluations so fast (incl. concurrently) that you could break apart, mutate and experiment with inputs and store the numeric results, this probably would allow some 'significance analysis'

Here's a quick demo of me using @typesafeai's Jev for ONET job classification vs. Luna. - Luna: 84.9% exact, ~2s/job, $482/1M - Jev: 80.5% exact, ~200ms/job, $122/1M tl;dr: ~10x faster and 4x cheaper for ~4 points of accuracy