Jev versus OpenAI’s Decisions API for Salesforce case routing

The short answer

Two decision models now compete for the same job inside a Salesforce org: picking the queue, the priority, or the next step for a case, and returning that choice in a few hundred milliseconds instead of writing a paragraph about it. TypeSafe AI's Jev has been generally available since 21 September 2026. OpenAI announced its Decisions API, built on GPT-6 Luna, at DevDay on 29 September.

Our position for a Salesforce service team, today:

• Pilot Jev now, in shadow mode. It has a public price, public documentation, and an early body of independent tests, good and bad.
• Put the Decisions API on the watch list, not the roadmap. It is in limited preview with no published price and no public API reference. You cannot cost or govern what is not documented.
• Keep Einstein Case Classification where you already have the history. A decision model earns its place where labels change often, history is thin, or the decision sits outside the Salesforce UI.

What each one actually is

Both models take structured state in and return a typed answer from a list you define, rather than generated text. That is the whole point: a case router does not need prose, it needs one of six queue names and a confidence value it can threshold on.

Sources: OrcaRouter's Decisions API review, the Awesome Jev reference, and Hatchworks on Jev pricing.

What the independent evidence says

Three findings matter more than the launch-week view counts.

1. How you ask decides the accuracy

An independent phishing benchmark found Jev scored 62.6% when asked one broad question, against 81.3% for Claude Haiku 4.5. Split into five atomic signals, Jev reached 95.0% against Haiku's 93.2%, at $0.038 per thousand emails (reported by Kanerika). For case routing, that means asking “is this about money?”, “is this a security event?” and “is something broken?” separately, then combining, rather than one six-way question.

2. It trades a little accuracy for a lot of cost

On Banking77, a standard intent-routing benchmark, one evaluation put Jev at 0.78 against GPT-5.6 Terra's 0.85, at roughly one-fiftieth of the cost (same source). For a first-pass router with a human or Einstein behind low-confidence cases, that is often the right trade. For a router with no fallback, it is not.

3. Not every demo is real

Builder.io's CEO publicly asked people to stop posting fake Jev demos on 19 September, and a reply reported a browser-use test failing (CellCog's dated tracker). TypeSafe's own headline gains compare Jev against an average of flagship models, built by its own team. Treat every number, including ours, as a hypothesis until it has run on your cases.

Cost at Salesforce volume

Our arithmetic, on list prices only. Assumptions: one million cases a month, 600 input tokens per case (subject, description, account tier, channel, queue definitions), and 10 output tokens where output is billed.

Two conclusions follow. Against a flagship model, a decision model is a fifty-fold saving. Against OpenAI's own cheap tier, Luna, the list-price gap is about 2.6 times, not a hundred. At this volume the model bill is small either way. The cost that matters is the cost of a misrouted case: the hour a security incident spends in the billing queue. Accuracy on your ambiguous cases decides the business case, not the token price.

Luna prices from OpenAI's model page; Sol from LiteLLM's launch note.

Where it fits in a Salesforce org

The pattern is the same whichever model wins:

• Trigger. A record-triggered Flow or Platform Event fires when a case is created.
• Call. An Apex callout through a Named Credential, or a small middleware service, sends the case state to the decision model. Keep the API key out of the org.
• Decide. The model returns a queue and a confidence value.
• Act on confidence. Above your threshold, write the queue back to the case. Below it, fall back to Einstein Case Classification or a human triage queue.
• Log everything. Store the model's answer, its confidence, and the final human-confirmed queue on the case. That is your accuracy dashboard, and your evidence when someone asks why a case went where it went.

Run it in shadow mode first: the model writes its answer to a custom field and routes nothing. Two weeks of shadow data tells you your real accuracy on your real cases, at no operational risk.

Two governance questions to settle before production. Data retention: zero-retention terms with TypeSafe are negotiated directly, not a default (Appinventiv). And regulated fields: strip anything you would not send to an external API before the callout, whichever vendor you use.

The test kit, and what we have not measured yet

We have published a synthetic, labelled Salesforce case set and the harness to score any decision model against it. No client data is involved.

• salesforce-case-routing-testset.csv: 240 synthetic cases across six queues (billing, technical support, account management, security, data integration, sales), each with account tier and channel. 24 are deliberately ambiguous, sitting on a real boundary such as a billing dispute caused by an integration failure, with the secondary queue recorded.
• decision_routing_harness.py: runs the set through Jev and GPT-6 Luna, and reports accuracy, accuracy on the ambiguous subset, p50 and p95 latency, and estimated cost at list price.

The set is small and template-built: 106 distinct subjects across 240 rows. It is a smoke test for the routing pattern, not a substitute for a shadow run on your own case history.

Not yet measured by us: accuracy, latency and cost for either model on this set; the Decisions API at all, since it has no public reference; behaviour on long case descriptions and email threads; and non-English cases. We will add our results to this page when we have them, with the raw output file.