The One-Line Migration: Which Jev Competitors Accept the Same Requests

Image placeholder

Editorial, product-forward hero illustration on an off-white background. Five rounded rectangular wordmark-style tiles sit in a horizontal row — labeled 'JEV', 'd1', 'DREX', 'CELERIS', 'SOLAR DECIDE' — each a different soft shade (pale slate, pale emerald, pale blue, pale sand, pale slate). Each tile has a short pale-slate cable running down from it into a single shared horizontal socket strip across the lower third of the image — one plug, five tiles. The socket strip is labeled in a small flat sans-serif: 'POST /v1/systemone'. One short tagline sits above the row: 'one wire format, five vendors, one line of code to swap'. Clean, flat, geometric. Palette: off-white background, pale slate borders, one emerald-green accent on the shared socket strip, navy ink for all labels. Linear or Stripe editorial feel. No AI robots, no neural networks, no brains, no faces.

• Aspect ratio: 16:9
• Source size: 1600 × 900 px (sharp on retina at 760 px display width)
• Format: WEBP (preferred), PNG fallback
• Target file size: under 300 KB

Save to /public/images/blog/<slug>/, then set src and alt on this <MediaFigure /> to swap it in. Keep the ratio prop so the browser reserves the right space.

By Dr. Sanju Abraham, Fractional CTO — 180+ projects shipped, 34 funded companies. Published October 11, 2026. Last updated October 16, 2026.

Key takeaways

• At least four decision APIs — Liquid AI’s d1, Nace.AI’s Drex, Celeris-1 Decision, and Upstage’s Solar Decide — accept TypeSafe Jev’s POST /v1/systemone request format. You can point a Jev-shaped client at any of them and the request body goes through unchanged.
• Wire compatibility makes A/B testing vendors almost free. You run the same traffic against two providers, compare latency, cost, and accuracy on identical inputs, and keep the winner. No prompt rewrite, no schema translation, no second SDK.
• I call the architecture that results the swap-ready stack: a three-function provider-abstraction layer (choose, score, verify) with a single environment variable deciding which backend serves the next request.
• The thing wire compatibility does NOT give you is semantic parity. Two models can accept the same body and still disagree on the answer — so the abstraction has to log inputs and outputs on both sides and let you replay.
• Lock-in in this category is self-inflicted. The vendors already chose wire compatibility; the only thing left between your app and vendor freedom is twenty lines of adapter code.

The short answer: TypeSafe AI shipped Jev with a specific HTTP contract — POST /v1/systemone with a state object and a questions array of typed Choice, Score, and Noul shapes. Four decision-API startups adopted that exact contract on their own endpoints, so a Jev client can be redirected to any of them with a one-line base-URL change. That is not a historical accident. It is a deliberate strategic choice called wire compatibility, and it is the single biggest reason you should not pre-commit your product to one decision API vendor in Q4 2026. For the broader landscape, see the full market map.

Your boss walks over on a Tuesday. “The Jev invoice came in. Any chance we try Liquid AI for a week and compare?” Six months ago that is a two-engineer sprint — new SDK, new auth, new prompt format, new test fixtures. Today, in the Jev-compatible world, it is a Dockerfile ENV change and a half-hour of dashboards. This piece is about why.

What does “Jev-compatible” actually mean?

Wire compatibility means the HTTP request body one vendor accepts is byte-for-byte usable against another vendor’s endpoint, with at most a change of base URL and API key. No SDK rewrite. No schema translation. No different serializer. The same JSON goes to a different host and gets back a structurally identical response.

Jev’s contract is small enough to copy. The request is POST https://api.typesafe.ai/v1/systemone with:

• a state field (text, structured object, or document reference) describing what the model is being asked about;
• a questions array, each item carrying a name, a type (choice, score, or noul), and the parameters that type needs (option list, rubric bounds, or statement text);
• an optional model field and routing metadata.

The response mirrors the questions, keyed by name, each with a typed answer and a confidence or probability. If you want the primitive-by-primitive explanation, start with what Jev is and the three questions a decision model answers.

Wire compatibility is a conscious strategic choice. The alternative — invent your own request format and ship a bespoke SDK — buys brand control but costs market access. A startup that adopts the incumbent’s contract bets that integration ease will matter more than brand ownership during the first year of a category. It is the same bet S3-compatible storage vendors made against Amazon in 2008, and the same bet the OpenAI-compatible model gateways made in 2024.

Which decision APIs accept Jev’s request format?

Four vendors have independently verifiable Jev-compatible endpoints as of October 2026, with a fifth name floated in the market I could not confirm. Here is the honest reading, source-checked against vendor-adjacent catalog pages and provider listings. Treat it as a snapshot — pricing and compat level in this category shift weekly.

Vendor	Launch	Compat level	Pricing (input / output per 1M tokens)	Notes
TypeSafe Jev	Sep 15, 2026	Reference implementation	Not independently published; third-party reports ~$0.042 / free	The incumbent. The format others copied.
Liquid AI d1	Sep 22, 2026 (text); Oct 5 (images)	Drop-in — same /v1/systemone path, “TypeSafe SDK-compatible” per vendor catalog	Not published at launch	Hosted at api.liquid.ai/decisions/v1/systemone.
Nace.AI Drex v1.5	Sep 2026, updated Oct 2026	Drop-in — “one wire format, System One” via POST /v1/systemone; TypeSafe SDK calls work unchanged	$0.04 / free on OpenRouter + haimaker	Open weights on Hugging Face under Open RAIL-M.
Celeris-1 Decision	Oct 8, 2026	”System One-compatible API” per vendor catalog — treat as drop-in	$0.04 / free	Accepts text, JSON, and images.
Upstage Solar Decide	Sep 22, 2026	Drop-in — “same /v1/systemone schema as TypeSafe Jev” per vendor catalog	$0.10 (Upstage) / $0.05 (OpenRouter)	512K context. Vendor warns the schema may change before GA.
”Decider 1”	—	Unverified — no vendor named exactly “Decider 1” appears in October 2026 search results; closest matches are AWS Strands Decider 2B and Perplexity’s pplx-decider-v1 family, neither of which explicitly claims Jev wire compatibility	—	Treat as rumor until a vendor page confirms.

A few qualifiers you should carry in your head when reading that table.

• “Compat level” is self-reported. Every “drop-in” claim above comes from the vendor’s own catalog page or model-registry listing. The only test that counts is sending real production traffic and diffing responses — which, happily, wire compatibility makes trivial.
• The grammar is converging, not fixed. Upstage flags that its schema may still shift before general availability. Treat today’s byte-for-byte parity as a 90-day window, not a guarantee.
• Pricing is a moving target. Nace.AI’s Drex v1.5 on OpenRouter and Celeris-1 Decision on BenchLM both list $0.04 per million input tokens at launch; Upstage’s Solar Decide lists $0.10 on first-party and $0.05 on OpenRouter. Liquid AI’s d1 is served from api.liquid.ai/decisions/v1/systemone, aligned to the same path Jev defines. Expect the floor to keep moving. If you want the broader “why is this a commodity already” argument, see the three-week consensus.

A fifth category of entrants — OpenAI’s Decisions API, Microsoft’s Decision-1, Cloudflare’s Clef family — are structurally similar but not wire-compatible with Jev out of the box. They are covered in OpenAI enters the decisions market and the big-player piece above. The adapter pattern below handles both camps.

Why does wire compatibility make A/B testing vendors almost free?

Because the only thing changing between runs is the hostname. When two providers accept the same request body and return the same response shape, you can send identical traffic to both without rewriting a single call site. Everything downstream — logging, assertions, downstream business logic — stays the same.

Here is what an “almost free” vendor A/B test actually looks like in practice.

• Dual-write for a week. You fork each inbound decision request to both vendors (Jev and, say, Liquid d1). You act on Jev’s answer in production; you record d1’s answer silently. No user ever sees the second call.
• Diff the outputs. You run a nightly job that joins the two logs by request id and counts the disagreements. For every disagreement, you snapshot the input so a reviewer can judge who was right.
• Score the vendors. At the end of the week you have three numbers per vendor: median latency, dollar cost, agreement with the reviewer-correct answer. One number per vendor, three vendors wide, is a decision you can make.
• Flip the primary. If d1 wins, you change the DECISIONS_BASE_URL environment variable. No deploy of application code is required. Rollback is the same change in reverse.

The classical equivalent — swapping databases, swapping payment providers — takes a sprint. Decision APIs made it a configuration change. For the first-call walkthrough that produces the logs this test needs, see your first decision model experiment, and for the fairness pitfalls, see reading decision model benchmarks.

What is the swap-ready stack?

The swap-ready stack is a four-layer arrangement that keeps your application vendor-agnostic at the cost of about twenty lines of code. It is my name for the shape I have ended up at in the last three Jev-adjacent engagements. Nothing in it is novel; the combination is the thing worth naming.

• Layer 1 — Call sites. Your product code calls choose, score, or verify. It never names a vendor. It never constructs a request body. It never touches a URL.
• Layer 2 — The adapter. A small module that translates each of those three function calls into the vendor’s native request. For Jev-compatible vendors the adapter is a one-liner — set the base URL and go. For non-compatible vendors (OpenAI Decisions, Microsoft Decision-1, Cloudflare Clef) the adapter maps the three primitives into whatever that vendor’s grammar is.
• Layer 3 — The gateway. A single HTTP client with timeouts, retries, circuit breaking, token budgeting, and a request-and-response log. One place to add observability. One place to apply rate limits. One place to swap in a shadow traffic fork.
• Layer 4 — Configuration. Environment variables pick the vendor, the model id, and the base URL. A rollout can target a percentage of traffic, a user cohort, or a specific endpoint. For the SMB framing on why you build this before you need it, see an AI strategy for SMB owners.

How do I design a provider-abstraction layer so I am never locked in?

You write three functions, one adapter, and one environment variable. That is the whole shape. The code below is the TypeScript version I ship on day one of a decision-API engagement; the Python version is structurally identical.

// decisions/client.ts — one file, three functions, swap-ready.
export type Confidence = { answer: unknown; confidence: number };

export interface DecisionsClient {
  choose(state: unknown, name: string, options: string[]): Promise<Confidence>;
  score(state: unknown, name: string, min: number, max: number): Promise<Confidence>;
  verify(state: unknown, name: string, statement: string): Promise<Confidence>;
}

export function createClient(): DecisionsClient {
  const baseUrl = process.env.DECISIONS_BASE_URL ?? "https://api.typesafe.ai";
  const model   = process.env.DECISIONS_MODEL   ?? "jev-latest";
  const apiKey  = process.env.DECISIONS_API_KEY!;
  const post = async (q: unknown) => {
    const res = await fetch(`${baseUrl}/v1/systemone`, {
      method: "POST",
      headers: { "content-type": "application/json", authorization: `Bearer ${apiKey}` },
      body: JSON.stringify({ model, questions: [q] }),
    });
    const json = await res.json();
    return json.answers[0] as Confidence;
  };
  return {
    choose: (state, name, options)   => post({ name, type: "choice", state, options }),
    score:  (state, name, min, max)  => post({ name, type: "score",  state, min, max }),
    verify: (state, name, statement) => post({ name, type: "noul",   state, statement }),
  };
}

// Swap vendors: set DECISIONS_BASE_URL=https://api.liquid.ai/decisions
// (or Drex / Celeris / Solar Decide). No other code changes.

Three implementation notes earn their keep after the first week in production.

• Keep the interface three functions wide, no more. choose, score, verify map one-to-one onto Jev’s three primitives and onto every current competitor. Resist adding summarize or generate to this interface; those belong to a different client with a different lifecycle.
• Log the raw request and response, not just the answer. The payloads are tiny and the day you want to replay last Tuesday’s traffic through a new vendor you will thank yourself. One row per call keyed by request id, both sides stored, retention 30 days.
• Treat the base URL as the only thing that moves. Prompt-equivalent inputs still produce vendor-specific wording differences you cannot control. If a vendor’s responses need any transformation to be usable by downstream code, that is a signal the vendor is not actually drop-in; audit the adapter before you declare parity.

Image placeholder

Infographic styled as a 'before vs after' two-column vendor-swap comparison. Left column labeled 'BEFORE — vendor-coupled stack' shows a tangle of lines from four services (ticket-router, lead-scorer, moderation, extractor) directly into one Jev tile. Right column labeled 'AFTER — swap-ready stack' shows the same four services routing through a single rounded rectangle labeled 'decisions/client.ts (choose/score/verify)', which then has one labeled arrow 'DECISIONS_BASE_URL' pointing at a stack of four stacked vendor tiles: JEV, d1, DREX, CELERIS. One short caption below the right column reads 'one line of config, four possible backends'. Palette: off-white background, pale slate borders, emerald accent on the single config arrow, navy ink. Clean, flat, geometric. No AI robots.

• Aspect ratio: 16:9
• Source size: 1280 × 720 px (sharp on retina at 760 px display width)
• Format: PNG
• Target file size: under 500 KB

Save to /public/images/blog/<slug>/, then set src and alt on this <MediaFigure /> to swap it in. Keep the ratio prop so the browser reserves the right space.

What should I NOT do when building the swap-ready stack?

Resist four tempting mistakes that quietly erase the benefit. I have seen each of them in the wild in the last six weeks.

• Do not try to normalize the confidence numbers across vendors. They are not comparable at face value. Jev’s 0.9 and Drex’s 0.9 are not required to mean the same empirical accuracy; they just mean “the model’s own rank.” Normalize by calibrating each vendor against your own ground truth, not by scaling the raw numbers. See why 70% sure beats yes for the calibration mechanic.
• Do not fold vendor-specific features into the three-function interface. If a vendor adds a with_explanation flag that returns a one-sentence rationale, resist exposing that at the choose level. Add a separate explain function behind the same adapter, or do not use the feature until all your target vendors have it.
• Do not pin a single model id globally. jev-latest and drex-v1.5 behave differently enough that you want model id per call site, not per process. Make the model id a parameter of each adapter method, defaulted at the environment-variable level only.
• Do not pretend wire compatibility means semantic parity. Two models can accept the same request body and still disagree on the answer. The adapter is for interoperability; the shadow log is what tells you whether the answers are actually the same. For how to compare models fairly on your own data, see reading decision model benchmarks.

Four external primary sources I would keep tabs on in parallel: TypeSafe’s own documentation for canonical schema changes to Jev’s /v1/systemone contract, OpenRouter’s model directory for pricing moves across the Jev-compatible set, Liquid AI for d1 revisions, and Hugging Face’s model listings for Nace.AI’s Drex weight updates under the Open RAIL-M license. When any of them moves, your base URL config might want to move with it.

What this does to the “which Jev-compatible decision API should we pick?” question

It mostly deletes the question for the first year. The right default, as of October 2026, is to pick whichever Jev-compatible decision API minimizes integration friction today, ship the swap-ready stack behind it, and let operational data pick the long-run winner over the next two quarters.

The non-compatible vendors — OpenAI’s Decisions API, Microsoft’s Decision-1, Cloudflare’s Clef family — are not disqualified. They just need the adapter to do a bit more work for them. For the structured vendor-selection conversation, see choosing a decision API in 2026 and the full market map.

If you are a hands-on builder, the practical sequence is short. Build the three-function client this afternoon. Point it at Jev tonight. Dual-write a Jev-compatible competitor — d1, Drex, Celeris, or Solar Decide — by Friday. Review the diff on Monday. Four days to an honest vendor comparison on real traffic.

Frequently asked questions

What does “Jev-compatible” mean?

Jev-compatible means a vendor’s decision API accepts the same HTTP request body as TypeSafe AI’s Jev, posted to the same path (/v1/systemone) with the same state and typed-question structure. A client written for Jev can be redirected to the other vendor with a base-URL change and nothing else. It is a wire-level contract, not a licensing or model-weight relationship.

Which decision APIs accept Jev’s request format?

As of October 2026, four independently verifiable Jev-compatible endpoints exist: Liquid AI’s d1, Nace.AI’s Drex v1.5, Celeris-1 Decision, and Upstage’s Solar Decide. Each vendor publishes a /v1/systemone endpoint and describes the request shape as the same one Jev uses. A fifth name sometimes cited as “Decider 1” could not be independently verified in the October 2026 search record.

Is OpenAI’s Decisions API Jev-compatible?

No. OpenAI’s Decisions API uses its own endpoint (/v1/decisions) and its own primitive names (Predicates, Choices, Scores). The grammar is similar — typed outputs, confidence per answer, parallel questions per call — but the request body is different, so a Jev client cannot be pointed at it without an adapter translation. The adapter pattern in this piece covers both camps. For a deeper read, see OpenAI enters the decisions market.

Why would a startup copy another vendor’s request format?

Because integration ease matters more than brand ownership in the first year of a new API category. Adopting the incumbent’s contract gives a smaller vendor instant access to every client, SDK, and tutorial already written for the incumbent — the same bet S3-compatible storage vendors made against Amazon and that OpenAI-compatible model gateways made in 2024. Brand control is traded for market access.

Does wire compatibility mean the models will return the same answer?

No, and treating it that way is the most common mistake. Wire compatibility is a syntactic property — the request body goes through — not a semantic one. Two different models can accept identical requests and return different answers to the same question, with different confidence scores. Dual-write the traffic and compare on your own data; do not assume vendor parity because the request body matched.

How do I A/B test two decision API vendors on real traffic?

Fork each inbound decision request to both vendors behind the adapter. Act on the primary’s answer in production; record the shadow vendor’s answer silently. Run a nightly diff job on the two logs, snapshot the disagreements, have a reviewer judge the correct answer on a sample, and compute per-vendor latency, cost, and agreement-with-correct. The whole experiment takes a week and no application code changes. See your first decision model experiment for the first-call walkthrough.

Do I need an SDK to call a Jev-compatible endpoint?

No. Every Jev-compatible endpoint accepts a plain JSON POST with a bearer-token Authorization header, so the native fetch or requests library in your stack is enough. Vendor SDKs are a convenience, not a dependency; writing to the raw HTTP contract is the whole point of the swap-ready stack and keeps the adapter under thirty lines.

---

If you are deciding whether to put the swap-ready stack in before shipping your first decision-API feature or after, that call is exactly the kind of thing a Fractional CTO is for. The 20 lines of adapter are cheap; the decision to ship them before the second vendor shows up is the leverage. One hour of the right conversation can save a quarter of engineering time. More pieces in this thread live in the AI Strategy archive, and the picking framework for the next vendor conversation lives in choosing a decision API in 2026.