Jev Explained: Stop Prompting for Text, Start Asking for Decisions

Postmark is just the tiny demo I built to feel it with my own hands, source | case study. The real classifier story lives in LLM-Orc-Station (GitHub).

Little Personal Story

This did not start with Postmark. It started with a client project for school kids.

They wanted a simple Q&A app: a kid types any question, the backend answers it. Easy, right? Except someone has to pay for every answer. You cannot send "what is 2+2?" to an expensive pro model, and you cannot send "compare photosynthesis and respiration with diagrams" to a free mock model and hope for the best.

So I needed a classifier in front of everything. Kid asks → classify complexity → route to the cheapest model that can actually handle it. That classifier is the heart of LLM-Orc-Station (GitHub): simple → mock (free, 25ms), medium → gemini-flash ($0.075/M), complex → gemini-pro ($3.50/M), plus key rotation, fallbacks, and metrics.

My first version used pure heuristics, no LLM call, because calling a model to decide which model to call felt recursive and expensive. Word counts, ? counts, verb lists (analyse/compare/evaluate → complex, explain/describe → medium, code/function → medium). It worked. It was deterministic and instant. And then the edge cases piled up. "Prove the Riemann hypothesis" is 4 words but definitely not simple. Every new subject needed a new keyword. I was maintaining a tiny English exam instead of a router.

My second thought was the obvious LLM fix: "just ask GPT to return JSON with complexity." It worked, sort of. Then it returned complexity: "kinda hard lol". Then it wrapped JSON in markdown. Then it took 2 seconds and output tokens, on every single request, before I had even called the real answering model. I was paying twice to answer once.

That frustration was still fresh when I was going through tech news and everyone was going crazy about this new model release by TypeSafe AI: Jev. Not another chatbot. A System One model ( Based on Daniel Kahneman's Book ) that skips tokens entirely and returns decisions. I somehow got into the early access program, so I had to try it.

I built Postmark afterward just to see how it works. It is obviously very simple, one page, one API route, paste a draft, get tone / virality / cringe_risk back as stamped bars. Same classifier pattern as the school router in LLM-Orc-Station, just funnier to look at.

1. What Am I Trying to Explain?

One shift:

Most AI apps do Prompt -> tokens... -> text -> parse + validate -> decision.

Jev does State + Questions -> typed Decisions -> code.

Most models today, ChatGPT, Claude, Gemini, Qwen, share one idea: generate tokens. You give input, the model reasons, it emits token after token until you get text, code, or JSON.

Jev, developed by TypeSafe AI, takes a different route. It is the company's first System One Model, a new model class built for software automation. You pass application state plus structured questions, it returns typed probabilistic decisions your software can use directly.

TypeSafe phrases it as "unstructured state goes in, typed probabilistic decisions come out." Less chatbot, more AI-powered decision function.

2. What Problem Creates the Need for It?

Software rarely needs a paragraph. It needs queue = billing, priority = high, refund_review = true.

Take the support example from the Jev writeup I read: "the customer says their package arrived damaged and wants a refund." A normal LLM would write a long explanation of what to do. But the app actually needs three decisions. Same with my school router: I do not need prose about the kid's question, I need simple / medium / complex so I can pick a model.

With a chat model that looks like this:

Kid's question
  ↓
Prompt ("return JSON with complexity...")
  ↓
Token 1 → Token 2 → Token 3 → ... → Token N
  ↓
Text ("Sure! Here's your JSON: ```json {...}```")
  ↓
strip markdown → JSON.parse → validate → retry on failure
  ↓
Software decision

Every step is a liability:

1. You pay for output tokens for values you already knew the shape of. In a router that runs on every request, that doubles the bill before you even answer.
2. Schema drift. Today "complex", tomorrow "COMPLEX!!", next week a 4th tier your router does not know.
3. It is slow. Sequential generation for what is fundamentally a judgment call. My router budgets are mock 25ms, flash 800ms, pro 2000ms, adding seconds just to pick a model kills the point.
4. One question = one generation. Want complexity + subject + risk? Either one mega-prompt that conflates everything, or three slow calls.

3. What Did I Initially Think?

That I could dodge it.

Attempt one was heuristics in LLM-Orc-Station, classifier.ts, deterministic, free, instant. Great until English got creative.

Attempt two was JSON mode: response_format: { type: "json_object" }, zod on the way out, retry once. Works in a demo. In production you are still babysitting a text generator pretending to be a function. No real confidence, still slow, still able to invent values outside your list.

I was treating a language model like a decision function and paying the text tax every time.

4. What Did I Discover?

Jev is not "a smaller LLM." It is a probabilistic decision model. Traditional LLMs optimize for string generation, every token depends on previous tokens. Jev optimizes for structured decision-making:

Traditional LLM:
Input → Reasoning → Token 1 → Token 2 → ... → Text → Parse + Validate → Decision

Jev:
Application State → Jev Model → Typed Decisions → Software

It evaluates multiple declared questions in parallel instead of generating a separate token stream per answer. That architectural difference is where the speed and cost claims come from.

And the questions are typed. Three primitives cover almost everything:

Choice: pick one

Which queue should receive this ticket? Options: billing / technical / shipping / human_review

Returns the choice plus probabilities. Used for classification, routing, tool selection, agent selection, workflow branching. In Postmark I used it for tone: hot take / humble brag / inspirational / informative / funny / vulnerable.

Score: rate on a scale

How urgent is this support request? Scale 1 → 5

Used for risk, quality, prioritization. In Postmark I used it for virality: Ignored / Mild / Solid traction / Breakout on 0 to 3.

Boolean / Noul: yes or no with likelihood

Was a refund issued? true

TypeSafe calls this primitive Noul. Their workflow eval framework treats Noul, Choice and Score as the three core types. In Postmark I used it for cringe_risk as a 0 to 1 likelihood with true/false criteria.

5. What Mental Model Explains It?

TypeSafe borrows from Kahneman: thinking fast vs slow.

Some work needs complex reasoning and open-ended generation, keep frontier LLMs for that. Other work is just decisions:

• Should I retry?
• Should I call this tool?
• Is this request risky?
• Which queue should receive this ticket?
• Should I escalate to a human?
• Does this answer satisfy the requirement?

System One Models target that second category.

Most agent loops today are 90% System One decisions wrapped in System Two generations:

User → LLM → reason → pick tool → call tool → reason → retry? → reason → continue...

The hybrid version is cleaner:

Frontier LLM (complex reasoning)
        │
  ┌─────┴─────┐
  │           │
 Jev        Tools
  │           │
Fast decisions → Execute
  │           │
  └─────┬─────┘
        ↓
   Agent State

Postmark is that idea shrunk to one page: State + Questions -> Decisions -> UI. Thresholds live in plain code next to the UI, not hidden in a prompt. Slow models reserved for work that actually needs prose.

6. How Does It Work Technically?

Probabilities and confidence, not just labels

Jev outputs are built around uncertainty. Say it decides refund_required = true with confidence = 0.94. Now you can write policy:

confidence > 0.90 → auto-process
confidence < 0.90 → send to human

AI does not have to decide everything autonomously. The app decides when AI is trusted and when a human steps in. TypeSafe says calibrated probabilities and confidence come back with decisions, that is the whole game for automation.

Parallel sampling is the big difference

Autoregressive models go Token 1 → Token 2 → Token 3 → .... Long answers need long chains.

Jev evaluates independent questions from the same state in one pass:

                ┌── Is it urgent?
Application ────┼── Should it be escalated?
State           ├── Which department?
                └── Is a refund required?

Same in Postmark: tone + virality + cringe_risk from one draft in one call. TypeSafe says this parallel sampler is a core reason for the latency win.

Architecture: three pieces, one new training idea

TypeSafe discloses principles, not a spec sheet. Three components:

1. A new model architecture: built for decisions, not generation.
2. A parallel sampler: one evaluation, many questions.
3. RLCD: Reinforcement Learning for Calibrated Decisions. RLHF optimizes for "give the answer people prefer." RLCD optimizes for "give the decision and say accurately how confident you are." That matters when code acts on the output without a human reading it first.

No public parameter count, layers, hidden size, heads, context length, weights, or training tokens. Vercel's listing also shows context as not specified. Do not invent those numbers.

Why type safety actually matters

With JSON mode the model still generates tokens that happen to look like {"decision": "refund"}. It can still invent "refound".

With Jev the outputs are defined by the question. A Choice over refund / replacement / human_review cannot return a fourth string. TypeSafe says schema matching is guaranteed, no traditional type errors. It can still pick the wrong allowed option (model error), but your code never crashes on JSON.parse.

Performance, pricing, and honest caveats

TypeSafe reports 70 to 500 ms end-to-end for Jev, vs roughly 3 to 329 seconds for frontier LLMs in their comparison, with workflow headlines up to 193.6× faster and 444.6× cheaper. Read those as vendor-reported numbers for System-One-shaped workloads, not universal "Jev beats everything" claims.

Pricing: $0.042 per million input tokens (~$42/B), output free because there is no generated text. Vercel AI Gateway lists ~$0.04/M. No output-token budget to manage, very different from reasoning models where generation dominates cost.

Current spec sheet without inventing anything:

• Model: Jev, by TypeSafe AI, System One Model, released Sept 15 2026, early access
• Input: app state + typed questions. Output: typed decisions with probabilities/confidence
• Types: Choice, Score, Boolean/Noul. Sampling: parallel. Training: RLCD
• Architecture / params / weights / context: not publicly disclosed
• Pricing: $0.042/M in, free out. Latency reported 70 to 500 ms
• For: classification, routing, scoring, verification, guardrails, agent decisions. No traditional text generation

7. What Did I Actually Implement? (Postmark as Example)

Postmark is intentionally not the star, it is one example of the pattern. One page, one route (app/api/inspect/route.ts holds the only TYPESAFE_API_KEY), zero chat:

const payload = {
  state: draft,
  model: "jev-latest",
  questions: {
    tone: { type: "choice", instructions, criteria: { "hot take": "..." } },
    virality: { type: "score", instructions, criteria: ["Ignored: ..."] },
    cringe_risk: { type: "noul", instructions, criteria: { true: "...", false: "..." } },
  },
};
await fetch("https://api.typesafe.ai/v1/systemone", {
  method: "POST",
  headers: { Authorization: `Bearer ${apiKey}`, "Content-Type": "application/json" },
  body: JSON.stringify(payload),
});

Verdict is two lines, no second model call:

const verdict =
  cringe_risk.noul >= 0.6 ? "Hold up"
  : virality.score >= 2.2 ? "You ate"
  : "Send it";

Bars render straight off probabilities. Full build details live in the Postmark case study, the point here is how little code Jev needs around it.

If you want the production version of the same idea, look at LLM-Orc-Station: classifier → router (cost/latency/fallback) → key manager → dispatcher → metrics → orchestrator with retries. Jev would slot into that classifier step as a calibrated replacement for heuristics-plus-JSON.

8. What Are the Tradeoffs?

• Jev gives decisions, not explanations. Want why something is cringe? You still need an LLM.
• Fixed question sets are a feature (type safety) and a limit (six tones, three tiers, reality is messier).
• Needs network + key. Heuristics in LLM-Orc-Station still win on zero-cost, zero-latency, offline.

The boundary is clean: Jev does not replace GPT/Claude/Gemini for writing, code, chat, creativity, or long reasoning. It replaces the part where you made those models output JSON and prayed.

LLMs → generate intelligence as language
Jev → exposes intelligence as decisions

9. When Would I Use This?

My reference case is still the school router: every question needs complexity → model in milliseconds, before the answer even starts. Jev-shaped to the core.

Reach for Jev for:

• Real-time routing, recommendation decisions, high-volume classification
• Fraud / risk scoring, customer-support automation, workflow automation
• Agent control loops: retry? call tool? ask user? stop? which sub-agent?
• Tool selection, agent routing, retry/stop, verification, guardrails (Vercel lists the same set)
• Verifying another LLM as a fast layer:

User → LLM → generated response → Jev → Accept / Reject / Human review

Check: supported by context? safe? right format? sendable? policy violation? That check matters more than impressive text in production.

Do not reach for it for articles, code, conversation, or open-ended answers. The future is probably both: frontier LLM for deep reasoning, Jev for fast decisions, plain code for logic, tools for actions. Agents stop being chatbots that occasionally call functions and become software that occasionally reasons.

Conclusion

For years the interface was Prompt → Text. TypeSafe proposes State + Question → Decision + Probability. Small API change, big architecture change, software consumes booleans, scores, categories, IDs, actions, probabilities, not paragraphs. Jev starts from those primitives.

The numbers grab attention, but the idea matters more. One giant LLM doing everything vs specialized primitives doing their jobs. That is what I felt building Postmark after LLM-Orc-Station: the frontend collapsed to sorting and widths, tuning collapsed to one number, and the key lived behind one tiny route.

One more thing while I was writing this. An open source model called Laya just dropped right now, as I was finishing this blog. I have not tested it yet, but if you are following this decision model space, it looks worth a look alongside Jev. I will probably try it next.