Jers versus Jev
Jev is TypeSafe AI's System One model, served at api.typesafe.ai. Jers is this API. The request and answer shape is the same on purpose, so code written for one runs against the other with a new base URL and a model name. Everything about Jev below is what TypeSafe's public pages said on 2026-09-22; their performance numbers are their claims.
| Jev (TypeSafe) | Jers | |
|---|---|---|
| Endpoint | POST /v1/systemone, bearer key | the same |
| Questions | choice, score, noul; JSON structure allowed | the same, the same limits (255 options, 2 to 10 levels); above 20 options Jers answers in two rounds |
| Answers | probabilities, confidence, usage in tokens | the same; tokens reported when the engine counted them, characters always; plus warnings, a reading report and a decision_id |
| Memory | none; every request is stateless | a per-subject memory in RAM: subject on the request, remember, rules with a when checked in code, forget with a verified removal, delete |
| Comparison | none | memory.compare returns the answer without memory and what changed, on any decision that asks for it; memory.placebo also answers with a neutral line |
| The model | Jev, their own, trained with RLCD | Jers, built on an open engine, with the checkpoint named in every answer |
| Where it runs | their cloud | Jers's cloud: a hosted API at api.getjers.com, the memories on Jers's server, the engine on a GPU server Jers rents |
| Price | $0.042 per million input tokens, output free | input free; a price per answer and per memory line written |
| Keys and usage | console, keys, usage in tokens | keys from Jers, a ledger line per request, prepaid credit, GET /v1/usage |
| Speed | 70 to 500 ms end to end (their figure) | a three-question request takes 22 to 25 ms of engine time on the development Mac (the hosted service is measured separately), stateless, and 30 to 31 ms with three memory lines; the gateway adds about 2.6 ms (4.3 ms with memory) for keys, metering, the decision record and warnings (medians of 20 requests, three runs, 2026-09-23, measurements/decision-api-overhead-2026-09-23.json) |
| Calibration | claimed and trained for | measured here on one constructed set of 60 support messages (the engine was under-confident there), and fitted per tenant from its own labels (Quality) |
| "Zero hallucinations" | their claim: every output is one of your options | true here too by construction, and not a claim about being right |
| Docs, SDKs, patterns, cookbooks, llms.txt, agent skill | yes | yes, this site; Python and TypeScript SDKs; an MCP server and Claude Code plugin; cookbooks run against this gateway and print measured numbers |
What the memory changes
With Jev, whatever your software knows about the account, the rules, the history, goes into state on every call, and you write the code that fetches and packs it. With Jers, you write it once to the subject's memory and name the subject. Recall picks the lines that share names and phrases with the state, places them before the state as a block of known facts, and the answer lists them. Measured in the escalation cookbook: two remembered lines moved the "escalate to a person" answer of jers-english from 0.20 to 0.82 and the route from support_queue to named_person; the control account did not move. Whether that is better is a question for your data; the point is that the answer shows what the memory did, and forget can take it back.
What Jers does not claim
No speed or cost multiples against language models. Calibration is fitted per tenant from its labels and measured, not claimed. The checkpoint is named in every answer, and the runtime library on the models page. The limits found while building the demos are documented on the Jaggedness page instead of hidden.