# 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 | the same: $0.042 per million input tokens, output free; memory writes free |
| 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 decision: 71 ms end to end through https://api.getjers.com, measured from a server in Boston (median of 50 requests, p95 77 ms, 2026-09-24); the engine itself answers in 27 ms on its RTX 4090 GPU. From farther away, the network adds its round trip to the US East Coast. |
| 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. The limits found while building the demos are documented on the Jaggedness page instead of hidden.