Jev pricing, rate limits and context window

The pricing page for Jev fits on one line, which is unusual enough to be worth a full page of explanation. This page gives the price, the limits, the model versions, the error codes and the SDKs from TypeSafe's documentation, then works a cost example with the arithmetic shown, and ends with the one caveat that TypeSafe itself puts on the price.

The price

TypeSafe charges $0.042 per million input tokens. Output tokens are free [1]. Written per billion, that is $42, which is the figure TypeSafe uses in some places.

Output is free because there is nothing to generate. A System One model returns probabilities over answers you defined, and reading those out costs no output tokens. So the whole bill is the input: the state, which is the text you send, plus the questions. For most requests the state is almost all of it, which is why many questions in one call is the pattern that matters for cost.

A worked example, with the arithmetic

Take a request whose state is 10,000 tokens, with a few questions adding 100 tokens. That is 10,100 input tokens. At $0.042 per million, the cost is 10,100 divided by 1,000,000, multiplied by $0.042, which is $0.0004242. Call it $0.00042 per request.

Scale it. One thousand such requests cost $0.42. One million cost $424.20. Ten million cost $4,242. Those are the numbers for a 10,000-token state, and a state that is a tenth of the size costs a tenth as much, so a 1,000-token support ticket with the same questions costs $0.0000462 per request and $46.20 per million.

Compare that with the shape of a language model bill, where output tokens are priced and a decision written out as a sentence plus a JSON object might run to 100 output tokens per request. We will not put a competitor's price next to Jev's here, because the fact sheet this page is written from does not carry one and prices change. TypeSafe's own comparison, reported by MarkTechPost, has Jev finishing a workflow decision for $0.000081 against $0.013880 for GPT-5.6 Terra [2], which TypeSafe reports as 444.6 times cheaper. TypeSafe's own team wrote the workflows, so that is a best case for Jev. Run the sum on your own state lengths and your own language model's rate card, and the ratio you get will be the one that matters.

The caveat TypeSafe puts on its own price

MarkTechPost reported on 19 September 2026 that TypeSafe says it cannot prove the price is unsubsidised [2]. Read that plainly: the company is telling you that it does not know whether $0.042 per million covers its cost of serving the model. A launch price for a model whose architecture is undisclosed may go up.

What that means for a cost model is one extra line. Compute the saving at today's price, then compute it again at two, five and ten times the price, and see at which multiple the decision changes. If Jev is 444.6 times cheaper on your workload, a tenfold price rise still leaves it 44 times cheaper, and the decision holds. If the saving is thin, it will not survive a price change, and you should know that before you build on it.

Context window and state limit

A request may carry 64k tokens. Of that, the state plus the longest question may use 32k [1]. A token is a piece of a word, and TypeSafe's own cookbook fits the 53,777-character Wikipedia article on the GDPR in a single request [3], so a long document fits. A codebase does not, a day of logs does not, and a full contract may not.

When something does not fit, select rather than truncate. TypeSafe's jaggedness page states that accuracy falls as the state grows with content unrelated to the decision [4], so a state that fills the limit with everything on hand is worse than a state that carries only what the question needs, even before the limit is reached. How to write the state and the questions covers the selection.

Rate limits

Two limits apply: 250,000 tokens per second and 1,200 requests per minute [1]. The second is 20 requests per second. Which one you hit first depends on your state length. At 10,000 tokens per request, 20 requests per second is 200,000 tokens per second, just under the token cap, so both limits bind at close to the same point. At 1,000 tokens per request, the request cap binds first and the token cap is far away. At 30,000 tokens per request, the token cap binds at 8 requests per second and the request cap is never reached.

Both limits favour the same shape: fewer requests carrying more questions. A service that fans its questions out into separate requests reaches the per-minute cap several times sooner for no gain, because TypeSafe evaluates every question in a request in parallel [5].

Model versions and aliases

The current model is jev-1.13.0, released 15 September 2026. Two aliases, jev-latest and jev-preview, both point to it [1]. TypeSafe's batching cookbook was measured on jev-1.12 [3], so a version before the current one existed and was used for published figures.

An alias is convenient and it is a risk for any decision with a tight threshold. When a new version is released, the alias moves, and the calibration curve for your question can move with it. Reveneau pins the model version for the grader in its eval suite and re-checks thresholds against stored labels before moving to a new version, because a grader whose threshold silently shifted would pass or fail changes for a reason nobody chose. Calibrated probabilities and confidence, explained has the re-check method.

The endpoint, the errors and the backoff

The API is a single endpoint: POST https://api.typesafe.ai/v1/systemone, authenticated with a bearer key [6]. Four error codes are documented. A 401 means the key is invalid. A 422 is a validation error, which is the request being malformed: a question of the wrong shape, a state over the limit, an option list over 255. A 429 is the rate limit. A 529 means "TypeSafe is temporarily overloaded" [6].

For 429 and 529 the docs say to use exponential backoff [6]: wait, retry, and double the wait on each failure, with a cap. Two details matter for a decision model specifically. First, a request is a pure function of its input, and TypeSafe reports that answers do not depend on what else is in the request [3], so a retry is safe and returns the same answer. Second, if the decision is on a path where a user is waiting, the backoff needs a ceiling after which code takes the safe default rather than waiting longer. TypeSafe's confidence docs describe falling back "to a different system" as one response to low confidence [7], and the same fallback applies to no answer at all. Jev in production covers the fallback design.

The SDKs

TypeSafe publishes two SDKs. The Python package is typesafe-sdk and needs Python 3.10 or newer. The JavaScript package is @typesafe-ai/sdk and needs Node 20 or newer. Both read the key from the TYPESAFE_API_KEY environment variable [8]. Both are thin wrappers over the one endpoint, so a team on another language can call the endpoint directly with any HTTP client.

For a decision model, the SDK is the least interesting part of the integration. The work is in the request shape, the thresholds and the fallback, and none of those live in the SDK.

Putting the numbers together

Here is the shape of a cost estimate for a real feature. Suppose a support product handles 200,000 tickets a month, each ticket is 1,500 tokens, and each ticket gets one request with four questions totalling 80 tokens. That is 1,580 tokens per request, 316,000,000 tokens a month, and at $0.042 per million, $13.27 a month. At ten times the price, $132.72. At 200,000 requests a month the rate limit is never close: that is 4.6 requests a minute on average against a cap of 1,200. The estimate takes five minutes, and it tells you the feature's model cost is small at any plausible price, so the engineering time is the only cost worth planning around.

Reveneau runs a similar sum for its eval suite. Every change goes through a suite written from the specification, and the checks that need a judgment go to Jev as one request per change, with the criteria, the diff and the plan as the state. On our own suite the run is ten times faster than it was with the previous grader. We do not publish what it costs, because we have not measured it in a way we could show the working for, and the speed is the figure we can stand behind. How Reveneau uses Jev describes the setup, and the pillar, Jev and System One models, covers the rest of the model. For the general question of what an AI feature costs to build, what it costs to build an AI product is the guide.