Jev Pricing: From One Request to a Workflow

A tiny per-request price does not prove that an entire workflow is inexpensive. A useful budget includes request volume, input length, retries and what happens after the model answers. This chapter gives you arithmetic whose assumptions can be replaced with your own records.

Fix the source and date first

On this edition's check date, September 20, 2026, the TypeSafe model reference lists direct API input at $0.042 per million tokens, with output tokens free. This chapter uses the direct-provider rate. If you use a gateway, check that gateway's price, additional fees and credit rules separately. See the official model and price reference.

This is not a promise of permanent pricing. Check your account's current billing terms before purchasing access or increasing volume. The publication date, handbook version and request date can differ; actual service terms and invoices take precedence.

Both the material and the questions are supplied to the service. Do not substitute word count for token count, particularly when moving between English and Chinese. Record usage.input_tokens from real responses and reconcile it with billing. The API reference defines the usage fields.

A reusable calculation

Input-model cost in USD
= sum of input_tokens across actual requests
  / 1,000,000
  * price per million input tokens

These are arithmetic examples, not measurements from this book. Assume an average of 1,200 input tokens per request and a rate of $0.042 per million:

These figures exclude tax, other models, hosting, tools and people. They also do not establish adequate decision quality. An inexpensive wrong decision can still create costly rework.

Include retries

Suppose 10,000 business tasks result in 10,800 actual requests, still averaging an assumed 1,200 tokens. That is 12,960,000 input tokens and an estimated $0.54432. The eight percent extra request rate is a teaching assumption, not a measured property of Jev.

Count requests sent, not only business tasks eventually completed. A timed-out request may have no usage record available to the client. Keep its cost unknown until you reconcile with provider billing. Missing usage is neither proof of free processing nor a reason to fill the field with zero.

Cost units for the three cases

Independent questions about the same material can be organized in one request. Shared material can reduce repetition, but questions still have length; trust measured usage rather than assuming a fixed saving. Parallel answers also do not authorize parallel execution of tools without parameter and permission checks.

The package's offline mode sends no model request. Model usage and model latency should therefore be absent or explicitly unmeasured. The time needed to read a local JSON file is not inference latency. A count of fixtures is not a bill.

Optimize the parts that matter

Start by asking which input helps the decision. Ticket triage rarely needs an entire historical mailbox. An editorial check may need the draft and rubric but not the site's complete page template. After removing material, compare decisions on the same development examples to ensure that useful evidence was not discarded.

List the judgments the application actually uses. If it only needs to know whether a procedure is missing, dozens of unused scores add complexity. If it needs four independent checks over the same draft, group those questions thoughtfully rather than repeatedly sending the entire draft in separate calls.

Consider concurrency after the request design works. More parallel requests may shorten a batch's wall-clock time, but may also trigger limits and extra attempts. Record total batch time separately from request latency. Throughput, latency and decision accuracy are distinct measurements.

Add the human line to the budget

A practical budget contains model calls, other services, runtime infrastructure, review and rework. The human component often depends on review rate and error type as much as on traffic volume.

One threshold may automate more tickets while increasing wrong-team handoffs. Another may require more initial review but reduce later rework. Use the evaluation chapter to compare the two policies, then estimate their workloads. There is no universally cheapest threshold without data from the actual process.

You have completed this chapter when you can replace the assumptions in the table with a real run record and identify which costs remain uncounted. Where this edition has no live measurements, an explicit “not measured” is more useful than an attractive decimal.