What does typed end to end actually buy me at compile time?

The key is the mechanism: questions.add takes an id and a question and returns a QuestionKey typed by how its answer is read, so reading a Choice answer as a yes/no probability does not compile. Enums declared through choice_options! map straight to options, and responses are verified against the questions before you get them, so a mismatched or missing answer surfaces as an error rather than a confusing value.

Can I use it in tests, or without an HTTP stack at all?

Both. Your application code depends on the SystemOne trait, and the fake feature provides an in-memory implementation that answers every question and records requests. Separately, disabling default features leaves you with just the types, builders and validation and no HTTP stack, which is useful if another component owns transport. The default http feature is reqwest with rustls.

How does it behave when the API is flaky?

Production defaults are already conservative: 408, 429 and 5xx responses, connection errors and timeouts all retry with exponential backoff, Retry-After is honored, and every call carries a hard deadline. Combined with the pre-send validation against documented limits, a request should fail fast when it is malformed rather than after a round trip.

Are the answer types what I expect, or do the numbers mean something else?

Three things to internalize. A Noul answer is the probability of yes, so near 0.5 means unsure, not partly true. A Score is a probability-weighted position between 2 and 10 levels, which is why the crate offers nearest_level() and normalized(). And choice probabilities always sum to 1, so a separate Noul question about whether any option fits is the documented pattern rather than a workaround.

How do I add it to a Rust project?

Add typesafe-client = "0.1" and tokio with the macros and rt-multi-thread features, then expose TYPESAFE_API_KEY. The crate is on crates.io at version 0.1 with an MSRV of 1.87, under MIT OR Apache-2.0, and it is unofficial.

What do the feature flags change?

The default http feature adds the Client, an async HTTP client using reqwest with rustls. The fake feature adds an in-memory FakeSystemOne for tests. Disabling default features leaves only the types, builders and validation, with no HTTP stack.

How do I read a Score answer?

A Score is a probability-weighted position across 2 to 10 ordered levels, so it can fall between levels. The crate gives you the raw score plus nearest_level() to round it and normalized() to scale it to 0-1 so scores with different level counts can be combined.

CommunityJev Repos & SDKs

TypeSafe Client — JedimEmO

An unofficial async Rust client for the TypeSafe System One API in which each question hands back a key typed by its answer, so reading a choice answer as a probability fails to compile.

See highlights

Open github.com

Stars: 1
Language: Rust
License: APACHE-2.0
Published by: Community
Author: JedimEmO
Last verified: Oct 2026

JedimEmO/typesafe-client

User repository on GitHub

View on GitHub

Unofficial typed async Rust client for the TypeSafe System One API

Forks: 0
Last pushed: Updated Oct 2026

Repo stats from the GitHub API, cached Oct 2026.

This is one of several Jev listings for the same project. The canonical entry is TypeSafe Client — haileyok.

About this project

A typed, async Rust client for the TypeSafe System One API. TypeSafe's System One models, such as Jev, don't generate text. They answer narrow questions about content you give them, and return typed answers with calibrated probabilities: the probability that something is true, the most likely option out of a set, or a position on a scale. This crate lets you ask those questions from Rust and read each answer back as the type its question promises.

Quoted from the project's README. Read the full README.

Tagscommunity jevbest catalog-import awesomejev

Works forJev for Classification

Used inJev for Software & DevTools

Languages: Rust

Highlights

Typed both ways: questions.add returns a key typed by its answer, and responses are verified against the questions before you see them.
Requests are validated against the documented limits before sending, and 408, 429, 5xx, connection errors and timeouts retry with backoff.
Options come from an enum via choice_options!, from runtime values via ValueChoice, or as 2 to 10 ordered score levels.
Without default features the crate is types, builders and validation with no HTTP stack; a fake feature adds an in-memory SystemOne for tests.

Watch out

Unofficial and independent, published on crates.io at 0.1 with an MSRV of 1.87 under MIT OR Apache-2.0, so expect surface churn while it matures. Semantics that will bite you are documented but easy to skim past: the question id is never sent to the model, so each question's instructions must stand alone; a Noul answer near 0.5 means the model is unsure rather than that something is partly true; a Score is a probability-weighted position that can land between levels, so nearest_level() and normalized() are deliberate choices; and choice probabilities always sum to 1, which is why the guide asks a separate yes/no question about whether any option fits. Defaults read TYPESAFE_API_KEY, and optionally TYPESAFE_BASE_URL and TYPESAFE_DEFAULT_MODEL. This review covers the README through the structured-state section, so deeper guide material is unverified. Copy reviewed against the repository README on 2026-10-04, not from running it.

Questions about this entry

Short answers drawn from the linked project or page.

More Jev resources like this

typesafe-sdk-rust

Unofficial Rust client for the TypeSafe AI System One API, matching the Python SDK 0.6.0 contract: named noul, choice and score questions, a typestated builder, per-call overrides, and a `wire` module for serving the same shape.