Early-access risk and vendor lock-in

TypeSafe announced Jev on 15 September 2026 [1]. The waitlist was removed on 20 September, five days later [2]. This page is being written on 22 September. Every figure in this guide, every price, every latency, every documented weakness, is at most a week old, and the model that produced them has one version number. That is the situation a buyer is deciding in, and the right response is a design question rather than a wait.

What is single about Jev today

One model version. TypeSafe's models page lists jev-1.13.0, released on 15 September 2026, with two aliases, jev-latest and jev-preview, that both point to it [3]. There is no older version to fall back to and no newer one to compare against. An alias is designed to move when a new version ships, which is why a production feature should name the version rather than the alias.

One vendor, one hosted API. The endpoint is a single POST to api.typesafe.ai with a bearer key [4]. There is no self-hosted option, no second provider serving the same model, and the architecture has not been disclosed [5], so nobody outside TypeSafe can reproduce it. TypeSafe describes its training method as "Reinforcement Learning for Calibrated Decisions" and says no more [1].

One primary language. The models page says English is the primary training language [3]. A product with a non-English market has no published accuracy figure to plan against.

One price, unproven. TypeSafe lists $0.042 per million input tokens with output free [3], and, as MarkTechPost reports, TypeSafe says it cannot prove that price is unsubsidised [5]. A launch price that is later raised is normal for a new API. Plan as if it will be.

One set of documented weaknesses, and they are specific. The jaggedness page for jev-1.13 says the model "answers the question you wrote, not the one you meant", reads scoping words and negations literally, "does not count reliably", cannot judge numeric closeness, reads dates as text, answers double negatives less reliably, loses accuracy as unrelated content is added to the state, and can be moved by adversarial content in the state [6]. A later version may fix some of these and introduce others. Your labelled set is how you find out which.

Why you can build on it now

A product team waits for a tool to be replaceable, whatever its age. The three third parties that built on Jev in its first week, LangChain [7], Openlayer [8] and Browser-use [9], each built an integration that could be pointed at another decision source: a package, a library, and an agent. That is the pattern to copy. Reveneau moved the grader in its own eval suite to Jev this month, and the suite runs ten times faster than it did with a language model grading it, on our own suite. We made that move because the grader was already swappable: the rubrics live in our criteria, the human labels from the uncertain band are kept, and a check that cannot reach the API fails closed rather than passing. The switch back would cost us a configuration change and a re-run of the labelled set.

The three-part swappable design

The questions and thresholds live in your repository. Every question your product asks, in the exact words, with its allowed answers, and every confidence threshold per action, as plain text files owned by your team and reviewed like code. Nothing about the questions should exist only in a vendor console or only in a partner's head. A language model can be given the same questions as a prompt. A rules engine can be given the same thresholds. A future decision model from another vendor can be asked the same things. If the questions are yours, the vendor holds nothing you cannot take elsewhere.

A labelled test set lives beside them. One hundred to two hundred real cases, each with the answer a person gave and the date they gave it. This is the instrument that measures any replacement, and it is the instrument that measures the next version of the same model. Without it a version change is a guess. With it, a version change is a run of the set and a comparison of agreement rates against a cutoff you wrote down in advance. Measuring a decision model in production says how often to refresh it.

A fallback path exists in code and is exercised. TypeSafe's API documentation lists four error codes: 401 for an invalid key, 422 for a validation failure, 429 for the rate limit, and 529, "TypeSafe is temporarily overloaded", with the instruction to back off and retry [4]. The rate limits are 250,000 tokens per second and 1,200 requests per minute [3]. Your feature will meet every one of these. The specification has to say what happens on each: retry, then route to a language model, then route to rules, then route to a person, or fail closed and tell the user. And the path has to be run on purpose, in a test that cuts the API, because a fallback that has never executed cannot be relied on. Writing a specification for a decision-model feature puts this in the spec.

What the contract should say

Four clauses, whether the counterparty is the vendor, a vendor that embeds the model, or a development partner building with it.

Which model version is pinned, and how a change is handled. The contract names jev-1.13.0, or whatever version the labelled set was last run against, and states that a move to a new version happens on your say, after the labelled set has been re-run, with a stated notice period from the vendor before an old version is withdrawn. If the vendor cannot commit to keeping an old version available, the contract says how long you have and what the fallback is.

What the price is after launch. The current list price, the notice period for a change, and a cap or a right to exit if the change exceeds it. Given that the vendor itself will not say the launch price is unsubsidised, this clause is the one most likely to matter.

What data the vendor keeps and for how long. The state you send is your users' text. The contract states whether it is stored, whether it is used for training, and how long it is retained. We make no legal claim about which regime applies to your data; the financial and healthcare compliance guides say how to find out for your sector.

Who owns the questions, thresholds and labelled set. If a partner builds the feature, the contract says these three artefacts are yours, live in your repository, and are handed over in full at the end of the engagement. What changes in a contract when AI writes the code covers the wider set of clauses for an AI-built product.

Which kinds of lock-in matter

Lock-in through the API is small, because the request shape is a state plus named questions and any language model can be prompted to answer the same questions, more slowly and at a higher price. Lock-in through the questions is small if they are yours. Lock-in through the thresholds is real but measurable: the numbers were tuned to this model's probability distribution, and a replacement will need retuning against the labelled set, which is a week of work with the set and an open-ended job without it.

The lock-in that is real is behavioural. A product that has been built around a decision arriving in a quarter of a second cannot easily go back to one arriving in three. A feature that checks thirteen things per message because each check was nearly free will have to check fewer if the price rises. Those are product decisions to make with the trade-off written down, and when to move back to a language model or to rules is the page for making them.

For an investor reading a portfolio company's plan

The questions are the same ones the model dependency risk page in the AI startup diligence guide asks about any model: is there a labelled set, is the version pinned, has the fallback been run, and who owns the questions. A company that answers all four in a sentence each has a dependency it can manage. A company that answers "we use Jev" has a dependency it has not thought about. Questions to ask a vendor or development partner that uses Jev is the full list, and the pillar guide has the rest of the decision.

A week-old model is a fine thing to build on. A week-old model that cannot be replaced is a risk you have not priced, and you should know which of the two you are building.