TypeSafe AI's Jev and Perplexity's Decisions API both evaluate supplied state using typed questions and can accept images. Jev's image support is experimental; Perplexity also publishes decision-model weights. Compare the input contract and deployment requirements, then test their predictions on examples from your application before switching.
The choice starts with the evidence your application needs and where you intend to run evaluation. Similar request fields can reduce integration work, but they don't establish that two models will make the same decisions.
Copy link to headingHow do their interfaces compare?
Both APIs accept caller-defined criteria for decision questions. This comparison uses their shared Choice, Score, and Noul types.
These are the providers' direct interfaces. Jev also has an AI Gateway decision integration, which uses a different endpoint and model identifier. Keep that distinction explicit when adapting code from an existing Gateway application.
Copy link to headingHow should you compare image workflows?
Both Jev and Perplexity can receive the screenshot itself. For a support ticket that says "This keeps happening," the visible error message and the screen around it may supply the information needed to select a queue.
Jev's image input is experimental in versions 1.13 and 1.14 and requires TypeSafe's image opt-in when called directly. Jev 1.14 on AI Gateway supports image input through AI SDK using the pinned version. Perplexity has its own image request format, so the shared text request below cannot be reused unchanged for images.
Give both workflows the same screenshot and message. Comparing an image on one side with only the customer's vague text on the other measures access to evidence as well as model behavior. If either workflow extracts text first, include that step when assessing the final classification.
Copy link to headingWhat changes in a text-routing request?
The following example sends the same invented ticket and routing question to both providers. It prints their answers without assuming which queue either model selects. Use Node.js 22 or later, set both API keys in your server environment, and save the file as compare-decisions.mjs.
const providers = [ { name: "Jev", endpoint: "https://api.typesafe.ai/v1/systemone", model: "jev-latest", apiKey: process.env.TYPESAFE_API_KEY, }, { name: "Perplexity", endpoint: "https://api.perplexity.ai/v1/decisions", model: "pplx-decider-v1-27b", apiKey: process.env.PERPLEXITY_API_KEY, },];
const task = { state: { subject: "Can't open my invoices", message: "My password reset link has expired. I need to sign in to download an invoice.", }, questions: { queue: { type: "choice", instructions: "Choose the queue that can resolve the immediate blocker.", criteria: { billing: "Incorrect charges or invoice contents, with no sign-in blocker.", account_access: "Sign-in, password reset, or account recovery problems.", review: "The blocker is unclear or falls outside these queues.", }, }, },};
for (const provider of providers) { if (!provider.apiKey) throw new Error(`Set the API key for ${provider.name}.`);}
for (const provider of providers) { const response = await fetch(provider.endpoint, { method: "POST", headers: { Authorization: `Bearer ${provider.apiKey}`, "Content-Type": "application/json", }, body: JSON.stringify({ model: provider.model, ...task }), signal: AbortSignal.timeout(30_000), });
if (!response.ok) { throw new Error(`${provider.name} returned HTTP ${response.status}`); }
const result = await response.json(); console.log(provider.name, result.model, result.answers.queue);}Run node compare-decisions.mjs to inspect the two responses. The question gives account access priority when signing in blocks the customer from reaching an invoice. Without that rule, a billing prediction could reflect an ambiguous task definition rather than a failure to understand the message.
The shared body uses fields defined by both TypeSafe's API and Perplexity's API. That overlap supports this specific example. Before adapting a larger integration, check its question structures and response handling rather than treating the two APIs as universally interchangeable.
The example uses TypeSafe's jev-latest alias, which currently points to Jev 1.13; jev-preview points to 1.14. Select a pinned version for a release-specific comparison and record it with your results.
Copy link to headingCan you reuse the same thresholds?
Reuse the business policy, then measure how each model implements it. “Automatically route only when the error rate is acceptable” can remain the goal. The numeric cutoff needed to reach that goal may differ.
For Choice questions, distinguish the selected option's probability from the separate confidence field. TypeSafe derives confidence from the probability distribution. Even when two APIs expose similarly named fields, matching names don't establish identical behavior on your dataset.
Keep the field used by your routing rule explicit. If the current rule tests probabilities.account_access, switching it to confidence changes the rule as well as the model. You would then need to determine which change caused any difference in routing.
Use a labeled validation set to select thresholds for each provider, and reserve other examples for the final comparison. Report both the errors among accepted routes and the proportion of tickets held for review. Sending nearly everything to a person can produce few automatic errors while providing little automation.
Copy link to headingHow do the deployment options affect your application?
Jev's AI Gateway decision integration lets a Vercel application use the gateway's decision interface. If you already use that path, include the response shape and authentication setup in your migration review. The Jev form router guide provides an existing implementation to build from.
Perplexity provides a hosted Decisions endpoint and downloadable model weights with inference code. The code above calls the hosted service. Running the model yourself adds responsibility for serving it, managing capacity, and maintaining the deployment.
Open weights can matter when operating the model on your own infrastructure is a requirement. They don't tell you whether your existing application can adopt the supplied inference code unchanged. Review the serving interface and infrastructure separately from the question definitions.
Copy link to headingHow should you evaluate a switch?
Start with a set of real cases that your team has labeled, including examples that are difficult to assign. For support routing, include messages that mention billing but are blocked by login, tickets with two unrelated requests, and cases that should go to review.
Use the same category definitions for the initial text comparison. Keep a record of each provider's answer, the expected queue, and the eventual action your policy would take. Review disagreements individually. Sometimes the model chose the wrong category; sometimes the rubric left two plausible routes.
Then test the candidate against a held-out set using its own selected thresholds. Include failure cases at the application boundary, such as a missing answer or an unsuccessful HTTP response. Those cases need a review or retry path, not a default queue that conceals the failed evaluation.
Before replacing an existing router, run the candidate without applying its proposed routes. Compare its suggestions with the workflow's actual outcomes. This lets you inspect differences without sending customer work to new queues during the evaluation.
Copy link to headingWhat doesn't this comparison establish?
Interface compatibility doesn't establish equal predictions, and a successful request doesn't establish accuracy. The examples above demonstrate how to submit a comparable task. Choosing a provider for production still requires labeled cases that reflect your application.
For work that needs a written reply, either decision API would be one part of a larger workflow. Keep the routing decision separate from the model that drafts the response so you can evaluate each task against its own requirements.
Copy link to headingFrequently asked questions
Copy link to headingIs Perplexity's Decisions API a drop-in replacement for Jev?
No. The direct APIs share several request concepts, but changing providers also changes the endpoint, model, and credentials. Check the fields your integration uses and reevaluate the resulting decisions before switching application traffic.
Copy link to headingCan both Jev and Perplexity evaluate screenshots directly?
Yes. Perplexity's Decisions API accepts images, and Jev 1.13 and 1.14 support experimental image inputs through TypeSafe's API. Jev 1.14 is also available for image decisions through AI SDK on Gateway. Each path needs its own image request format; the shared text-routing example does not include images.
Copy link to headingCan I keep my Jev routing threshold when switching models?
Treat the existing cutoff as a candidate to test. Select a threshold using labeled validation examples for the new model, then assess accepted-route errors and review volume on separate examples.
Copy link to headingHow can I compare these APIs from a Vercel application?
Call the providers from server-side code and keep their credentials out of the browser. Jev also has an AI Gateway decision integration; the shared HTTP example in this article uses each provider's direct endpoint.