Jev Is Incredible  🔗 **Source:** [Jev Is Incredible](https://www.youtube.com/watch?v=F3YXg7AaKWE) > [!note]+ Document Notes > tags: [ai-models, structured-outputs, classification, llm-engineering, context-management] > author: Theo (t3.gg) > source: Theo - t3.gg (YouTube) > reference: https://www.youtube.com/watch?v=F3YXg7AaKWE > date created: 2026-09-21 > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: Jev is incredible > ## 🧭 Table of Contents > - [📝 Summary](#-summary) · [📖 Main Content](#-main-content) · [🗒️ Notes](#️-notes) · [📚 References](#-references) · [🗣️ Paraphrase](#️-paraphrase) · [📰 Newsletter](#-newsletter) · [✅ Action Items](#-action-items) · [🧪 Hypotheses](#-hypotheses) · [📊 Methodology](#-methodology) · [❓ Questions](#-questions) · [🔮 Future Research](#-future-research) · [💡 Implications](#-implications) · [🧠 Learning Styles Assessment](#-learning-styles-assessment) · [📊 Accessibility Assessment](#-accessibility-assessment) · [🌍 DEIB Assessment](#-deib-assessment) · [✅ Logical Validity](#-logical-validity) · [🛡️ DARVO Analysis](#️-darvo-analysis) · [🎯 Conclusion](#-conclusion) · [🧱 Refactor Appendix](#-refactor-appendix) · [🧰 Template Library](#-template-library) > ## 🔗 References (in-page) > - Source video: https://www.youtube.com/watch?v=F3YXg7AaKWE — Theo (t3.gg), uploaded 2026-09-21, 30m29s > - **Sponsored segment:** Depot (CI and build infrastructure), about [00:01:02]–[00:03:07]. > - Subject: Jev, a "System 1" classification model from Typesafe AI. Its founder is described as a former OpenAI researcher who worked on the research behind ChatGPT and RLHF; the captions render his name "Dio," which is unverified. > - Model names in the captions (Fable, Astra, Terra, Soul, Luna, Opus 5, Haiku, GPT-OSS-120B, DSV4 Flash) are transcribed as spoken; spellings may be off. > - Key vendor figures (193.6x faster, 444.6x cheaper, 0% structured-output errors) come from Typesafe's own announcement; the benchmark set was not published. > ## 📝 Summary > **What happened.** Theo reviews Jev, a new model from Typesafe AI built for classification rather than text generation. It takes structured state in and returns typed JSON with calibrated confidence, fast and cheap enough to use like a function call or an "if statement" inside code. > **What Jev is.** Named after the Jevons paradox (cheaper power increases total use) and framed with Kahneman's System 1/System 2 distinction, Jev handles fast, intuitive judgments. It gives up free-text generation, has a 32K-token context window, no vision yet, and — per the vendor — always returns the requested JSON shape. Theo stresses that the *format* is deterministic; the *content* is not. > **The numbers.** > - Price: about $0.04 per million input tokens versus about $10 per million on a frontier model; output tokens are free ("too cheap to meter"). > - Speed: 70–500 ms per classification versus 3–300+ seconds for LLMs, which Theo calls "40 to 200x faster." > - Typesafe's homepage claims: 193.6x faster and 444.6x cheaper, which Typesafe itself says is "the higher end of real world gains." > - Structured-output error rate: 0% for Jev; Theo reads a 45.5% rate for Haiku off the vendor's chart. > - Real use: a colleague classified 100 emails at about 200 ms average (p95 240 ms, 38/second); Theo classified 32,311 messages across 1,118 of his own chat threads. > **Where it's good.** Moderation, email triage, sorting content, routing decisions in workflows, fast UI updates, navigating HTML, and games from state data — anything a person could answer in under about 10 seconds once they have the information. > **Where it isn't.** Theo pushes back hard on two viral ideas. Using Jev as an LLM judge (suggested by the observability company Braintrust) makes little sense because it can't reason about complex outputs. Using it for context compaction is a bad idea: compaction is synthesis, not filtering; Jev's 32K window can't hold the context; labs don't expose reasoning traces; models are trained on their own compaction; and deleting earlier history invalidates prompt caches. > **Why it matters.** A clear explanation of a new class of model — cheap, fast, typed classification — and an unusually direct warning against using it for the wrong jobs. > **Risks.** The headline benchmarks are the vendor's and unpublished. The reference answers used an average of two frontier models, so "accuracy" means agreement with those models. The video opens with a sponsor read. And "can't hallucinate" is true only of the output format. > **Bottom line.** Treat Jev like a library function for classification, not a chat model. Believe the speed and price claims more than the unpublished accuracy claims. > ## 📖 Main Content > Theo opens by saying this isn't the usual incremental model release. Jev is for data processing: taking data, organizing it, classifying it, and returning type-safe JSON. It won't replace general models, and if you're using expensive frontier models for this kind of work, "I have a lot of questions for you." After a sponsor segment for Depot — faster CI, Docker caching, GitHub Actions–compatible builds pitched as built "for agents today" — he gives the background. > Jev comes from Typesafe AI, founded by a researcher who worked on instruction-following and RLHF at OpenAI. The core idea is System 1 models: fast, intuitive judgment like recognizing a shirt's color, leaving slow reasoning to other models. The Jevons-paradox name signals the pitch: not new capabilities, but making existing ones cheap and fast enough to use everywhere. Theo's own checkers demo shows the tradeoff: moves come back almost instantly, but the model plays badly because it isn't reasoning. > Reading the announcement, he emphasizes that Jev is meant to be called from code, not by a human. You pass structured program state and get back typed decisions — "a frontier intelligence function call." He compares it to BAML, a language that defines typed interfaces between code and LLMs and repairs malformed JSON at runtime, which he found necessary because GPT-OSS-120B formatted JSON incorrectly about half the time. > He anticipates confusion about determinism. Code that formats a name does the same thing every time; an LLM might not, and might return a float where you wanted an integer. Jev's output *shape* is deterministic; its *content* is probabilistic but, he says, reliable. It also runs many inputs in parallel. On cost, input is about $0.04 per million tokens and output is free. On speed, 70–500 ms versus 3–300 seconds. Calibration is a selling point: a model that's right 95% of the time but can't tell you when it's in the other 5% can't be used for automation, while Jev reports confidence with every answer. > The vendor's comparison shows 27 questions answered in 0.114 seconds for a negligible cost, against about 9 seconds for a frontier model. Theo notes the vendor charted cost on a log scale when linear would have looked more dramatic, and that only two models ranked better on classification in their workflows. The benchmark wasn't published, though examples were: an alert-triage flow of the kind "is this unauthorized activity?" leading to incident-state classification and a recommended action. The headline 193.6x/444.6x figures come with the vendor's own caveat that they're the upper end. The reference answers averaged two frontier models, so those models' mistakes are baked in. On structured-output errors, Jev scores 0% and Haiku 45.5%, which prompts Theo to say Haiku "needs to stop being used for anything." > Demos: Doom played from game state at 10 decisions a second for under $7 an hour, with visible flailing because each frame is a fresh decision with no memory; wiki racing; JSON Render from Vercel producing UI updates in one shot; and 1,500 exported emails classified at about 200 ms each. Theo imagines future vision support for checking video frames for personal data before release. > Then the warnings. He's worried that excitement will produce bad ideas and calls out Braintrust for suggesting Jev as a judge for LLM outputs: prompting a general model as a judge takes seconds, and a non-reasoni Oh boy, it's new model time. This one'svery different, though. This isn't ourusual new LLM that’s slightly better atcode, and it’s not going to be the typeof thing that the model counter guy isgoing to show up and say, "Look, bestnew model." If anything, this might takethe counter guy out of his job becausethis model is for data processing. It'sby a company called Typesafe AI, and it'scalled Jev. The point of this modelisn't to generate text, write code, ordo all the things that we expect modelsto do today. It is classification. Thismodel is the best model ever made totake data and organize it and classifyit. It returns JSON perfectly in atype-S safe format. When you give it aformat, it does it and it does it well. That means this model isn't going toreplace things like Fable or Astra.Well, hopefully not. If you are usingFable and Astra for the stuff you can dowith this, I have a lot of questions foryou. All that said, this model isIncredibly capable, and that's why it'sblown up on Twitter. I've seen demos ofeverything from lightning-fast computeruse, even in like the iOS simulator, tothe model playing Minecraft at lightningspeed, to compaction that takes under asecond instead of multiple minutes. Ican't wait to show you all the bestthings you can do with this model. Butfirst, we got to classify something. Thenext section, which is the sponsorbreak. If you're not a developer, youcan skip this ad. But if you are, youshould listen closely. Have you ever sent a prompt to Cloud Code, Codeex, Cursor,or some other tool and been surprisedthat it took hours when you expected itto take minutes? Did you check to seewhy? Because I would bet, good money,there's a very good chance that ahandful of things happened. Maybe ittook too long to download the Dockerimage. Maybe it spun up and had someerror when it did. Maybe the CI that itwas trying to run took forever. Maybe itPushed it up to GitHub and the CI run onthere was going to take hours long. Icannot tell you how many times I've runinto this. Wouldn't it be nice if youragents could do all of those things wayfaster and more reliably, and when thosethings failed, you got insight into it? Imagine taking all of these 8-minutebuilds and knocking them down to 20seconds or building and testing threeReact apps in seven Go binaries in 30seconds or making your cross-platformbuilds 10 to 20 times faster. Hopefully,you get the idea now because today'ssponsor is Depot, and they are tryingtheir damnedest to make AI more capable,not by giving it things it can't doalready, but by making all of the thingsit does do more reliable and faster. Whether you're looking for a faster andcheaper alternative to GitHub Actions orjust a nice place to let your agents runor a cache for all the Docker images youand your team are using, Depotprovides all of this and more. Their CIPlatform is fully compatible with GitHubactions, which means you can swap overtrivially. But if you don't want to dealwith GitHub's downtime, you can movefully over to Depot's platform. Stillcompatible with actions, but withouthaving to worry about GitHub'sreliability. You can also transformthose workflows to let them run inparallel, which ends up being comicallyfaster than the alternatives on GitHub. Their CLI is incredible, too. You andyour agents will understand itimmediately. It makes it trivial tomigrate your CI, run it without pushingup code, diagnose things when they gowrong, find secrets and clone themacross different places, and more. Youcan even SSH into a session while it isrunning to figure out what's going wrongin real time. And when I say you,obviously, I mean your agents. GitHubactions were poorly assembled for humansover 10 years ago. Depot was craftedcarefully for agents today. Figure outWhat that means at soyv.link/depo. Quick breakdown on how this all happenedbecause it's actually been pretty crazyto watch. It feels like it just poofappeared and took over my entire Twitterfeed. Like half of what I've been seeingis all of the stuff about Jev. It wascreated by Dio, who used to work atOpenAI. He apparently helped co-inventChatGPT as well as RHF. And as great asRHF is for model behaviors, it is nothelping as much with classification,which is the thing he cares about. Ifyou focus more on the classifying sideand less on the general usage of textgeneration side, what you can get is wayway faster and way way cheaper. Inparticular, all output tokens beingfree. The cost characteristics of thismodel are almost as insane as the speed. Both are crazy. So, let's read throughthe announcement. The core concept hereis system one models. This is an ideathat comes from thinking fast and slowby Daniel Kahneman. System one is the fastAnd intuitive judgment of your brain. The part of your brain that can dothings without effort that looks atsomebody's like, "Yeah, that shirt'sblue." System two is slow and deliberatereasoning. In TypeSafe's framing, Jevhandles the first kind of task whilereasoning models still handle thesecond. They named it Jeb after Jevan'sparadox, which I actually think ispretty cute. The idea is that when thesteam engine gets more efficient, itactually increased coal consumption, notdecreased, because now that power ischeaper, we can use it for more things. That is really the right way to think ofthis model. It's not unlocking newcapabilities that weren't possiblebefore. It's making them fast and cheapenough that they're way more viable thanthey've been. But what are those cases?What is this valuable for? Pretty muchanything that needs to be classified.Think organizing videos by their topicin my YouTube channel. Figuring out ifAn email is important or not, and whatcategory it should be put under. Thingslike safety and moderation, identifyingwhat messages are safe and which onesaren't, and what makes them unsafe. There are so many things you can use itfor. And when it's as insanely fast asthis model is, the results are kind ofcrazy. We'll go to the officialannouncement in a sec, but first I justwant to show you how insanely fast themodel is with an example of something itcan do. Not saying it can do it well.You'll actually see the type 1, type twodistinction here. But this is a game ofcheckers that I built to use Jev. Jevtakes the whole board as an input, as astate, not an image because it doesn'thave vision. It takes the board state asdata and then it chooses what to movebased on the output it gives. So here itmight say it wants to move B6 to C5. Igo first, so I'll make a move. Watch howfast it responds. I'm clicking now.Yeah, it's practically instant. There is a catch though. It's not verysmart.I was able to barely pay attention whileplaying and crush this model. Yeah, it'sjust, it's not good. I was barely payingattention, and I'm going to crush ithere. The point I’m trying to make is thatit’s super fast, but it’s not using thereasoning part of its brain, so to speak.It is just processing the data. Let’stake a look at what do models have beensuperhuman at chat for years. So where'sall the automation? This has been mydriving question for the last fouryears. At OpenAI, I help build themethods that make language models usefulat following instructions and talkingwith people. The work ended up as theresearch behind ChatGPT. At the time, Ithought maybe chat models would lead toAGI. But despite the hype, it becameobvious to me that there was somethingreally big missing. After two years instealth, countless technical challenges,and research breakthroughs, he's beyond. Excited to announce that today TypesafeAI is releasing its first system 1model, a new class of frontier modelbuilt to make fast structured decisionsthat software can use directly. This isone of the biggest important pieces tounderstand. The point of this model isto integrate it into your code. Thismodel isn't even useful if a humantriggers it. The model is useful if thehuman triggers some code to run, orsomething else triggers some code to run,and when the code runs, it passes certaindata to this model, and then it comesback with JSON. That's when it's useful,when it's integrated almost like afunction in your codebase. In order todo this, they had to build a new stackentirely focused on automation, newmodel architectures, parallel samplersfor maximum efficiency and trainingmethods that they call reinforcementlearning for calibrated decisions. Thefirst public version of this is Jevwhich is now available in early access. It is invite only, but you can getaccess to it on things like open routeor the Vercel AI gateway and a coupleother places. While Jev gives up stringgeneration, it's optimized forstructural outputs and it can'thallucinate. This is a key piece. Sinceit has to give the output in a certainformat, it's not going to change or makeup the format, which happens a hilariousamount. Think of Jev as a frontierintelligence function call. Unstructuredstate in, typed probabilistic decisionsout. That's the key piece. You hand it some [ \_\_ ] text data, and you get backa type-safe shape. There have beenother attempts to do this in variousdifferent ways, from attempts to trainmodels to act like this, to tools toforce other models to behave similarly.One that I really liked once itclicked for me is called BAML. The pointof BAML was to make a language thatinterfaces between agents and real code,so that you can define something in aSyntax that of course agents understand,but also to give a specific format and instruction set to the model to get itto output a certain shape. They frame itkind of like TypeScript but as theinterface from the TypeScript to theLLM. For example, here is a textsentiment classifier that they have ontheir site. You give it a label typewhich positive, negative or neutral arevalid for verdict which has label andconfidence, which is a float. Then youdefine the function classify. It takesin text. It outputs a verdict. You useOpenAI GD55 here as the client. You handit the prompt. You use their specialformatting things. And then you can callthis in your TypeScript code in order toget a formatted correctly output. BAMLis basically a made-up language, but whatmakes it cool is how well it interfaceswith other languages and how it fixesall the things that can go wrong. Forexample, I was using this a bunch withGBT OSS120B to find comments thatMentioned sponsors and things. And whenI did that, I had a really goodexperience with it. It all just worked. And when I tried to move off BAML foranother thing I was doing, I learnedthat apparently GPOSS120Bdoesn't format JSON correctly half thetime. One of the many things they dowith BAML is in their runtime, they fixthe malformed formatting in the JSON outputsto make sure it is guaranteed to matchthe format it puts on the tin. When yousay this is the response format and youcall it through BAML, that's the format.Sometimes that takes time, though,because it has to reformat it, fix it,change it all with code that it'srunning. But, and even some high-endmodels can sometimes screw these thingsup, literally can't. If you give it a JSONformat, you get back that JSON format. Itdoesn't handle things like a messagehistory well as input. It's reallylooking for structured program statelike data it can use to make decisions. Already see people getting confused, so Iwant to be really, really clear here. Thepoint of things like BAML, like Jev, andlike all structured outputs is becauseLLMs are not deterministic. If I havecode that formats someone's name, itwill always do the same thing when Icall it with a given name. If I have anLLM that I ask to format the name, itmight do something else. If I have afunction that returns a user object thathas a name, colon, string, and an agecolon, number, and I write code to getthat, it will always be that shape. If Icall an LLM, it might screw up theformatting of the name. It might use afloat for age instead of an int. There'sa lot of different things that can gowrong. The point of Jev is that you cancall it as reliably as you call code, andit's really fast, kind of like code. Italso can do this for a bunch of inputs at once in parallel, which is supersuper cool. And the token cost isinsanely low. It's about 4 cents perMillion tokens in comparison to $10 permillion on a model like Fable. I seemore confusion in chat already. So, isit deterministic? The format of theoutput is yes. There are two ways thingscan be deterministic. The shape and thecontent. The content isn'tdeterministic, but it should be quitereliable. The actual format is what isdeterministic. It will always give youthe format that you define. And on thetopic of cost, the tokens out are freebecause it's so cheap. They frame it astoo cheap to meter. Meanwhile, withLLMs, the output tokens are soexpensive. It's often the majority costwhen you're doing stuff like this. Traditional LLMs can take three to over300 seconds to do the type ofclassification work that this model cando in 70 to 500 milliseconds. That isactually 40 to 200x faster. There isno doubt on that claim. That is real andtrue and based. Even if prompted for aconfidence estimate, models tend to beOverconfident and inconsistent. Themodel can do a task 95% of the time, butdoesn't say when it's in the 5%, youcan't automate the task. Meanwhile, Jevwill always communicate confidence anduncertainty with every output. So youcan calibrate around the accuracynumbers you get, and the answers alsotend to be more consistent. I like theframing here of one of the good usecases being a smart if statement. I knowa lot of y'all don't code anymore, sadly. I get it. But if statements were a greatway of thinking of logic. And that'swhat this model is for—as a thing youput between states to decide what pathyou go down or to map-reduce over agiant pile of data in order to getinsights out of it. And this is one ofthe coolest things you can do with it. Real-time applications. Not that likeit'll build the app, but it is a tool inthe app because it responds in justunder 500 milliseconds worst case. Youcan do something silly like a search. With it or the demo I just showed withchess or checkers, this demo from Mattis really cool as well, where you candefine a term and ask it to generate acolor palette effectively for it, and itshifts that bar at the bottom, and it'spractically real time because the modelis so quick to respond. The final usecase they have in their example listhere is verifying everything: score,judge, verify, guard rail, and detectjailbreaks of LLM prompts, reasoningtraces, and outputs. Stuff like that. Iwant to make a quick point though, because one of the questions I've seenthe most by far is something along thelines of, "Wait, so if I use fourdifferent LLMs to generate an output, Icould use this to judge it." You dounderstand how expensive it would be togenerate all four of those, and how sillyit would be to have a model that's onlyusing one side of its brain to judge that. The benefit of other LLMs is that theycan reason. They can think through theDecision. They can walk through yourcodebase using agentic tools in order tofigure out what changes to make. They can grow their own context over time andprompt themselves with sub agents. Theycan do all of these different things. Itmakes no sense at all to give a modelthat takes a bit of text input andimmediately responds with JSON threedifferent implementations of somethingby three different LMS. It just doesn'tknow enough to make a [snorts] gooddecision there. I want to beat into yourheads how this works. And I'msorry for those who get it because it'sgoing to be tedious, but I'mincreasingly tired of comment sectionsthat fundamentally don't understandwhat's being talked about. This is amodel that works like a switchstatement. It is roughly as intelligentas a switch statement. It's forclassifying things. It doesn't know howto look through a codebase to make agood decision. It doesn't have theIntelligence to distinguish between theoutputs of language models. And mostimportantly, the context window is tiny. It's only 32k tokens. That doesn't meanit's not cool, and it is cool as hell.The speed and the cost are insane. Theydo a comparison here against an LLM forresponding to a query. Type-safe race ask LM versus type safe.He got back the response immediately. Itwas given 27 questions about a bunch ofdata, and it responded to all of themwith the right format, with numbersranking them and the type as well asconfidence on its decisions for thesethings. It took 0.114 seconds, and itcost an amount that rounds to zero. Meanwhile, Terra, once it finallyfinished, took 9 seconds and cost 1.3.That is a comical gap here. 170x cheaperand 70-something times faster. Respectto them for keeping the cost perworkflow in their chart in log. Theycould have made this linear, and it wouldhave looked hilarious. The only modelsThey measured that had betterclassification in their demo workflowsthan Jev were Soul and Opus 5. Theydidn't test Fable or Astra, but likethose are way too expensive. Youshouldn't even look at them for this. But it is outranking DSV4 Flash invarious tests for ranking things. and itowns the PTO Frontier with almost twoorders of magnitude again because it'svery specifically focused on this onething. They didn't publish the benchthey used here, but they gave someexamples. There's an alert. The nextstep is a question. Is this unauthorizedactivity with options for what it canchoose? Once that happens, we determinedifferent flows it goes through. And ifwe have decided that this is anincident, then we ask what state is theincident in and it has 11 readings for it. It processes all the data. We thenask what action it thinks we should takeand then we rank the results after. Theyare surprisingly transparent with a lotOf things. Like they love to say all thethings the model isn't good at. This iswhere the numbers on their homepage comefrom. The 193.6x faster and 444.6xcheaper. But they say that they expectthis is the higher end of real-worldgains. The context of these workflowswere not deliberately chosen norconstructed to make our model look good. Cool. They're using the average of GBD6Astra and Fable 5.1 as the referenceanswer. That's why they don't appear inthe list and also why the data might notbe perfect since those models might bewrong as well. The LMS uses their system1 LM wrapper, which constrains LLMs tooutput structured decisions compatiblewith their API. We found it to be themost accurate way to get decisions fromLLMs, but this tends to be slower andmore expensive than giving decisionswithout probabilities. I find that theylove to tie the idea of hallucinationand type safety. Type safety being youhave a contract for what it shouldOutput, and it follows the contract. That's why they're type-safe AI becausethe shape of the data will always behonored. Hallucination goes a lotfurther than hallucinating fields in areturn type. But in this particularcase, it can be pretty brutal if your LMhallucinates that it can change thefields when it can't. That does suck fortype safety. The way they frame it hereis that having a hallucinated tool callcan be inconvenient for an agent, butit's an absolute dealbreaker if it'spart of a system with latency guaranteesor if it's buried several layers deep ina dependency chain. Yep, that part Iabsolutely agree with. No matter howsmart an existing model is, it can stillhallucinate and have type errors. Theyshow that here where crazy enough, Astraactually has more errors with structuredtool outputs than Sole Terra and Luna. It actually has more than Terra andLuna combined, which is kind of crazy.But then you start to look at models. From a certain anthropic where Haiku hada 45.5%error rate. That model is so bad and itneeds to stop being used for anything.It's about a year old now or might be overthat. Just anthropic is treating Haikuas dead. We should do them the favor ofdoing the same. But of course, the numberthat matters here is Jev with a 0%. This is for structured output errors. Whenyou give it a JSON format and tell it tohonor it, Haiku cannot do it. If weswitch over to tool call error rates,funny enough, anthropic models startdoing a lot better and OpenAI modelsstart to have more problems. But ofcourse, Jev still is at zero. It honorsthe format it's given. They made a demoof it playing Doom, and the engineer whomade it was concerned about cost, butthey figured out even though it'srunning 10 times a second, the costwould still be under $7 an hour becauseof how efficient the model is and howcheap it is to run. Remember, it doesn'tHave vision. So this is all from gamestate data that it's being given. Theapplication state is handed to the modeland it's given the JSON format on whatit should decide to do next, and itdecides. You will see some quirks withthat, though. Watch how often it likejust rotates left and right wildly. That's because every single frame it'stold to make a decision. So it doesn'tnecessarily know what decision it madebefore. It doesn't know it turned left,so keep turning left. So it's like okay,looking here, I'll turn left. Okay, stateturn right. On every single frame,effectively its brain is being wiped, andit's making a new decision. You get theidea, though, and I saw this with thechess as well. It's not meant forlong-running jobs. It's meant for making aquick decision on the fly or being partof some other long-running jobs work. Theycall out that this demo is again onstructured state as a data structure,with text, not on images yet. This isParticularly exciting. This model havingimage support will be super, superuseful. The model is also insane at wikiracing because it makes decisions soquick. So when it has the contents of anHTML page and it knows where the linksare on it, it can choose which one toclick and continue going much faster. Yeah, it is very, very fast. Terra evenhad a hallucination during its run.That's funny. Let's take a look at whatpeople are using the model for. Theyclaim you can't use it for generatingtext, but if you give it the ability torespond by choosing which character itthinks makes the most sense, you cankind of get it to do things. Here's onethat I think actually makes way moresense from Chris over at Verscell. It'sthe idea of using JSON render with Jev.The point of JSON render is to make iteasy to create a component and use itfor arbitrary JSON. So, you can link theoutputs of an LLM into your UI in a morevisible and useful way, but you have toWait for the LM to generate the JSONbefore you can update the UI. What ifthe model could do that comicallyfaster? That's a pretty big difference.Yeah, it's insane. It responds with thewhole thing at once because it's notstreaming in text. Everybody's beentelling me Ryan's been cooking with it.Let's see what he's done. 1,500 of myown emails that I've exported from uh myemail. And uh we're going to run thisclassification model because I gotaccess to it and see how well it runsthe classification on it. We're going todo a batch of 100 emails just to startout with eight workers, and we'll see howlong it takes to do it. So, let's start.Boom. 100 emails done. It doesn't tellme how long it took. The average was 200milliseconds. 200 milliseconds per email. P95 was 240milliseconds, and it did 38 per second,which is amazing. So, this is a muchbetter example. I already use LLMs to goThrough my email, it's expensive, butit's fine. This is a first pass to likeget the quick, low-effort spam things outof your way. Super useful. It's thethings that are too cheap to justifyrunning an LM for, or the things that arerun too often to wait that much timefor. Once this has image support, anexample of something we can do with thisis take a bunch of frames for my videoand ask it, does this frame havesensitive data or PII on it, like doesit have an email address on it? And totell me where it is, so I cango find these and clean up our videosbefore we release them. That type ofthing is so nice. I think computer usewill also be way more compelling with it. Once it has the ability to see what'sgoing on, but it's already really goodat navigating websites because it canjust take the HTML and then decide whatto do based on the current page content.There's an example of it booking flightsin under 7.1 seconds, right? Yeah. That's crazy. LM's doing this take so much longer. I am scared to even makethis video, if I'm being real, because ifI increase excitement too much aroundthis model, we're going to end up withsome really, really dumb things. Forexample, this tweet from Brain Trust.Their goal is to increase observabilityfor agents. This is a really bad thingfor them to tweet. It makes me not trustthem because they suggest that youshould use Jev as a judge scorer in atool like Brain Trust to decide betweenoutputs from LM. They're legitimatelysuggesting that you replace an LLM thatyou use for judging, for scoring agentresponses, with Jev. And the reason is sothat you don't need to spend time andresources prompting a general-purposemodel into an LLM judge. What thoseprompts take [ \_\_ ] 30 seconds towrite. Not even. And like, if youjust give it the examples from somethinglike Jev, it's going to follow them. This is hilarious. On that note, thereWas another demo that I actually thinkis really cool conceptually. Like itlooks crazy, and it helps show whatcapabilities this model has, but if youactually think it's a good idea to use anon-reasoning classifier model forcompaction for your context, then Iwould plead that you never ever everstray from the defaults in those tools,because you just fundamentally don'tunderstand yet. And don't worry, you'renot the only one. I don't think anyonehas to. Context compaction is a complextopic, and it's gotten more complex over the years. I will do my best to tellTL;DR why this is a bad idea, but youshould just read my longer post ifyou're curious. First thing, compactionisn't a filter. We're not just goingthrough your history and selectivelydeleting lines from it. We aresynthesizing a summary based oneverything that's happened so far. Jevalso doesn't have enough context to evenknow what it's deciding on. Then we justSaid, it doesn't have the tool calledoutputs and results. It only has theinputs and a little bit of the contextfrom the thread and not that much of it,because it's 32k tokens of context. So itdoesn't have enough data to make adecision. Even separate from the factthat it doesn't have access to the reasoning data at all because thereasoning data is never shared by thelabs anymore. When you call the Claudeor CodeX APIs, you don't get backreasoning. You might get back anencrypted payload that they can then mapto the reasoning on their end. Or youmight get a summary if you're lucky, butyou don't know what the model wasthinking when it made a decision. So, anyattempt to compact that is not going toinclude those decisions. This gets evenworse when you remember that Enthropicis making changes to how historypreservation works such that if you edityour history, you lose all of thereasoning traces for that context. There's also the fact that models aretuned on the way that they compact. Theydo this in training. Now, models learnhow to handle compaction well, and theymake adjustments to the weights, and howthis works through the process oftraining through RL. The compaction thatthe models do is already pretty damngood, and changing what history they havebefore they do it makes even less sense. Another important thing to recognize isthat cache writes are often, if notalways, for agentic use cases, much moreexpensive than cache reads end up being.And when you remember how cacheinvalidation works, you realize thatthis will probably break the cache quitea bit if you run it actively enough. Because if you have a history like 1 2 34 5 6, and then you delete number two,everything three onwards has to berewritten because the history has to beprefixed. Any changes early meaneverything past that point'sinvalidated. The model's given weirdInstructions as implementation, too. Things like whatever's not kept ispermanently deleted, but the assistantcan rerun a tool if needed. Some toolsare destructive. It's not that simple. And you'll also get to a point if it'sclassifying in such a shallow way whereit gets stuck in a loop where it'salready removed everything it thinksdoesn't matter and it only has left whatdoes. No. And people have actually triedthis and benched it. It doesn't performwell at all. There is one benefit tothis style of compaction. It's so fastthat it fits in the attention span ofthe average Twitter user. So, the videois guaranteed to go viral. But you'renot like the average Twitter user.You've been watching this video for muchlonger than the attention span of theaverage Twitter user. And for that, Iappreciate you. If you haven't hit thesub button, I would appreciate that aswell, cuz a lot of y'all haven't. And itseems like you want this type of long-Form content. You should considersubscribing to signify that. And as aTwitter user, trust me, you don't wantto be like us. Avoid it to the best ofyour ability. I do think there are waysthat a tool like Jev can be useful tothings like agentic dev work. Not havingit write code or compact by context or change anything that the harness isdoing. The harnesses are pretty danggood now. You should lean into the factthat billions upon billions of dollarsare being spent on that and not reinventthe wheel constantly. Don't get mestarted on the people who think they cancompact their history by taking theirentire context and then shoving it intoa small image. Insanity. Anyways, athing you can use this for is goingthrough large amounts of data. Forexample, all of your history usingmodels. Here are my 1,118T3code chats that I did on this particularmachine categorized and classified usingJev. It classified 32,311Messages across 1118 threads. And doingall of that cost 37. And it found that nearly half of what Idid was bug fixing and PR work,specifically reviewing and managing PR.So was 20% of my threads. Remember thatthe results here are classifications. Sothey're usually scored. It's notresponding with a list of strings onwhat to tag. It's taking all of thevalues inside of the body there andgiving you a threshold on a scale of 0to one for all of them. And you canchange what you want to count and notcount. For example, here with the simpleweb app I made, I am changing what barwe have set for each of theclassifications. So if we have it at an80% confidence interval, then 22% of mythreads are expanding scope. But if Ibump that up to 90%, it's down to 6.8because it was not sure in the rest ofthose cases or as sure, so to speak.Funny enough, when I had Astra buildthis, it did note some of the things. That it wasn't great at, particularlytrying to identify which threads couldbe used for content for me. So, one ofthe ideas it had was what if we canfigure out which threads Theo shouldsave to use in a video. And it triedmultiple times to revise the prompt toget better threads for that. And itstill concluded about half of my threadswere worth using for content. So, it'snot good at this. It's not smart enoughto do those types of complex reasoningthings, whereas to make a decision thatrequires thought. It's like one lastsimple way to think of this: how manyseconds would it take for you to answerthe question once you've perceived all of the information? If I show you apicture of a person wearing a shirt, howmany seconds does it take for you to saywhat color it is? If the answer is under10 seconds, this model's probably goodfor it. If it's over 10 seconds, thismodel's likely less good for it. This isthe point I'll end on, and it's similarTo the one I started on. I really want toemphasize the system one point becauseI'm tired of people not getting it. Ifthe task requires thinking, this modelis not right. If the task requiresclassifying, organizing, ranking, realquick decision-making, this model isincredible. It's a system one model. System two is when you think about athing. System one is when you reactbecause your brain thought for you. It'salmost like the reflex. It's like whenyou tap your knee and your leg kicksout, that kind of thing. This model isdesigned to work like that first part tobe really fast and quick. If you'rethinking of this model in terms of howit replaces the other ones you use,you're probably not thinking about itcorrectly, unless you're doing a lot ofstructured output work. The value ofthis model is that it made so manythings that weren't really realisticbefore way cheaper and faster in a way that is actually kind of cool as aProgrammer. But you shouldn't be viewingthis as a tool you use in Codeex orClaude or even in your terminal. Youshould see this like a new library youinstall or a function that you call. Itis meant to be integrated in the toolsthat we build, not used as an inferencefarm to generate code or text or allthese other things. Somebody in Chinajust said the only way this wouldreplace an LM is if you're using thembadly. I mostly agree. There are a lotof use case for structured output typestuff, and this is where it is strongest. I think this model is really cool, andI've been enjoying it a lot. I have afeeling you will too, as long as you goin with the right mindset. Don't usethis to replace fable or judge betweencomplex topics. Use this like an ifstatement, and you'll have a lot of fun.With it. Let me know how y'all feel. Anduntil next time, peace, nerds., Jev Is Incredible, Theo (t3.gg), 01m31yvcqbqt9nk7429vnenevr.