--- title: "TypeSafe Best Practices" answer: "TypeSafe's Jev is a System One model, not an LLM: one endpoint, `POST /v1/systemone`, that takes a `state` plus typed `questions` and returns typed `answers` with probabilities. Coolhand records the state as the user prompt and the questions as the system prompt. Several fields other providers populate are structurally absent, and bakeoffs don't apply." category: "Provider guides" tags: [] published: 2026-09-22T14:26:13Z updated: 2026-09-30T16:09:48Z canonical_url: https://coolhandlabs.com/help/typesafe-best-practices index_url: https://coolhandlabs.com/help.md --- # TypeSafe Best Practices TypeSafe's Jev is a System One model, not an LLM: one endpoint, `POST /v1/systemone`, that takes a `state` plus typed `questions` and returns typed `answers` with probabilities. Coolhand records the state as the user prompt and the questions as the system prompt. Several fields other providers populate are structurally absent, and bakeoffs don't apply. --- ## 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`. ```json { "state": "Help! My payouts have been failing for 3 days.", "model": "jev-latest", "questions": { "is_urgent": { "type": "noul", "instructions": "Does this convey urgency?" } } } ``` ```json { "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](https://coolhandlabs.com/help/llms-vs-system-one-models.md). --- ## 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](https://coolhandlabs.com/help/llm-request-log-fields.md). --- ## 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?](https://coolhandlabs.com/help/what-is-feedback-match-rate.md). --- ## 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 ```bash 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](https://coolhandlabs.com/inference-apis/typesafe-jev-1-13-0). --- ## Related - [LLMs and System One models: what's different, and when to use which](https://coolhandlabs.com/help/llms-vs-system-one-models.md) — what a System One model is, and when to use one instead of an LLM - [Jev: The Working Man's Classifier](https://coolhandlabs.com/updates/jev-the-working-mans-classifier.md) — why we think this category matters, and what we're building around it - [What every field on an LLM request log means](https://coolhandlabs.com/help/llm-request-log-fields.md) — every field on a request log, and who leaves it blank - [What is feedback match rate?](https://coolhandlabs.com/help/what-is-feedback-match-rate.md) — how feedback gets linked to the call that produced it --- Related: - [OpenRouter best practices](https://coolhandlabs.com/help/openrouter-best-practices.md) - [Google Gemini best practices](https://coolhandlabs.com/help/google-gemini-best-practices.md) - [AWS Bedrock best practices](https://coolhandlabs.com/help/aws-bedrock-best-practices.md) - [Anthropic API best practices](https://coolhandlabs.com/help/anthropic-api-best-practices.md) [← All help articles](https://coolhandlabs.com/help.md) · [Provider guides](https://coolhandlabs.com/help/category/providers.md)