ai newsDo., 15. Okt.
EilmeldungAlibaba Qwen N1 AI glasses go on sale in China

OpenAI Decisions API: Schluss mit dem Parsen von LLM-Antworten per Regex

Viele Agenten geben modellgenerierten Text per Regex in boolesche Werte zurück. OpenAIs Decisions API, jetzt im öffentlichen Beta, liefert dafür eine saubere Primitive, die diesen umständlichen Workflow überflüssig machen soll.

dev.toDienstag 07:09 · 13.10.DE3 Min. Lesezeit
Bild: dev.to

Every agent you've ever shipped has a embarrassing secret in its control flow: somewhere, a regex is parsing a model's English back into a boolean. This week, the industry finally gave us the primitive that kills that hack.

On October 6, OpenAI's Decisions API went public beta — POST /v1/decisions, typed answers only: a probability, a choice, or a score. On October 9, Microsoft shipped Decision-1 in Foundry: a Qwen3.5-9B post-trained for single-pass decision scoring at $0.042 per million input tokens, output free. Same week, SGLang added a nightly /v1/decisions endpoint and vLLM merged /v1/systemone. The interface consensus is here: stop generating the decision, score it.

Be honest about your current stack. It looks like this:

response = llm. chat ( " Classify this lead as HOT, WARM, or JUNK. Reply with JSON only. " ) label = json. loads ( response. text )[ " label " ] # pray Enter fullscreen mode Exit fullscreen mode You pay output tokens for reasoning you discard. You wait on a full generation for a yes/no. And every few hundred calls, the model gets creative and your parser eats an exception at 2 AM.

JSON mode and structured outputs reduced the breakage, but the architecture was still wrong: you were using a text generator as a classifier because no served classifier existed. Now one does.

The replacement pattern has three parts:

1. Typed decision call. Fixed options in, calibrated probabilities out. OpenAI's three shapes cover nearly all control flow: predicate (probability a condition holds — your if statement), choice (one option plus probabilities — your switch), score (position on ordered levels — your priority queue).

2. Threshold policy, not vibes. This is the part most tutorials skip. The number is useless without the policy around it:

score = decide ( " Is this support ticket urgent? ", ticket. text ) # → {"urgent": 0.91, "normal": 0.09} if score [ " urgent " ] >= 0.85: page_oncall ( ticket ) elif score [ " urgent " ] >= 0.60: human_review_queue ( ticket, score ) # score travels with the ticket else: auto_resolve ( ticket ) Enter fullscreen mode Exit fullscreen mode 3. Audit log. Every decision lands in a log with its input hash, scores, threshold outcome, and timestamp. When a decision looks wrong, you don't argue with a paragraph — you look at the number, the threshold, and the input. This is also what makes the pattern compliance-friendly: OpenAI ships the beta with Zero Data Retention support and HIPAA eligibility, because a scored, logged decision is auditable in a way prose never was.

Price comparison that's actually interesting: TypeSafe's Jev — the decision model one independent writeup called the product OpenAI was directly answering — lists the same $0.042/1M input. The category now has a price anchor, and it's cheap.

I've run a decision stage in my own agent stack for a long time — THINK, ACT, then DECIDE: a small scoring model verdicts every consequential step, logged and thresholded. It was always the quiet stage and always the one that kept the system honest. This month the industry formalized it as a served primitive, with two vendors and both open stacks converging on the same interface in the same week.

When that happens, the interface is the story, not the leaderboard. Build the verdict layer. Your 2 AM self will thank you.

By Shivam Kumar — VisionQuantech. I run a decision engine (Jev) in production nightly for lead scoring, reply classification, and build prioritization. This week's launches formalized the stack I've been running.

Originaltitel: Stop Parsing LLM Essays: Build a Verdict LayerQuelle: dev.to (dev.to). Original öffnen