Jev AI Pricing
Priced per billion tokens while everyone else prices per million, with output tokens not metered at all. Here is what that means in practice.
The published Jev AI rate card
| Item | Rate | Note |
|---|---|---|
| Input tokens | $0.042 per million | Equivalently $42 per billion tokens |
| Output tokens | Free | Not metered — described as too cheap to meter |
| Per decision | ~$0.0004 | TypeSafe's internal workflow benchmark |
| Frontier comparison (Terra) | ~$0.0304 | Roughly 76× more per case |
| Frontier comparison (Sol) | ~$0.0836 | Roughly 209× more per case |
The unit is the first thing that trips people up. Everyone else quotes dollars per million input tokens; TypeSafe quotes per billion, because at $0.042 per million the per-million figure would round to nothing in a comparison table. Multiply by a thousand and you get $42 — a number you can actually reason about.
What Jev AI costs at volume
Per-token rates are hard to feel. Per-month totals are not. The table below uses TypeSafe's own benchmark figure of roughly $0.0004 per decision, which assumes a modest amount of context per case — your own numbers will move with how much material each question carries.
| Volume | Approx. cost | What that is |
|---|---|---|
| 10,000 / month | $4 | A small support desk. Rounds to a rounding error. |
| 1,000,000 / month | ~$400 | Mid-size moderation queue running on every submission. |
| 10,000,000 / month | ~$4,000 | Marketplace-scale classification on every listing. |
| 100,000,000 / month | ~$40,000 | Inline validation on every step of a busy agent fleet. |
Run the same volumes against a frontier model at roughly three cents a case and the million-case row becomes thirty thousand dollars a month instead of four hundred. That gap is the entire commercial argument, and it is why the interesting question is not whether Jev AI is as smart as a frontier system, but whether it is smart enough for the decision in front of you.
Is Jev AI pricing sustainable?
The obvious suspicion is that these numbers are venture-subsidised and will correct upward once the early-access period ends. TypeSafe's own answer is unusually direct: it cannot prove otherwise, and long-term sustainability will have to be demonstrated rather than asserted. What it does argue is that the economics follow from the architecture rather than from a discount — a model that produces one value per query does a fraction of the compute of one that produces a thousand tokens, and that ratio does not change with funding.
The company's stated expectation is that prices fall rather than rise. That is the direction the whole industry has moved, and there is no obvious reason this corner would be an exception. Still, if you are building a business case, the prudent move is to model it at a multiple of the current rate and check that the numbers still work. If a 5× increase breaks your margin, you have a dependency risk regardless of who the vendor is.
Free output tokens on Jev AI are less mysterious than they sound. When a response is a single typed value, metering it would cost more in accounting than it could ever collect. Calling that "too cheap to meter" is accurate rather than promotional — and it is also why the free-output promise is one of the safer parts of the rate card to rely on.
One more thing worth budgeting for: context is where your bill actually lives. Because input is the only metered side, the difference between sending a whole document and sending the three paragraphs that matter is the difference between two invoices. Teams that trim aggressively — stripping boilerplate, truncating threads to the relevant turns, dropping attachments that never affect the outcome — routinely land well under the benchmark figure. Teams that pipe entire records in unfiltered land well above it. The rate card is the same for both; the engineering is not.
Building the business case
The comparison that persuades a finance team is rarely against another model. It is against whatever is handling the work today, which is usually a mix of a rules engine and a queue of people. Price that honestly: the fully loaded hourly cost of a reviewer, the cases they clear per hour, and the share of those cases that were never ambiguous in the first place.
Then model three lines rather than one. The automated share at a fraction of a cent per case. The reviewed share at the human rate. And the error cost — what a wrong decision actually costs you, multiplied by the rate you observed during calibration. That third line is the one teams forget, and it is the one that determines where the confidence threshold should sit. A high error cost pushes the threshold up and the automation rate down, and the model still pays for itself as a pre-filter.
What tends to surprise people is the second-order effect. Once per-decision cost drops far enough, you stop rationing judgement. Work that was sampled gets checked in full; checks that ran nightly run inline; questions nobody bothered asking because the answer was not worth the compute get asked routinely. The savings on the existing workload are real, but the change in what you are willing to automate at all is usually the larger number.