Speaking the Model's Native Language: OpenAI's Decisions API, TypeSafe's Jev, and the Rise of Decision Models

Fundamentally, every transformer works on probability. Even chat-based LLMs like ChatGPT and Claude are probability engines at their core, looking at your context and calculating the likelihood of what word should come next based on their training. Because humans communicate in sentences, we forced these models to learn our language and speak to us in prose. That made total sense when a human was sitting on the other side of a chat box, but it made much less sense when we started wiring AI into software. Whenever an application needed AI to make a simple decision, like routing a support ticket, flagging a bad frame of video, or picking which tool to call, we still made the model speak English. Under the hood, the model calculated its probabilities, translated them into words one token at a time ({ "category": "billing" }), and sent that text over the network so our code could parse it back into a decision.

Over the past few weeks, two releases removed that translation step entirely: TypeSafe AI's Jev (built by OpenAI RLHF co-inventor Diogo Almeida) and OpenAI's Decisions API (powered by gpt-6-luna). Instead of generating text, decision models speak their own language. The catch, and the secret to how they work, is that you have to pass all the possible output choices upfront as part of your input. Because the allowed answers are already in the input, the model doesn't actually produce a new output. It simply evaluates the options you handed it and selects the winner based on probability and confidence. With no words to generate, there are zero output tokens, making decisions roughly 10x faster (~100 to 150ms) and dramatically cheaper.

The Pathfinder protocol: how pointing beats talking

The best way to understand how a model that cannot speak can still be extraordinarily powerful is the Pathfinder scene from The Martian. Stranded on Mars with no working radio, Mark Watney digs up the old Pathfinder probe. He cannot type messages to NASA, and NASA cannot talk to him; all NASA can do is rotate the lander's camera. Notice what Watney has to do first: NASA's camera cannot invent an answer out of thin air. Watney has to physically write the possible outputs on signs and stick them in the dirt before NASA can answer. So he plants his question, ARE YOU RECEIVING ME?, flanked by two output choices: YES and NO. The camera rotates and points at YES.

At first, it is just binary. Then Watney realizes that if he places a full circle of cards around the camera, expanding the alphabet into hexadecimal (0 to 9 and A to F), that simple rotating camera can point fast enough to spell out complex instructions. Eventually, that constrained pointing system gives him enough bandwidth to hack the Ares 3 rover, establish a real two-way console with NASA, and save his life. That is the exact contract of OpenAI's Decisions API and TypeSafe's Jev. You supply the evidence and the cards in your input request, and the model points at the right card in one pass:

1. Binary (predicate in OpenAI / nu in Jev): Watney's YES and NO stakes. Does this input meet a condition? Returns a probability from 0% to 100%.
2. Multiple Choice (choice): A circle of up to 255 predefined options you pass in the input. Which category, tool, or route fits best? Returns the winning choice, the probability of every option, and a calibrated confidence score.
3. Grading Scale (score): An ordered rubric of levels (like 0 to 3) passed in the input, where the model weighs the probabilities across levels to return a precise score (for example, 1.1).

The economics: why output tokens cost $0

In traditional LLMs, output tokens are the bottleneck. They are generated one by one (which causes latency) and typically cost 5x more than input tokens. With a decision model, because you already paid to send the possible choices inside your input, the model only returns probability numbers for those existing choices, making output tokens completely free.

Why a decision model cannot exist on its own

Even after Watney got the Pathfinder camera pointing at cards, he couldn't rely on it alone. Pointing at predefined cards is fast and life-saving, but you cannot use a pointing camera to write software patches from scratch or have an open-ended conversation. Watney needed Pathfinder so he could unlock the rover. Decision models have the exact same limitation and the exact same product role. A decision model cannot write an email, generate code, or chat with a customer. It cannot exist on its own. Instead, from a product perspective, it transforms two foundational layers of software: classification and agentic workflows.

1. Classification as a whole gets faster, cheaper, and hallucination-free

Classification used to mean choosing between dumb, brittle keyword rules or slow, expensive LLM calls. When you drop the latency to 100ms and the cost to fractions of a cent, classification stops being a batch job and becomes a live product feature:

• Screening at scale: Talent marketplace Jack & Jill replaced Gemini 3.1 Flash Lite with Jev to screen 6,000 candidates per open role daily, cutting token costs by 88%, halving batch time, and dropping live candidate signup checks from 3.6 seconds to 0.2 seconds.
• Vision + deterministic code: Because OpenAI's Decisions API supports images natively, you can feed it live video frames, product return photos, or food pictures in real time. In one build below, an iPhone calorie tracker uses two quick Decisions API calls (~1s total, $0.00005 per scan) to match a meal photo against 5,000 verified USDA foods and portion sizes, and then uses plain code to multiply the calories so the AI can never hallucinate the math.
• Pre-filtering before heavy models: Instead of paying a massive reasoning model like Claude Opus 5.5 hundreds of dollars to edit raw video, a decision model can classify 40 transcript lines (keep, false start, restart, dead air) in 1.7 seconds for $0.03, escalating only the tricky cuts to the big model.

2. The agentic workflow: identifying the right tool to call

Where decision models may matter most is inside complex agentic workflows. Today, when an AI agent has 40 different tools it could call (database queries, Slack actions, billing APIs, web search), we usually ask a heavyweight reasoning model (GPT-6 Astra or Claude Opus 5.5) to read the entire conversation, read all 40 tool descriptions, and "think out loud" about which tool to pick. The user stares at a loading spinner for three seconds before a single tool is even triggered. With a decision model acting as the front-door reflex, the workflow looks completely different:

In a single 100ms pass that checks multiple questions at once, the decision model reads the context, verifies the request is safe (predicate), points to the exact tool needed (choice), and scores how complex the task is (score):

• If confidence is high (say, 97%): Your code immediately fires the check_order_status or issue_refund tool and hands the result to your conversational LLM to write a friendly reply.
• If confidence is low (60%): Because decision models return calibrated confidence, your code knows the request is ambiguous and escalates the decision to a heavy reasoning model.

Separating deciding from talking

For the last few years, we treated every AI problem like a chat problem because chat was the only interface we had. The shift behind OpenAI's Decisions API and TypeSafe's Jev is a reminder that deciding and communicating are two completely different jobs. We still need conversational and reasoning models, the Ares 3 rover, to write, plan, and talk to humans. But for the thousands of quiet judgments happening underneath the surface of our software every second, we just needed the camera to point.

If you are exploring decision models in your product or agent stack, I would love to hear what you think. Let's connect on LinkedIn.