Inference pricing · TypeSafe AI
TypeSafe AI sells Jev at $0.042 per million input tokens, output free. That is a linear price. The cost underneath it is not.
A published price is a constraint. It has to cover the FLOPs the model burns, on hardware you can actually rent, or it is a subsidy. Working backwards from $0.042 per million input tokens tells you roughly how big the model can be, and — more interestingly — which workloads a flat per-input-token price cannot cover at any model size.
Three things move the answer. Weights cost 2P FLOPs per token slot.
Attention adds 4·L·d·n_layers, which grows with the context, so cost is quadratic in
document length where revenue is linear. And Jev answers N questions per document against a
published price that never says which side of “input tokens, output free” a typed
question falls on — a definition worth more than it sounds. The panel below is that arithmetic;
the figures are the same model swept along one axis at a time.
Uncheck if only the document counts. The price card says “input tokens, output free” without saying which side the questions fall on.
A rented accelerator converts dollars into FLOPs at a fixed rate. Peak dense throughput, derated by the fraction you actually achieve, divided into the hourly price:
At the default rig that is about 1.25e-18 dollars per FLOP. Revenue is
4.2e-8 dollars per input token. Divide and you get the compute budget a single token can pay
for: roughly 3.4e10 FLOPs. A dense forward pass spends 2P of those in the
weights, so at break-even P = 1.7e10 — about 17B parameters. FP8 roughly
doubles it.
That is a ceiling at zero margin. A business wanting 80% gross margin on inference has to fit in a fifth of it, which lands in the low single-digit billions. The price card is not consistent with a 70B model under any rental price currently on the market; it is very consistent with something small, which is exactly what you would build if you wanted one parallel pass in under 500ms.
The weights term is not the whole cost. Attention over a context of L tokens
contributes 4·L·d·n_layers FLOPs per slot, so the cost of a document is:
Revenue has one power of L. Cost has two. There is therefore a document length past which every additional token is sold below cost, and it does not depend on how the product is marketed — only on shape:
For the default 3B model on H100 BF16 that crossover sits near 87k tokens. FP8 pushes it to roughly 192k. Neither number is anywhere near the context lengths a document-analysis product invites you to use. Send a 500k-token contract and the call loses money by construction, no matter how many questions you ask or do not ask.
Note what hardware does and does not fix. B200 buys roughly 2.3x the FLOPs at roughly 2.5x the hourly rate, so at these list prices its dollars-per-FLOP is actually slightly worse than an H100 — 6.9e-19 against 6.2e-19 at FP8. Newer silicon does not move this wall. Precision does, and it is the only lever on the page that buys a full doubling.
The obvious guess is that question slots are where the money leaks: Jev answers N questions per document, output is free, so surely N is unpriced compute. Work it out and the guess is wrong, in a way that turns out to be more interesting.
At full depth a question slot is arithmetically identical to a document
token. It traverses the same stack, it attends over the same L positions, so it costs
2P + 4·L·d·n_layers — exactly what a document token costs. And if it bills as an
input token, it earns exactly what a document token earns. Cost and revenue scale together, so
the margin does not move at all:
That is why the boundary in Fig 3 is a vertical line at the default settings. Asking one question or ten thousand changes nothing. The whole exposure is in L, which is section 02's problem, not a new one.
The neutrality rests entirely on a word the price card never defines. It says input tokens, output free. A typed question is neither, obviously: it is something you send, that produces something you receive. If questions bill as input, N is free of consequence. If they are treated as part of the decision output — free — then every question slot is pure unpriced compute, and N tilts the boundary hard. Untick the billing box in the panel: an 8k-token document with 5,000 questions goes from a 3.9x margin to 0.65x, without changing anything else.
This is also where the amortization story has to pick a side. Jev's cost claim needs many questions per document — that is what spreads the encode. But each question either bills, in which case it is just input tokens and the “output free” framing is doing no work at all; or it does not, in which case the cheapest workloads for a buyer are the ones that lose the most money for the seller. There is no third option, and the price card does not say which one it is.
None of this says the price is wrong. Flat prices are a product decision, and a seed-stage lab pricing below cost to buy adoption is ordinary — the number on the card tells you what they want the workload to cost a buyer, not what the GPU does. What the arithmetic does say is narrower and more useful:
The price bounds the model. At $0.042 per million input tokens, a profitable Jev is small — low single-digit billions of parameters. That is consistent with the latency claim and inconsistent with "frontier-scale". It also means the comparison that matters is against a fine-tuned cross-encoder, not against a chat model doing classification.
The price cannot survive long context. A linear per-input-token price against a quadratic attention cost has a crossover, and for a model this size it arrives well before the context lengths document workloads use. Expect a length cap, length-tiered pricing, or a quiet repricing.
One undefined word carries the rest. Whether a typed question bills as an input token decides whether N is free of consequence or the whole exposure. The published card does not say. That is not a rounding error in a pricing page; it is the difference between a neutral axis and an unbounded one, and it is the first question worth asking them.
The practical read for a buyer is the inverse of all this. Jev's price is a genuine bargain on short documents with many questions — and that is also the regime where a self-hosted cross-encoder is cheapest to run yourself, because the encode you are amortizing is small either way. The place you would most want a hosted model to save you, long documents, is the place this price cannot survive. Price your own workload at both ends before you join the waitlist.
| Quantity | Value used | Why, and how wrong it could be |
|---|---|---|
| Jev price | $0.042 / M input | Published on typesafe.ai, September 2026. Output stated free. |
| H100 SXM | 989 / 1979 TF, $2.00/hr | Dense BF16 / FP8, no sparsity. Rental price varies 1.5–3 by provider and commitment. |
| H200 SXM | 989 / 1979 TF, $2.50/hr | Same compute as H100, more HBM. Memory headroom does not change these FLOP sums. |
| GH200 | 989 / 1979 TF, $2.20/hr | Hopper GPU beside Grace. Priced as a superchip node. |
| B200 | 2250 / 4500 TF, $5.00/hr | Dense. Rental pricing is still thin and moves fast; this is the softest cell in the table. |
| MFU | 0.45 | Prefill is compute-bound and batches well, so this is achievable but optimistic at long context. |
| Model shape | P = 12·n·d², d/n = 128 | Standard aspect ratio. Reproduces Llama-7B and -70B shapes to within a few percent. |
| Attention | 4·L·d·n per slot | Full dense attention. Sliding-window, GQA on the KV side, or any sparsity pushes the wall right — this is the most consequential simplification here. |
| Question cost | depth × full slot | Jev's architecture is unpublished. Exposed as a knob for that reason; at depth 1.0 a question is a full token slot. |
| Excluded | — | KV cache reuse across calls, batching inefficiency, serving overhead, networking, storage, idle capacity, and any margin on hosting. The first helps them; the rest hurt. |
Everything above is an analytical model built from published prices and public hardware specifications. No part of it is a measurement of Jev, which is in gated early access. Where a number could not be sourced it became a control in the panel rather than a hidden constant.
← All notes