Jev + Claude Code: How Fast-and-Slow Thinking Can Cut AI Agent Costs by 90%

Few models in recent years have genuinely turned heads, but Jev (named after the "Jevons Paradox") is a notable exception. It's not another bigger, more powerful language model — it's a fundamentally new kind of "System 1 model" designed to sit at the front end of your stack: fast, cheap, and structured, built specifically for decision-making. When combined with "System 2" coding agents like Claude Code or Codex, it enables extremely tight, low-cost feedback loops in programming workflows. This article breaks down how that works in practice.

What Is Jev: No Text Generation, Just Probabilities

A standard large language model works like this: give it a prompt and some data (say, an invoice plus the question "is this invoice fraudulent?"), and it generates a response token by token. Due to the autoregressive architecture, this process takes time — and the longer the sequence, the longer it takes.

Jev works completely differently. You give it the same prompt and data, but you also provide a predefined set of options (fraudulent / clean / needs human review), and it returns a probability score for each — for example, "this invoice has an 88% probability of being clean." It generates no text whatsoever; it just returns probabilities across the answer set you provide.

Because of this architectural difference, responses are extremely fast — typically 200 to 300 milliseconds. Think of it as a "smart switch statement": take the returned probabilities, feed them into an if-condition, and you can make rapid decisions across massive volumes of data.

In TypeSafe's playground, Jev exposes a few core primitives:

• Null (truth evaluation): Assesses the truthfulness of a statement, returning a yes/no probability. Paste in a fictional fraudulent invoice and it gives 85% true; add fraud signal descriptions and it shifts to 94%, with results staying stable across repeated runs with only 2–3 percentage points of variance.
• Choice (multiple choice): Define up to 255 options. Reframe the invoice question as "human review / fraudulent / clean" and it returns 98% fraudulent, 2% human review — in under 100 milliseconds.
• Score (spectrum scoring): Up to 11 scoring tiers (0–10). Score sales leads, for instance, by defining "0 is a student with no budget, 3 is a large enterprise" — input a corporate decision-maker's profile and it returns 2.91, which can then trigger different follow-up logic.

Another classic use case for the scoring primitive is log triage — feed in a "connection pool exhausted" log entry and it returns a severity score of 2.99; anything over 2.5 immediately pages the on-call engineer. Because Jev is so cheap and fast, you can monitor critical systems in near real time.

---

The architectural principle behind Jev is fundamentally different from traditional autoregressive language models. Standard LLMs use next-token prediction — every word generated requires a full forward pass, and latency scales linearly with sequence length. Jev is closer to a discriminative model than a generative one: its task isn't to "write an answer" but to "select an answer from candidates," making it essentially a multi-class probabilistic classifier. This lets it sidestep the latency bottleneck of autoregressive inference and compress single decisions down to milliseconds. By analogy, it resembles BERT-style fill-in-the-blank models more than GPT-style continuation models. The tradeoff is that it can't handle open-ended generation — but in structured decision scenarios (fraud detection, log triage, task routing), this limitation actually becomes an advantage: the output space is bounded, results feed directly into if/else logic, and you don't need another model to do "intent parsing."

---

System 1 and System 2: A Division of Cognitive Labor

TypeSafe positions Jev as a "System 1 model" — a framing clearly inspired by Thinking, Fast and Slow. Human cognition operates in two modes: System 1 is fast, automatic, and reflexive, requiring almost no conscious effort; System 2 is slow and detail-oriented. Crucially, with practice, certain tasks can migrate from System 2 to System 1 — like learning to drive: at first you're consciously checking mirrors and gear shifts (System 2), but over time it becomes second nature (System 1).

Applied to AI: models like Claude Fable 5.1 or GPT-6 Astra — slower, more deliberate — are "System 2." Jev is "System 1." It's fast enough to run always-on in the background.

The two in combination create something interesting: Jev produces a stream of instant, probability-weighted decisions that if-statements act on automatically; a deeper System 2 model can periodically reflect on "what's our strategy here, can we improve it," then rewrite the criteria and instructions that System 1 uses, feeding them back to Jev. That's a closed loop where System 2 trains System 1.

---

This framework draws on psychologist Daniel Kahneman's dual-process theory from Thinking, Fast and Slow. System 1 relies on intuition, pattern matching, and experience with minimal cognitive overhead; System 2 handles logical reasoning, planning, and deep analysis — but it's slow and resource-intensive. In software engineering, the metaphor is particularly apt: a compiler's syntax checking resembles System 1 (rules are explicit, execution is instant), while an architecture review resembles System 2 (requires contextual understanding and tradeoffs). Classifying AI models this way is fundamentally an exploration of which judgments can be codified and structured to reduce per-decision costs. TypeSafe's innovation is the attempt to train a class of models to achieve "intuition-level" speed and cost on specific judgment tasks, while using System 2 models to continuously calibrate those judgment criteria — forming an evolvable loop.

---

The Minecraft Experiment: Astra Plans, Jev Executes

The author ran a vivid demonstration: having Jev and GPT-6 Astra collaborate in real time to play Minecraft. The division of labor: Astra handles high-level planning (build shelter first, prepare tools, mine before dark, push toward iron and diamond pickaxes); Jev handles immediate execution (rapidly switching between available tasks based on current state using multi-select).

Jev reads the intermediate goals, current state (health, hunger, time of day, mining progress), history, and the list of available tasks, then makes multi-select choices; when feedback is needed it pauses, hands off to Astra to assess the situation and issue new sub-goals. Codex reviews every two minutes, and also debriefs on setbacks like "Jev died" — analyzing why it happened and how to improve next time.

This almost perfectly mirrors how humans play games: System 1 handles most of the action, System 2 periodically reflects and retrains System 1. After running for roughly 10–20 minutes, Jev built a shelter with a door, obtained a stone pickaxe, then a diamond pickaxe, and eventually reached the Nether.

Coding Workflows: Four Real Problems Jev Can Solve

The real focus is Jev's role in AI-assisted software development.

Skill Selection: Saving Tens of Thousands of Tokens

Claude Code users often install dozens or even hundreds of skills, and each skill description consumes tokens from the context window. The official Jev documentation cites one example: the Hermes agent has 182 skills, and when the agent selects skills on its own, the wrong-skill-loading rate is around 17%; with Jev's recommendations, that drops to 7%. The author routed all skills through Jev for on-demand recommendation, saving roughly 10,000 tokens per session.

Browser Verification: Sub-cent Feedback Loops in Seconds

Someone used Jev combined with browser automation to look up flight prices in about 7 seconds at a cost of roughly 0.4 cents. That means you can run Jev locally to quickly verify hundreds of user flows in your application. Because Jev navigates familiar sites (like Google Flights) with the intuitive speed of System 1, you can build fast, cheap verification agents and hand the bug-fixing off to System 2 agents.

Taking it further, teams have built "highly parallel adversarial test suites" — dozens of browsers running in parallel, randomly clicking around, simulating real users trying to break the app — for just a few cents. Each PR can spin up tens to thousands of Jev agents in parallel hunting for bugs; the author estimates the daily cost at only $5–10. At that point the bottleneck is no longer tokens, but compute.

Qualitative Code Checks: Turning Lint Rules into Natural Language

The author demonstrated using Jev to clean up "junk comments" — evaluating the accuracy and usefulness of comments. 150 comments processed in 9.3 seconds for roughly $0.01; scanning the entire codebase (~1,700 comments flagged for improvement) comes to about $0.57.

This kind of "qualitative check" is traditionally hard to cover with lint rules. With Jev, you can ask directly in natural language: "Does the function name describe its behavior and side effects?" or "Are secrets or financial data being logged?" — flag it if they are. Every PR can run these checks at negligible cost.

---

Traditional static analysis tools (ESLint, Pylint, etc.) rely on predefined rules and excel at catching formatting errors, unused variables, and potential type mismatches — structural issues. But they're nearly blind to "semantic quality." A comment can be syntactically valid while being stale, misleading, or redundant — no lint rule can catch that. Jev opens up a new class of "semantic lint" capability: it understands the intent of a natural-language question and can make qualitative assessments of code snippets. This is directionally similar to LLM-based code review tools like CodeRabbit or Sourcery, but Jev's speed and cost profile make it more suitable as a permanent fixture in CI pipelines rather than something triggered only on demand. A three-layer code quality stack seems increasingly plausible: traditional lint for the syntax layer, Jev-class models for the semantic layer, and GPT/Claude-class models for the architectural layer.

---

Code Smell Scanning

Drawing on Martin Fowler's Refactoring and its concept of "code smells" (duplicated code, dead code, magic numbers, etc.), the author had Jev scan an entire codebase. A thorough scan required 28 million input tokens and cost just $1.19. The approach: have System 2 run small-scale checks first, review results, refine criteria, then let Jev do the large-scale sweep.

Jev-Based Code Review: Putting Attention Where It Matters

The author envisions a more complete pattern: having a coding agent build its own "System 1 understanding" of the codebase — a set of invariants, code smells, and scoring criteria. Every PR is automatically checked against a list of 50–500 items, like a senior engineer doing an intuitive review from 100–1,000 angles, with serious issues routed to the System 2 main agent for fixes. Security-related issues can even be routed to specialized models (like GLM 5.3), since mainstream cloud models often refuse to handle security-adjacent requests.

This direction already has real-world validation: an engineer at Sentry mentioned that using Jev-class small models in their security pipeline was 5x cheaper than their previous approach, faster, and maintained high accuracy. The author had an agent running Opus 5 evaluate the approach and found that reducing the token count for code review by an order of magnitude represents a massive cost advantage on its own.

A Trend Taking Shape

The author admits they haven't been this excited about a new model since ChatGPT launched four years ago. Their read is that this will become a lasting paradigm: System 1 models (Jev, or equivalents that OpenAI or Anthropic may release) working alongside System 2 models (like Claude Fable) to achieve better outcomes in agentic coding.

System 1 handles extremely cheap, broad sweeps across entire codebases and diffs, routing only the strongest signals to System 2 for maximum attention; System 2 then rewrites System 1's criteria in return, giving agents genuine reflexive capability. More robust security pipelines, cheaper code review, round-the-clock adversarial testing, rapid qualitative checks — all of these applications point toward a future where the cost structure of programming is fundamentally restructured.