Direct answer: Jev bills input tokens only, at 0.042 USD per 1M tokens, and output tokens are free. The cost of a run equals the input tokens of every request multiplied by 0.042 and divided by 1M. Our audit used 287 calls and 222,946 input tokens, so the bill came to 0.0094 USD.

It holds when: you use model jev-1.13 at the price published on 21 September 2026. Limits: prices change, and your state size decides the final bill rather than the number of questions.

We wrote this guide from the official TypeSafe pricing page and from our own run on 20 September 2026. The token figures come from the usage field of the answer, not from an estimate.

What is billed and what is not

A generative model bills both sides: the tokens that go in and the tokens that come out. Jev bills one side.

PartBilledNote
The stateYesThe material under judgement, counted once per request
Question instructionsYesThe criteria of each option included
The answer returnedNoOutput tokens are free
The question keyNoIt is not sent to the model

Because output is free, a question that returns a long probability spread adds nothing to the bill. Only the text you send adds to it.

A diagram of the Jev cost formula in 3 steps: count one request, multiply by the requests, then multiply by 0.042 USD per 1M tokens, with a real audit example
The 3 step formula, then the real figures from the 20 September 2026 audit: 287 calls, 222,946 input tokens, 0.0094 USD.

The formula and a worked example

Take the input tokens from the answer, then multiply by the price. The code below does it for a whole run.

# 1 permintaan, 12 pertanyaan, 1 kali biaya state
total_token = 0
for hasil in jawaban:
    total_token += hasil["usage"]["input_tokens"]

biaya_usd = total_token * 0.042 / 1_000_000
print(f"{total_token} token masuk, {biaya_usd:.4f} USD")

A small example. One chat reply of 800 input tokens costs 0.0000336 USD. A thousand of the same costs 0.0336 USD.

Our own example. The audit of 227 sessions used 12 questions per conversation, 5 per assistant reply, and 3 per session record. That came to 1,100 questions across 287 calls, took 222,946 input tokens, and stopped at 0.0094 USD.

The cost of 1,000 decisions

The table uses 3 state sizes we met ourselves. The numbers are estimates, and your own request size decides the final figure.

A cost table for 1,000 records at 3 state sizes: 300 tokens, 800 tokens, and 3,000 tokens, with costs from 0.0126 to 0.1260 USD
The cost follows the state size, not the number of questions. Stacking questions into one request keeps the state billed once.
State typeTokens per record1,000 recordsCost
A short record, such as session metadata300300,000 tokens0.0126 USD
One chat reply800800,000 tokens0.0336 USD
A full conversation3,0003,000,000 tokens0.1260 USD

Note that all 3 rows carry the same number of questions. Only the size of the material differs.

Four ways to cut the bill

  • Stack questions into one request. The state is billed once, so 12 questions in one call cost far less than 12 calls. Source: the fan-out pattern.
  • Filter the state first. Send what the question needs, not the whole history. This lowers the cost and raises the answer quality.
  • Use a closed shape rather than long prose. A short JSON object uses fewer tokens than the same content written as narrative.
  • Filter in code before you call the model. A record that is plainly irrelevant needs no model at all.

In our audit, stacking 12 questions into one call held the call count at 287 rather than above 1,000.

Rate and context limits

LimitValue
Tokens per second250,000
Requests per minute1,200
Context per request64k tokens
State plus the longest question32k tokens

A request over the limit returns status 429. The official SDKs retry with growing backoff and honour the retry-after header. Source: the TypeSafe models page.

In our audit, 8 to 12 concurrent requests never touched those limits.

Comparing the cost with human work

The fair comparison is not against another model. It is against the old way. Reading 227 conversations by hand takes hours, and judgement drifts after the twentieth one.

The machine run took 20.8 seconds and 0.0094 USD, with the same rubric across the whole queue. The full story is in our guide to auditing conversations with Jev.

Rama Digital recommends: cost it per decision, not per month. A figure under one cent per decision is what lets you put a guard on every single turn.

Which part makes a request expensive

One request carries 3 billed parts. Knowing the share tells you which part deserves trimming.

PartTypical shareHow to trim it
The state70% to 90%Filter it, send only the fields the question uses
Question instructions5% to 20%Write one exact sentence, not a paragraph
Option criteria5% to 15%Use a short sentence per option, not a long example

These shares come from our own requests in the 20 September 2026 audit. When your state is a long conversation, the share shifts further toward the state.

One habit saves the most: never send a full conversation to judge one reply. Send the visitor question and the reply under judgement. In our audit a reply level request used about 800 tokens, while a conversation level request used up to 3,000.

A budget for 3 business sizes

These 3 scenarios use a state of 800 tokens per decision. The figures are monthly estimates, and your record size decides the final number.

ScenarioDecisions per monthInput tokensCost per month
A small shop, 1 chat channel3,0002.4M0.10 USD
A mid business, 3 channels30,00024M1.01 USD
An agency, 20 clients300,000240M10.08 USD

Note that the agency scenario still sits under 11 USD a month. At this size the cost stops being the deciding factor, and the quality of the rubric takes over.

The counting mistakes people make

These 3 mistakes push an estimate far off, and all of them are easy to avoid.

  • Counting per question rather than per request. Twelve questions in one call carry the state cost once, not 12 times.
  • Forgetting the criteria. A long option list becomes input tokens, so options with long examples raise the bill on every request.
  • Estimating in words rather than tokens. One word often becomes more than one token, so read the usage field instead of a word count.

The safe method stays the same: run 10 sample records, read the real figure, then multiply. An estimate from 10 records lands far closer than any paper calculation.

Frequently asked questions

Is there a monthly fee? The official pricing page lists only the input token price. Check that page before you set a budget, because prices change.

Why are output tokens free? Jev generates no text. Its output is only numbers and choices, so it stays small and fixed.

How do I cost a run before I make it? Send 10 sample records, read usage.input_tokens, then multiply by your record count. The estimate stays close when your records are similar in size.

Do extra questions add cost? More questions add instruction tokens, and that is small. The state is what grows, so stack the questions and keep the state lean.

What does a guard on every chat turn cost? At our reply size, one guard costs about 0.00003 USD per turn. A thousand turns stops under 0.05 USD.

Next step

The remaining limit: a cost figure says nothing about answer quality. A poor rubric still returns poor decisions, cheaply. We wrote about checking a claim before you use it in What is a meat proxy.

If you want us to work out which decision point deserves automation first, open AI Diagnostic. To talk it through first, pick an AI Diagnostic slot.

Sources