Vendor risk for a decision model is mostly version risk. The API is simple, the output is small, and the price is low. What changes under you is the model behind the model alias, the contract behind the endpoint, and the deprecation clock behind the version you pinned.
A team that treats the model as a utility will be surprised by all three. A team that treats it as a dependency with a version, a contract, and an exit can absorb the changes.
Aliases are a moving target
The models page shows that jev-latest and jev-preview both pointed at jev-1.13.0 at capture time. The 1.14 release post says 1.14.0 shipped under jev-preview, with the largest expected gain in multilingual support, and that jev-latest was scheduled to move to 1.14.0 within a week.
That is normal product behavior, and it is exactly why production code should not call jev-latest. Pin the concrete version. The confidence docs make the dependency explicit: your threshold was tuned on a distribution, and a new model can shift that distribution without changing a single line of your code.
The release post also describes deprecation intent: 60 days' warning for 1.13.0 and 30 days for 1.14.0, with a formal policy still to come. Intent is not a contract. Put the notice period in your vendor review and track the actual announcement, not the blog post.
Pin more than the model
A decision with repeatability depends on the model version, the question wording, the criteria, the threshold, the SDK version, and the gateway configuration. Pinning only the model gives you a false sense of stability.
The API reference is stable in shape (one state, typed questions, answers keyed by your ids), but the semantics of a question live in its wording and criteria. A criteria edit can move answers more than a minor model release. Version the question registry with the same seriousness as the model.
The SDK is part of the surface too. The Python SDK defaults to two retries, 0.5 s initial backoff doubling to 5 s, jitter 0.25, and a 30-second total retry budget. A SDK upgrade that changes those defaults changes your tail latency and your error rate, even if the model is identical.
Gateways add another version field. If you route through OpenRouter or a self-hosted gateway, record the resolved provider and model, not just the alias you sent. The OpenRouter listing is useful for price and access, but it is another party in the path.
Read the contract, not the landing page
The Master Customer Agreement is the contract for services named in an order. It was last updated 23 September 2026. It grants a limited, non-exclusive, non-transferable, non-sublicensable license to access and use the services and to integrate the API into customer applications.
The restrictions matter for product design. The license bars selling, leasing, sublicensing, or offering the services as a standalone service, and bars using output to train or distill a similar or competing model. If your product wraps Jev as a feature, read those clauses before you describe it as a platform.
The Terms of Use are site terms, not the API contract. They were last updated 19 September 2026, cover typesafe.ai and its subdomains, and say a separate product agreement controls use of the products. They also bar scraping the site with automated tools. Do not cite the website terms as the service contract.
The enterprise page is where the procurement conversation starts: SOC 2 Type II, zero data retention, a no-training commitment, and higher rate limits, with a sales contact for throughput, data requirements, and VPC questions. It is a marketing page, and the 88% and 98.7% cost case studies are headlines without methodology there. Verify the report and the retention setup directly.
SLA math
The public MCA captured here does not publish an availability number. It says the order names the services a customer bought. If you need an availability commitment, it has to be negotiated into the order; do not infer one from the marketing page or the status page.
What you can measure without an SLA is your own dependency on the endpoint. The models page states 100,000 tokens per second and 80 requests per second, with rate limits that adjust dynamically and can change without notice. The API reference lists 429 and 529 as retryable and 401 and 422 as caller errors.
Build the service-level objective from your side: the percentage of decisions completed within the latency budget, the percentage that required a retry, and the percentage that fell back to a default. The jev-oncall run reports p50 418 ms and p95 1,477 ms for alert triage, which is a useful shape for an interactive queue. Your numbers will differ, and they are the ones that matter.
Run a deprecation drill
A deprecation is a forced model change. The safe way to absorb it is to rehearse it before the notice arrives.
Run the current version and the candidate version in parallel on a representative sample. Compare the answers, the confidence distribution, and the branch decisions, not just the accuracy. The workflow evals are a starting harness: four workflows, 67.8% average accuracy at $0.0004 per case, with reference labels from GPT-6 Astra and Claude Fable 5.1. The caveat is that the eval is vendor-run and the harness is assumed correct, so use it as a prior and add your own cases.
The shadow and canary article describes the deployment pattern: shadow the new version, pick the threshold from the disagreement, canary a slice, and keep rollback to one flag. A deprecation drill is the same pattern with a deadline.
Pay attention to the categories where the model is weakest. The independent audit found invoice processing at 61.8% for Jev against 79.1% for a frontier comparator, even though the four-workflow average was 67.8%. A version change that helps the average can still hurt the category you care about.
Keep an exit
Portability is the best SLA. If the request shape is one state plus typed questions, moving to another provider is mostly a matter of changing the base URL, the model id, and the auth. The Decision Models API is Jev-compatible and offers an EU tier with a DPA at signup and contracted EU operators, at $0.019 to $0.021 per million input tokens for s1-fast. Its caveats are explicit: it is not affiliated with TypeSafe, the benchmark placement is the operator's own, and the Peer-to-Peer tier can use providers that may store content.
OpenRouter is another exit path, with Jev at $0.042 per million input tokens and output free. The OpenRouter explainer is also a reminder that the probabilities are the product; a replacement must return the same typed shape, not just a label.
Self-hosting is the last resort and the strongest residency answer. It is not free: you own the hardware, the quantization, the upgrades, and the evaluation. The hosted versus self-hosted TCO article does the arithmetic.
A vendor review checklist
For each dependency, write down the pinned model version, the alias policy, the deprecation notice period, the contract term, the data region, the retention setting, the rate limits, the error contract, the price per million input tokens, and the exit path. Then test two things: a model upgrade on your own sample, and a failover to the exit path with the same question set.
The reproducibility article is the checklist for the first. The second is a fire drill. A vendor relationship is manageable when the version is pinned, the contract is read, the SLA is either negotiated or measured, and the exit has been rehearsed. Everything else is hope.
