Jev now has company. Which decision model belongs in your app?

Sources checked on 8 October 2026.

The interesting part of Jev was the job it refused to do. It did not need to write a paragraph before your application could decide where to send a piece of work. That was the point of the earlier Fkra article. [1] Once the output is a choice your code can use, asking a general-purpose model to narrate the choice starts to look expensive.

That idea now has several implementations. Strands released Decider 2B on 1 October. OpenAI offers a Decisions API in public beta. [3][4] The question for a builder has become more specific: which one fits this decision, in this application, with this failure cost? A ranking of model names will not answer it.

What you are actually choosing

Strands also releases weights, training data and scripts. That gives a team something substantial to inspect and adapt, while adding a service it has to operate. [4] A local process is useful when local control matters. It is less useful if nobody is going to own its deployment when the prototype becomes a dependency.

The table compares how each option runs. It does not rank their quality. Having the right output type only means the answer fits the slot. A perfectly valid category can still be the wrong category.

Give all three the same small job

Take an illustrative product-feedback inbox. A message says that offline notes disappeared after an update. The application needs one of four routes: bug report, feature request, account question or general review. It does not need a sympathetic opening, a summary of the message and a closing offer to help. Those might belong in a later response to the person.

Write the categories before picking the model. Does a request for a missing feature count as a bug? What happens when a message contains two problems? Does general review mean insufficient information, an unsupported language, or anything outside the other categories? A comparison becomes hard to interpret when the intended answer changes halfway through it.

// Application contract, not vendor SDK syntax
input:   "Offline notes disappeared after the update."
options: [bug_report, feature_request, account_question, other]
output:  one supplied option + uncertainty information
action:  apply the application's routing rules

Put a small adapter around each provider so the rest of the application sees the same contract. Preserve the original response for inspection. Map each provider's uncertainty fields deliberately: a field called confidence does not mean the same thing in every service.

A price comparison you can reproduce

At the checked rates, Jev lists $42 per billion input tokens and OpenAI Decisions lists $0.10 per million. [3][5] Now assume 100,000 decisions, each consuming 2,000 billable input tokens: 200 million input tokens in total. The input bill is $8.40 for Jev and $20.00 for OpenAI Decisions. That is my arithmetic from the list prices; nothing was run.

Equal billable volume is an assumption. Tokenisation, question overhead and input preparation can change the volume each service actually bills. The calculation excludes retries, fallback calls, infrastructure, regional premiums and other applicable multipliers. It says nothing about whether the two systems make equally useful decisions.

Strands has no comparable hosted tariff in this comparison. Pricing it at zero would hide the machine, serving capacity and operational work. Reusing a machine you already have can make sense, but you still need to know what happens when traffic exceeds that machine's capacity.

For this workload, the listed input-price difference is $11.60. Before spending a week pursuing it, look at the cost of reviewing a wrong route and the share of messages that fall back to a larger model. A cheap first call can be a small part of an expensive workflow.

The ratio stays the same as volume grows, so the gap grows with it: about $116 at a million decisions and $1,160 at ten million, by the same arithmetic.

Compare decisions that survive contact with your data

Use the same held-out messages for every candidate. Include the awkward cases: two requests in one message, a negation that changes the meaning, an unfamiliar product name and incomplete context. If customers write Arabic, include the Arabic they actually write, including dialect and mixed Arabic-English sentences. Translating an English test set is a useful check, but it is no substitute for that traffic.

Then choose thresholds on a separate validation set. On the held-out set, report how much traffic each system can route automatically at an error rate you are willing to accept. Also report errors by category. Sending a feature request to the bug queue and overlooking a serious bug may have very different consequences. An overall accuracy number conceals that difference.

Check calibration too. If a group of decisions carries probabilities near 0.8, do outcomes in that group match the predicted event roughly 80% of the time? That relationship is something to measure on the deployment's data. It does not become true because a response contains a decimal.

Measure end-to-end latency under the concurrency you expect, including timeouts and the review path. Strands' published local latency figure uses specified hardware and task sizes; its displayed latency plot is for v18, while the release described is v19. [4] It cannot serve as a matched race against two remote APIs. A p95 from your own workflow would be much more useful.

Then put every candidate on the same axes. The radar below is a template: the two candidates are hypothetical and the scores are invented, to show the shape a trade-off takes. The candidate that wins on input cost can lose on the axes that decide what the workflow costs.

The shortlist depends on what you need to own

For an existing Jev integration, I would first ask what problem a migration solves. For an application that needs image-based decisions, I would put OpenAI's documented input support on the shortlist. For a team that needs to run and inspect the model locally, I would start by evaluating Strands. Each of those earns a candidate a place in the test. None of them replaces the test.

There is also a fourth option: an ordinary rule. If the decision is whether an account has an active subscription, read the account record. A probabilistic classifier has no useful work to do there. Save these models for the narrow judgements that need interpretation, keep the application's policy explicit, and give uncertainty somewhere sensible to go.

Sources

• [1] Fkra: Jev answers in half a second and cannot write a sentence. The earlier Fkra article this one follows.

• [2] TypeSafe: Introduction. Jev's question types and response structure.

• [3] OpenAI: Decisions API guide. Public beta, model, inputs, output types and standard input pricing; checked 8 October 2026.

• [4] Strands: Introducing Strands Decider 2B. 1 October 2026; local deployment, released assets and evaluation conditions.

• [5] TypeSafe: Jev pricing. $42 per billion input tokens, equivalent to $0.042 per million; checked 8 October 2026.