Jev is a System One model, not an LLM
Every TypeSafe request goes to a single endpoint, POST /v1/systemone. There is no
messages array, no streaming, and no generated text. You send:
state— the thing being judged. Text only: a string, a JSON object, or an array of text values. No image, audio or video input; pre-process those into text first.questions— a map of typed question objects, under keys you choose.model— which model answers.
and you get back one answer per question, under the same key, plus usage.
{
"state": "Help! My payouts have been failing for 3 days.",
"model": "jev-latest",
"questions": {
"is_urgent": { "type": "noul", "instructions": "Does this convey urgency?" }
}
}
{
"model": "jev-1.13.0",
"answers": { "is_urgent": { "type": "noul", "noul": 0.95 } },
"usage": { "input_tokens": 296, "output_tokens": 20 }
}
Questions come in three types — noul (yes/no, returns the probability the
answer is yes), choice (one option from a set you define, up to 255, returned
with the full probability distribution and a confidence), and score (a rubric
of 2–10 ordered levels, returned as a probability-weighted value with a confidence).
Jev reads the state once and evaluates every question against it in parallel.
For what this category of model is for and when to reach for one, see LLMs and System One models: what's different, and when to use which.
What the prompt and response fields contain
| Coolhand field | Contents |
|---|---|
| User Prompt | The request's state |
| System Prompt | The request's questions — the instructions and criteria |
| Assistant Response | The response's answers |
| Model | The resolved version from the response (e.g. jev-1.13.0), not the alias you sent |
Non-string values are stored as JSON, so a structured state or a multi-question
questions map is preserved as sent rather than flattened.
This mapping is what makes Jev calls group and compare sensibly: Coolhand files them
under a system_one group of their own, and similarity search scores the state
and the questions, because for a System One call the questions carry as much of a
template's identity as the input does. Full field-by-field detail for every provider
is in What every field on an LLM request log means.
Send an alias, log the version
jev-latest and jev-preview are aliases that resolve to a versioned id — both
currently point to jev-1.13.0. Coolhand records the version from the response,
which is the one that actually answered, so your logs stay accurate even though you
sent an alias.
The catalog carries a row for the resolved version only. If you ever see
jev-latest itself appear as the model on a log, that means the response body was
missing or unparseable and the ingestor fell back to your request — those rows can't
be priced. It's a capture problem, not a missing catalog entry.
An alias moves when TypeSafe ships a release, so the answers behind it can change without a change on your side. If you've tuned confidence thresholds against a specific version, send that version's id rather than the alias.
Context length: two budgets, not one
TypeSafe documents 64k tokens per request, and separately 32k tokens for the
state plus the single longest question. The 64k budget covers the state plus all
questions combined.
The catalog shows the 64k figure, because a context window there is a single number. The 32k sub-budget has nowhere to live in that field, so plan against both: packing more questions into one request spends the 64k budget, while a long state plus one verbose question can hit the 32k limit well before you get near 64k.
TypeSafe also publishes guidance on how accuracy shifts as the state grows. A request that fits is not automatically a request that answers well — test with states the size of your real ones.
Structured outputs
Structured output isn't a mode you opt into; it's the entire interface. You declare
each answer's type up front and the response conforms to it. There is no
response_format, no "respond with JSON only" instruction, no parser to maintain,
and no retry when a model opens with a preamble.
The tradeoff: Jev returns a probability, not an argument. If your workflow needs to show a human why, that has to come from somewhere else.
Caching
Not applicable. TypeSafe publishes no prompt-caching feature, and the response carries no cache fields. Cached Input Tokens and every cache-creation field are always blank on TypeSafe logs.
Batch processing
Not applicable. TypeSafe has no batch API, and no discounted batch tier — so unlike most providers, there's no cost saving to capture by deferring work. Pricing is a single input rate regardless of how you send the request.
Latency
Coolhand records the collector-provided duration_ms as wall-clock latency.
TypeSafe's response carries no server-side processing header, so there's no
provider-reported figure to prefer over it and no way to separate network time from
inference time.
Rate limits
TypeSafe publishes 250,000 tokens per second and 1,200 requests per minute,
and returns 429 when a request exceeds either. Their docs warn that these limits
are adjusting dynamically and can change without notice, so treat a published number
as a snapshot rather than a contract. Their SDKs retry with backoff and honor
retry-after by default; if you call the HTTP API directly, handle 429 and 529
yourself with exponential backoff.
A rate-limited request returns no answers, so Coolhand records it as an error
rather than as a contentless success — rejected requests show up in your logs as
failures, not as silently empty results.
Fields that are always blank
Structurally absent from TypeSafe's responses, not missing by mistake:
| Field | Why |
|---|---|
| Temperature | Not a parameter Jev accepts |
| Cached Input Tokens and all cache-creation fields | No caching feature |
| Reasoning Tokens | Jev doesn't emit a reasoning trace |
| Audio Input Tokens | Text-only input |
| Truncation / finish reason | The response reports no finish reason |
Feedback on Jev outputs needs a log id
TypeSafe's response carries no request or response id — there is no id field in
the documented response shape. Coolhand falls back to a synthesized identifier for
deduplication, which works fine for logging, but it means the fastest and most
reliable feedback-matching tier, provider-id matching, is unavailable for Jev.
Send the Coolhand request log id with your feedback on a Jev output. Content matching still works as a fallback, but on short typed answers there is much less text to match on than there is with a paragraph of generated prose, so relying on it will cost you match rate. See What is feedback match rate?.
Bakeoffs don't apply, but Coolhand can compare Jev to your LLM
A bakeoff swaps a different model in for the original and compares the results. No LLM can stand in for a System One call — the request isn't the same shape, so there is nothing to swap. System One models are excluded from bakeoff selection, and Jev templates don't offer the option.
Coolhand compares the two a different way: instead of swapping a model id, it translates the task into both shapes. When Coolhand's optimization analysis looks at an LLM call that is really a classification or routing decision, it writes the equivalent typed question for Jev, runs Jev over the same inputs your LLM saw, and scores both against what you already have — a human correction or thumbs-up on that call where there is one, otherwise the call's correctness evaluation. It reports the quality, cost and latency difference together, so a recommendation reads like "same accuracy, 25x cheaper" rather than just "cheaper."
Two things to know:
- It needs labeled history. The comparison scores calls that already carry a correctness evaluation or human feedback. With too few of them, Coolhand says the quality check was inconclusive rather than guessing. Sending feedback on your outputs (see above) is what makes it possible.
- It sends prompts to TypeSafe. Because the comparison calls Jev with your real inputs, it is skipped for clients with a Business Associate Agreement unless Jev is BAA-available.
Evaluations and correctness scoring also work normally on your Jev templates, so you can keep measuring whether Jev is getting your task right once you've switched.
Finding Jev in the catalog
curl "https://coolhandlabs.com/api/v2/inference_apis?q[model_type_eq]=system_one"
Keyless and free. The same model_type filter is available on the
list_inference_apis MCP tool, and the model page is at
Jev 1.13.
Related
- LLMs and System One models: what's different, and when to use which — what a System One model is, and when to use one instead of an LLM
- Jev: The Working Man's Classifier — why we think this category matters, and what we're building around it
- What every field on an LLM request log means — every field on a request log, and who leaves it blank
- What is feedback match rate? — how feedback gets linked to the call that produced it