Focused guide / AI Knowledge Hub
Jev’s published price: rate ratios and task bills
Calculate listed input-price ratios, then keep them separate from equal-work bills and measured savings.
Evidence checked 7 October 2026 · Examples unexecuted · Jev accuracy unmeasured; evaluation dropped
On this page
The published Jev rate is USD $0.042 per million input tokens, with $0 output charge. The TypeSafe rate card and OpenRouter Jev 1.13 listing agree on that rate, checked 7 October 2026. A zero output charge is a billing statement, not a statement that a response contains no output fields.
Jev accuracy in our use is unmeasured because the evaluation was dropped. No paid inference, matched-workload bill or latency measurement underlies this guide.
Calculate the listed input charge
For the published rate, the arithmetic is:
input charge in USD = billed input tokens ÷ 1,000,000 × 0.042
Thus one million billed input tokens gives USD $0.042 in input charge at that rate. This is a calculation, not a provider receipt or a completed-task cost. Use the provider’s recorded billed input usage rather than estimating a bill from the number of labels returned.
Compare exact uncached input rates
The Claude rate card, checked on the same day, lists the standard base input rates used below. These comparisons use explicit model versions and equal billed uncached input-token counts.
| Listed model | USD per million base input tokens | Listed input-rate ratio against Jev |
|---|---|---|
| Jev 1.13 | $0.042 | 1 |
| Claude Haiku 4.5 | $1 | 1 ÷ 0.042 = 23.81 |
| Claude Fable 5.1 | $10 | 10 ÷ 0.042 = 238.10 |
Ratios are rounded to two decimal places. They compare listed input prices, not total bills, equivalent outcomes or the versions actually used in the video. They say nothing about elapsed time.
Why a task bill is a different comparison
Equal token counts are a calculation basis. Equal text, complete work and acceptable outcomes require their own evidence. Tokenisation, prompt construction, output generation, caching and batching can change the charging basis. Downstream model calls, retries, correction and review can also change the work needed.
For a proposed routed workflow, account separately for classification and the downstream task. Record actual provider usage and the outcome before claiming a saving. If the lower bill leaves the task incomplete or creates more review, a rate ratio cannot resolve that difference.
For operating arrangements and output reuse, consult Weights. A price card does not settle contractual rights.
Do not turn marketing multiples into measurements
Speed and cost multipliers are marketing figures until their comparison basis is established. This element adopts none of the video’s speed, timing, volume or saving figures as results.
A published rate cannot prove faster completion, and a bounded output shape cannot isolate the cause of price or speed. There is no controlled causal comparison or local measurement here.
The next useful evidence would be matched task definitions, explicit configurations, complete usage receipts and outcomes that meet the same acceptance criteria. Listing those requirements is not authority to restart the dropped evaluation.
Keep the buying unknowns visible
Current eligibility, a particular account’s access, future rates and total task cost remain unverified here. The historical no-waitlist announcement is not an account test or an SLA.
Read bounded decisions for where the interface fits, and classifier possibilities for proposed uses. The rate arithmetic supports a narrow cost observation; accuracy, reliability, latency and savings in our use remain unmeasured.
Sources and limits
Primary rate cards: TypeSafe models, OpenRouter Jev 1.13 and Claude pricing, read 7 October 2026. Only the listed rates and derived uncached input ratios are asserted. No benchmark, provider bill or business outcome is supplied.