Comparisons · Last updated 2026-09-21

Jev vs batch processing

Batch processing is when you run work. Jev is what you call. People search this pairing because they want to score a million tickets overnight.

Unofficial. Models page vendor limits: 1,200 RPM and 250k tokens/second — can change without notice. docs.typesafe.ai/models.

Comparison scope

There is no documented “batch endpoint” separate from POST /v1/systemone in the public API we used. Batch means your job loop with backoff.

Criteria that decide the architecture

Decision quality and control

Official parallel-questions cookbook: one state, many questions, cheaper than N calls. That helps within a row. Across rows you still iterate.

Integration trade-offs

Chunk the file. Reuse HTTP connections / official SDKs (retries on 429/529). Persist answers before the next chunk. Pin jev-1.13.0 so a week-long job does not straddle an alias move.

TypeSafe’s public models page lists jev-1.13 at $0.042 per million input tokens with output tokens free — a vendor claim, not a jev.pro measurement. Confirm on the models page before you bid.

When each approach fits

Prefer Jev when

• The row needs a language judgment and can wait

Prefer Batch processing when

• The job is joins and aggregates

Batch is the clock. Jev is the call. Streaming page covers the other clock.

Queued POSTs inside the nightly job

Batch processing is when you run work. Jev is what you call. There is no documented “batch endpoint” separate from POST /v1/systemone in the public API we used. Sketch: scheduler (Airflow, Spark driver, cron) chunks the file → each row (or small group) is one evaluation with many questions on one state → persist answers + response.model before the next chunk → backoff on 429/529. Pin jev-1.13.0 so a week-long job does not straddle an alias move. Official parallel-questions cookbook: cheaper within a row. Across rows you still iterate.

Vendor models page: 1,200 RPM and 250k tokens/second — can change. $0.042 / M input (output free) is a vendor claim; multiply by rows yourself, we will not invent volume. Jaggedness still applies at night: do not ask Jev to join tables or aggregate counts. Spark owns joins. Jev does not generate a nightly report.

How a “batch API” gets invented

• Unofficial /v1/batch. Do not invent one. Pattern around /v1/systemone plus your queue.
• N HTTP calls per Noul per row. Official skill (npx skills add typesafe-ai/skills) exists because agents do this. Batch questions.
• Alias pin on jev-1.13. A week-long Spark job that starts on an alias can finish on a different response.model. Pin the patch.
• Cluster size as RPM. More executors × same door = 429. Match concurrency to vendor limits, not to executor count.
• Schema-safe labels as a warehouse fact. Write them as model outputs with as_of. Do not overwrite source-of-truth columns.

When not to use Jev here

Do not use Jev when the job is joins and aggregates with no language judgment. Do not use it as a Spark replacement. Prefer batch compute alone. Use Jev when the row needs a language judgment and can wait, inside your job loop with backoff.

What this page does not claim

• No unofficial /v1/batch invented.

• Schema-safe output is not the same as factual correctness.

• No independent bake-off numbers live here.

FAQ

Is there a TypeSafe batch API? Not in the public reference we used. Pattern around /v1/systemone.

Output tokens in batch? Vendor: output free; usage still reported.

Can Spark mapPartitions call Jev unbounded? Only if you cap in-flight POSTs to vendor RPM. Unbounded mapPartitions is how the door 429s the whole night.

Disclaimer

This is an independent unofficial site and is not affiliated with TypeSafe AI; official documentation is available at https://docs.typesafe.ai. Never treat jev.pro as TypeSafe official documentation. We do not sell, issue, or proxy API keys.

Hub: Comparisons. Siblings: vs streaming processing, vs asynchronous jobs, api rate limits. Canonical: https://docs.typesafe.ai.