AI Coding Agent session compaction with Jev TypeSafe's Jev model takes unstructured input and returns typed probabilistic decisions, reporting 70–500 ms end-to-end latency that TypeSafe says is 40 to 200x faster than frontier chat LLMs for "System One shaped" queries. The model is positioned for coding-agent session handoffs, where a developer's AI DevKit command uses Jev to select which state to pass between manager, executor and reviewer agents instead of forwarding full transcripts. TypeSafe claims Jev's schema-constrained output "can't hallucinate" for these queries and that higher confidence correlates with higher accuracy, though the author states he has not benchmarked those numbers. Most of my coding agent work now runs through more than one agent https://codeaholicguy.com/2026/08/19/how-i-run-ai-coding-agents-as-a-team-with-ai-devkit/ . A manager agent brainstorms with me, starts an executor, checks on it, and later brings in a reviewer. Sometimes I resume a session the next morning. Sometimes the manager is running on a VPS and I talk to it from Telegram. Every one of those moves is a handoff. Each time, the same question comes up: what does the next agent actually need to know? The obvious answer is the transcript. That doesn’t work for long. This post is about a small AI DevKit command that tries to answer the question better, and about Jev, the model behind it. The problem is state handoff, not context length Coding agent sessions get long quickly. An hour of implementation work can produce hundreds of messages: the original instruction, clarifications, file reads, test runs, failed attempts, retries, status updates, and the occasional “let me check that again”. Somewhere in there are the facts that matter: - what the user asked for, including the constraints they added halfway through, - which decisions were made, and why, - which files changed, - which commands ran and what they proved, - what is still blocked, - what the next step is. They are mixed with a lot of noise. The same npm test output appears four times. A path the agent tried and abandoned takes up twenty messages. Status chatter “Now I’ll look at the service layer” says nothing a later reader needs. When I work with a single agent, this is mostly an annoyance. The harness compacts the context, some detail gets lost, and I repeat myself. In orchestration it turns into a reliability problem. If the manager hands an executor’s state to a reviewer and the handoff drops a constraint, the reviewer approves the wrong thing. If a resumed session loses the validation evidence, the agent reruns work or, worse, claims something passed when nobody checked. A bigger context window doesn’t fix this. What fixes it is choosing the right state to pass on. Jev in one sentence Jev https://typesafe.ai/blog/introducing-system-one-models-and-jev is a model from TypeSafe that takes unstructured input and returns typed decisions, fast. TypeSafe calls it a System One Model and sums up the idea as “unstructured state in, typed probabilistic decisions out”. You don’t ask Jev to write. You give it a piece of state and a set of typed questions: pick one of these categories, give me a probability for this yes/no. It answers in that shape, with a probability or confidence attached. According to TypeSafe, that narrow focus buys a few things: - Type-safe answers. The output always matches the schema you asked for. TypeSafe goes further and says Jev “can’t hallucinate” for these queries, because the answer is constrained to the options you defined. - Calibrated confidence. Every answer comes with a probability, and TypeSafe says higher confidence means higher accuracy. - Latency. TypeSafe reports 70–500 ms end to end, and says that is 40 to 200x faster than frontier chat LLMs for “System One shaped” queries. I haven’t benchmarked these numbers carefully, so treat them as TypeSafe’s claims. What matters for this post is the shape: Jev isn’t competing with chat LLMs at writing code or explaining things. It does the small, frequent judgement calls that sit between those bigger steps. Structured output isn’t new I want to be careful here, because it is easy to present this as a brand-new idea. It isn’t. Jev doesn’t introduce the idea of structured AI output. Engineers have been moving toward “AI as a structured-data engine” for a while, with JSON mode, tool calling, and schema-constrained decoding. Last year I wrote The turning point in AI https://codeaholicguy.com/2025/05/31/the-turning-point-in-ai/ . The first point in that post was that AI isn’t new. What changed was access, and with it, how engineers build. The example I used was a weather app. The old way: an engineer writes the integration by hand. The early-AI way: the engineer asks an LLM to help write that same integration code. The shift I cared about was a third option: ask the model directly for the temperature, humidity, wind speed, and chance of rain for a location, in a structured format, and build the app around that output. In that post I put it as “Treat AI as an engine you can build around. Prompting becomes programming”. Structured output was the important part then, and it still is. Once a model returns clean JSON instead of a paragraph, you can put it inside a program. You can branch on it, store it, test it, and pass it to the next step. What Jev changes is the cost of each call and what the call returns. If a typed decision takes a few hundred milliseconds and comes back with a calibrated probability, you can afford to ask it many times inside a loop, not just once at the edge of a user interaction. Classifying every message in a session stops being an expensive batch job and becomes something you can simply do. That’s the part I find exciting: an old idea that is now cheap enough to use in places where it used to be too slow. Why session compact needs a typed decision layer A normal summary keeps the story of a session. For continuing work, I don’t need the story. I need the operational facts. So the first design question for session compact was: what should survive? Keep: - user instructions and constraints, - decisions, - code changes, - command evidence, - validation evidence, - blockers and open questions, - the next step, - facts worth proposing as long-term memory. Drop: - routine status updates, - duplicated tool output, - abandoned exploration that led nowhere, - anything sensitive, such as tokens, keys, and credentials. Written that way, this is a classification problem, not a writing problem. For every event in the session I want answers to four questions: 1. Which category is this? 2. How important is it for continuing the work? 3. Should it survive compaction? 4. Does it contain something that shouldn’t be stored? Each question has a small, fixed set of possible answers. That is exactly what Jev is built for. The categories AI DevKit uses are: - user instruction - decision - code change - command evidence - validation evidence - blocker - next step - memory candidate - discard Once every event has typed labels, building the compact artifact doesn’t need another model call. Plain code can do it. How AI DevKit implements it The command lives under the existing agent session namespace: Find the session you want to compactnpx ai-devkit@latest agent sessions --all Human-readable handoffnpx ai-devkit@latest agent session compact --id