Replacing OpenAI/Anthropic apps with Jev

When TypeSafe AI launched Jev on 20 September 2026, the headline was the price: $0.042 per million input tokens, output free, and one evaluation quoted at 444.6× cheaper and 193.6× faster than a small frontier LLM. The instinct is to ask “can this replace OpenAI?”. It is the wrong question. The right one is narrower and far more useful: which of my OpenAI or Anthropic calls are decisions, not prose? Those are the ones you can move — and in most apps they are the majority of the traffic.

If you want the build-side view — the specific patterns worth moving — read the companion, 7 things you can actually build with Jev. This piece is the migration: the rule, the split, the path, and the math.

A System One model returns a typed value from a space you defined in advance — a true/false judgement, a choice from a fixed set, an ordered score — with a calibrated probability. An LLM generates open-ended language. So the migration rule writes itself: anywhere your app uses an LLM to produce an answer you could have enumerated beforehand, that call is a candidate for Jev. Anywhere it produces text a human will read, it stays.

The tell is the prompt. If you find yourself writing “reply with JSON”, “answer only yes or no”, “pick one of these labels”, or “rate this from 1 to 5”, you are already fighting a language model into behaving like a decision model. That fight — JSON parsing, enum guarding, retries on malformed output, no trustworthy confidence — is the tax a System One model removes.

Run this split across your app. Most production systems land with more in the left column than the team expects — the “AI” is generation, but the plumbing around it is decisions.

The safe way to adopt Jev is not a rewrite. It is a behaviour-preserving wrap, measured, then a backend switch. TypeSafe’s open-source system-one-adapter makes this possible: it is a drop-in for the system_one API, but backed by OpenAI or Anthropic — so you can adopt the interface before you adopt the model.

Step 1 — Inventory and tag every model call

List every place your app calls OpenAI or Anthropic. Tag each one prose or decision using the database-column-versus-chat-bubble test above. The decision calls are your migration surface.

Step 2 — Wrap each decision behind system_one, still on your LLM

Replace the raw completion with a system_one call through the adapter, pointed at the same model you already pay for. Nothing about your vendor or your bill changes yet — you have only swapped a hand-rolled JSON prompt for a typed, calibrated interface.

# BEFORE — a yes/no decision dressed up as a chat completion.
import json
from openai import OpenAI

client = OpenAI()

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system",
         "content": 'Is the message spam? Reply JSON: {"spam": true|false}.'},
        {"role": "user", "content": message},
    ],
    response_format={"type": "json_object"},
)
is_spam = json.loads(resp.choices[0].message.content)["spam"]
# You still parse JSON, guard the value, get no calibrated confidence,
# and pay for output tokens — on the hot path, once per request.

# AFTER — the same decision as a typed System One call.
from system_one_adapter import SystemOneAdapterClient, Noul

client = SystemOneAdapterClient(
    structured_outputs=True,
    llm_answer_mode="probabilities",
    normalize_probabilities=True,
)

response = client.system_one(
    state=message,
    questions={"spam": Noul(instructions="The message is spam.")},
    provider="openai",   # switch this to the Jev backend when you have access
    model="gpt-4o-mini",
)
# A typed judgement with a calibrated probability — no JSON, no enum guard.
# For a multi-way route, swap Noul for Choice; for a rating, use Score.

Step 3 — Shadow-run and measure

Run the new path in shadow against the old prompt on real traffic. Compare three things: agreement with your previous output (accuracy), latency, and cost per thousand decisions. This is also where the calibrated confidence earns its keep — you can set a threshold that auto-decides on high confidence and escalates the rest.

Step 4 — Switch the backend to Jev

For the decisions that pass, change one argument — the backend — from your LLM to Jev, and keep the adapter in place as a fallback. Because you migrated the interface first, this last step is a config change, not a code change.

Two things drive the gap. First, architecture: Jev is non-autoregressive, so a decision comes back in a single 70–500ms pass instead of an LLM’s token-by-token 3–329 seconds. Second, pricing: $0.042 per million input tokens against roughly $0.20–$10 per million for LLM input, and — the one that compounds — output tokens are free where an LLM meters every one.

That free-output line is why bulk and hot-path decisions move the needle most. A yes/no check or a route emits only a token or two of output, but on an LLM you still pay for them, per request, forever. Multiply by a moderation gate on every message or a router on every request and the decision layer can quietly become a large share of the bill — the exact dynamic we traced in the per-token economics of AI features.

Do not force a decision model onto a language task. If the output is a paragraph, a conversation, a summary or code, keep it on OpenAI or Anthropic — a typed value cannot express it, and trying will make the product worse. Be cautious, too, with decisions whose option space is genuinely open-ended or changes per request; System One models are strongest when the answer space is defined up front.

And keep an LLM fallback for the long tail. The pattern that ages well is a fast System One decision on the hot path, escalating low-confidence or out-of-distribution cases to a heavier model — not an all-or-nothing switch.

Primary sources

• TypeSafe AI — Introducing System One models & Jev
• GitHub — typesafe-ai/system-one-adapter (MIT)
• TypeSafe AI — product site

Not affiliated with or endorsed by TypeSafe AI. Product names are used for identification only.