I Read All Four Legal Documents Behind Jev, the Fastest AI Model of the Year

Jev launched on 15 September. Three days later I searched for its terms of service. Google gave me the vendor's launch post at position one, a DataCamp explainer at two, and the raw Terms of Use at three.

I clicked position three and read the wrong contract. So did everyone else who clicked it. That document covers typesafe.ai, the marketing website. It has nothing to do with the API you are about to send client data through.

The contract governing the product sits three clicks away, and in four days of launch coverage I could not find one person who had read it. Everyone measured the speed. Nobody opened the paperwork. So I opened it, all four files.

What Is Jev, and What Is a System One Model?

$0.042 per million input tokens. Output tokens free. 70 to 500 milliseconds. Those are the numbers that made everyone sit up when TypeSafe AI came out of stealth on 15 September 2026 with $40M led by DCVC, founded by Diogo Almeida, co-inventor of RLHF and InstructGPT at OpenAI.

Jev is what they call a System One model. It does not generate text. It returns a typed decision in a single parallel pass, with a calibrated confidence value you can branch on in code. Type correctness is guaranteed by construction rather than by retry loops, which is the interesting part for anyone who has written a JSON repair function at 1am. Their own framing: "To ask it questions, you have to define the shape of the answer. Kind of like writing multiple choice questions."

The same page admits Jev is weaker than large reasoning models at maths and chess, and on the headline intelligence claim says "This is the hardest claim to defend, and no one in the field has found a good way to prove it." That is more candour than most launch pages manage, and I want to credit it before I spend two thousand words on the parts that worry me.

I am not a lawyer. I am a developer who reads contracts before client data goes through them, because when something breaks it is my name on the invoice. What follows is my reading of four public documents, not legal advice.

Four Documents, Four Dates, and Google Shows You the Wrong One

The scope problem is the most useful thing in this post, so it goes first.

Document	What it covers	Law and venue	Liability cap	Updated
Terms of Use	The website only	Delaware, JAMS arbitration	$100	14 Sep 2026
Master Customer Agreement	The API and console	Delaware courts, loser pays	greater of 12 months of fees or $50	27 Aug 2026
DPA	Personal data in your Inputs	Irish law, Dublin courts	per the MCA, DPA wins on conflict	24 Apr 2026
Privacy policy	TypeSafe's own processing	not stated	n/a	19 Nov 2025

The Master Customer Agreement is the one that matters, and the DPA overrides it where they disagree. Look at the dates: the privacy policy is nine months older than the MCA, and you can see that drift inside them. It is why the no-training promise reads one way on the privacy page and another in the contract.

I have been caught out by document scope before, from the other side of the table. A client tried to renegotiate after I delivered, and that went my way only because I had read my own paperwork properly.

What You Get, What You Cannot Do, and What Credits Actually Are

Start with the good half, because it is real. Section 2.1 grants a limited non-exclusive licence, 2.2 lets you embed the API in applications for your own end users, which is the clause an agency needs, and 4.2 goes further than it had to: TypeSafe disclaims ownership of Output and assigns you whatever right it might have had.

Then 2.3 lists thirteen things you must not do. No standalone resale, no distilling Output to train a competitor, no reverse engineering. No security or vulnerability testing either, which 2.3(h) bundles in with circumventing access controls, so your pentest is a breach. Section 2.4 says only your employees or contractors may use the web console, so you cannot hand a client a login.

Then the money. Credits are prepaid and, per 8.2, "are not redeemable, refundable, transferable, or legal tender or currency". They expire at the earlier of your term ending or twelve months after purchase, and 10.3(c) says unconsumed amounts are gone at termination regardless of who ended it or why. Section 6 allows immediate suspension for a 2.3 breach or a payment thirty days late, and 15.7 lets TypeSafe rewrite the agreement unilaterally on sixty days of notice. Prepaid expiring credits against terms the other side can change is worth pricing in before you top up, which is the general check in 5 questions to ask before paying for any AI tool.

Clause 2.3(f) and the Invitation to Verify

Two sentences from the same company, published the same week.

The product page: "You're in now, so you can trivially verify our speed claims, but be aware that our service is currently in us-west so where you request from matters."

MCA 2.3(f): you will not "publish benchmarks or performance information about the Services."

No consent carve-out, no exception anywhere in the document. And the chapeau to 2.3 binds "Customer Applications, or any of Customer's directors, officers, employees, agents or contractors", so it reaches the freelancer you subcontract the integration to.

Then the teeth. Publishing a benchmark is material breach under 10.2(a), section 6 allows immediate suspension, and 12.3(b) makes a customer breach of 2.3 an Excluded Claim that escapes the liability cap entirely. Your exposure for posting a latency chart is uncapped. Their exposure for losing your data is capped at the greater of twelve months of fees or $50.

Anthropic's commercial terms contain no benchmark publication ban. Google Cloud permits publication on a reciprocity condition. I could not verify OpenAI because their legal pages block automated fetching, so I am leaving them out rather than guessing.

The fair reading, and the point only survives if I state it plainly: a private test is not publication. The invitation and the ban do not collide until you share what you measured. You are welcome to verify. You are not welcome to tell anyone.

Telemetry Is Four Clauses, Not One

This is what I would flag first if a client forwarded me this contract.

Telemetry is defined in 4.3 as "technical logs, hashes, summary statistics and classifications, metrics, and learnings related to Customer's use of the Services", which TypeSafe "may Process without restriction, including to improve the Services or TypeSafe's other products and services."

Alone, a normal analytics clause. With the other three it is the broadest grant in the document. Clause 4.1(b) gives them the right to process your Customer Data specifically to derive Telemetry, 11 gives them ownership of it, and 10.4 survives it past termination. Derived from your data, owned by them, kept without limit, still theirs after you leave.

Set that against the no-training promise, which is real. The privacy policy is flat: "We will not train or fine tune any artificial intelligence or machine learning models on Input." The MCA is narrower. Clause 4.1 says they will not include Customer Data in a training dataset "(i.e., to modify the model weights of)" any model "without Customer's prior consent". There is a consent carve-out the privacy page does not mention, and a definition pinned to model weights, which does not obviously cover eval sets or retrieval corpora. The word Telemetry does not appear in the privacy policy at all.

The ask is one sentence: define Telemetry in writing as anonymised or aggregated data in the Recital 26 sense. If they agree, the clause stops being a problem. If they hesitate, you have learned something.

The Cap and the Indemnity Both Point the Same Way

Clause 12.2 caps each party at "the greater of (A) the amounts paid or payable during the 12 months prior and (B) $50 USD". Consequential damages are waived both ways, which is standard.

Clause 12.3 lists what escapes the cap: your failure to pay, your breach of 2.3, 2.4 or 5, and either party's indemnity payments. Every carve-out but the last runs in one direction.

Put GDPR Article 82 beside it. A data subject sues you, because you are the controller. You pay. Your recourse against TypeSafe is capped at what you spent on credits, which for a small agency is low four figures. DPA 3.1 applies the same cap to subprocessor failures, so an incident at AWS or Modal lands in the same small box, and with Delaware jurisdiction plus fee shifting, chasing anything modest is negative expected value by design.

The indemnity is worse for a European buyer. Clause 13.1 covers claims that the Services infringe "a third-party's U.S. patent, copyright, trademark, or trade secret". US rights only. Sued in Munich on an EU right, you are alone, and 13.6 makes that the exclusive remedy. Clause 13.5(e) then excludes Output entirely, at a moment when competitors market output indemnities as a selling point.

It runs the other way too. Clause 13.2(d) has you defending TypeSafe against claims "brought by an End User and related to the subject matter of this Agreement". Embed Jev in your client's product, a user of that product sues TypeSafe, you pay for the defence, and 12.3(c) puts that outside the cap so your side has no ceiling.

Cannot Hallucinate Is a Marketing Claim, Not a Contractual One

The product page says type correctness is "Not 99.9999% success, actually 100%". Much of the coverage rounded that into a model that mathematically cannot hallucinate.

The contract, in capitals, says "THE SERVICES MAY PRODUCE INACCURATE OR ERRONEOUS OUTPUT" and "CUSTOMER IS RESPONSIBLE FOR INDEPENDENTLY EVALUATING THE OUTPUT."

Both are true at once, and the gap between them is the point. Type correct is not the same as correct. A guaranteed-valid enum value can still be the wrong enum value, and a calibrated confidence score is a number about the model, not a fact about the world. Clause 9.1 warrants only that the Services "perform materially as described in its Documentation", with a thirty day fix or a refund of unused fees as your exclusive remedy under 9.2.

What is missing is louder. There is no acceptable use policy, no prohibited application list, no high risk use ban, no human oversight requirement. The only restriction list is 2.3, and every item in it protects TypeSafe's IP and infrastructure rather than anyone downstream. Nothing stops you dropping Jev into an AI Act Annex III high risk system, and nothing obliges TypeSafe to give you the provider-side information you would need to do that lawfully.

Five Clauses That Break Differently in Germany

Where the data goes. The product page says us-west. The privacy policy says the United States and nothing more. The subprocessors are four companies, all American. And TypeSafe is not certified under the EU-US Data Privacy Framework. I checked rather than assumed: the search box on dataprivacyframework.gov is broken, so I paged all 232 active participants under the letter T. The closest entry is Tynker.

Standard Contractual Clauses are in place, so transfers are lawful on paper. In practice the Transfer Impact Assessment is yours to write, with CLOUD Act and FISA 702 exposure to address in it. The backdrop is not restful: the General Court upheld DPF adequacy in September 2025, that ruling is on appeal at the CJEU, and Max Schrems wrote to the Commission on 30 June 2026 arguing the US Supreme Court's decision in Trump v. Slaughter undermines the framework's independent oversight requirement.

The cap is the clause I would negotiate first. Telemetry is the one I would get in writing.

Deletion, where I want to be accurate rather than dramatic. MCA 10.3 says TypeSafe "will be under no obligation to store or retain Customer Data and may delete Customer Data at any time in its sole discretion." The DPA body says nothing about deletion or return at all. The duty arrives only through SCC Clause 8.5, incorporated by reference in 6.2, and because DPA 1.3 makes the DPA control on conflict, you probably do have a deletion right. You just reach it by chasing two documents into an annex, and what you never get is a deletion certificate or an export window. For a German Loeschkonzept and your Article 30 VVT, an auditor wants a date and a written confirmation. Neither is owed.

No SLA. Support is commercially reasonable efforts by email. That is the whole commitment.

The Annexes Are Thin, and the Subprocessor List Has Two Doors

Here is the complete technical and organisational measures annex, Schedule I section 11, quoted in full:

Typesafe will implement security safeguards designed to protect the security, confidentiality and integrity of Personal Data as described on Typesafe's Trust Center at https://trust.typesafe.ai/.

That is Annex II. A URL. DPA 5.1 lets TypeSafe modify those measures unilaterally, and the SOC 2 report behind that link sits behind a "Request access" button. The rest of Schedule I is similarly light: data subjects are "Customer and Customer's users", which does not describe the people inside your client's records. Section 10 names the Supervisory Authority of Ireland for EEA data subjects, which is the SCC Annex I.C field rather than a choice of your regulator.

The subprocessors, verified from the page: AWS stores and processes live request data, Modal processes prompts without storing them and is the one running inference, and Slack and Google Workspace handle support. Four companies, all US, no EU entity. DPA 3.2 gives fifteen days to object on "reasonable privacy or security grounds", after which both sides "work together in good faith". No termination right, which is where a German DPA normally lands, and no change notification on the page, so the clock runs against something you have to remember to check.

Two doors lead around the list. MCA section 7 says enabling a Third-Party Platform authorises TypeSafe to exchange your Customer Data with it, and a Third-Party Platform is not a subprocessor, so it never appears on the page and the objection window never applies. Clause 15.1 lets TypeSafe assign the agreement in an acquisition without your consent, while the privacy policy permits transferring personal data to "potential transactional partners". Your Article 28 processor can change owner, with your data, and you have no say.

The DPA body itself is competent and it would be unfair not to say so. Instructions-only processing, no selling or sharing, no combining with third-party data, seventy-two hour breach notice, an annual audit right. It runs out at the annexes, not in the body.

Six Things I Would Ask For, and What I Would Actually Do

In priority order, if you are sending the redlines:

1. Carve DPA breach and data protection claims out of the 12.2 cap, and extend 13.1 beyond US intellectual property rights.
2. Get Telemetry defined as anonymised or aggregated, and the 4.1 consent carve-out deleted.
3. Turn a subprocessor objection into a termination right with a pro-rata refund.
4. Put deletion, certification and a thirty day export window into the DPA body.
5. Ask for an EU hosting region, or failing that their TIA documentation and the SOC 2 without the gate.
6. Refund of unused credits where TypeSafe terminates or breaches.

A company nine days past launch on a $40M seed will refuse most of that. Which ones they refuse tells you more than which ones they grant. The version of this conversation you can have with any vendor before getting this deep is in the 5 questions to ask an EU-compliant AI vendor before you sign.

So would I use it? I have not run Jev in production and I am not going to pretend otherwise for a tidier ending. The paperwork is not hostile. It is a young American company's standard template that has not met a German procurement process yet, and most of what bothers me is what gets fixed in a first enterprise negotiation.

Where Jev looks most useful to me is work that never touches personal data. Classification and routing over synthetic or already anonymised state, where the transfer question evaporates and you are left with a fast, cheap, type-safe decision engine. For anything touching a client's customer records, the local versus cloud break-even looks different than it does on price alone.

One thing stuck with me. The same company wrote "no one in the field has found a good way to prove it" about its own headline claim, and wrote a clause forbidding you from publishing what you measure. Both are in force, and reading the TypeSafe AI Jev terms of service is how you find out which one you are agreeing to.

I cannot promise you a compliant answer for your case, and anyone promising that from a blog post is selling something. What I can do is read the contract with you before your client's DPO asks. Let's talk if that is useful.