tinyhumansai/tinyjevclientArchived
Organization repository on GitHub
Integrate decision models (Jev, OpenJev, Sage) in Rust
- Forks
- 1
- Last pushed
- Updated Sep 2026
Repo stats from the GitHub API, cached Oct 2026.
CommunityJev Repos & SDKs
Tinyjevclient
Typed Rust client for TypeSafe's System One API that sends shared state with independent Choice, Score and Noul questions, validates the provider's response against the originating request, and returns latency, attempts and usage with the answers.
- Stars
- 0
- Language
- Rust
- License
- GPL-3.0
- Published by
- Community
- Author
- tinyhumansai
- Last verified
- Oct 2026
About this project
tinyjevclient is a typed Rust client for TypeSafe AI's System One API and Jev model. It sends shared state with independent Choice, Score, and Noul questions, validates the provider's response against the originating request, and returns latency, attempts, usage, and request metadata alongside the typed answers.
Quoted from the project's README. Read the full README.
Works forJev for Classification
Used inJev for Software & DevTools
- Languages
- Rust
Highlights
- Response validation is provider-aware: answers are checked against the originating request rather than deserialized and trusted on arrival.
- Failed evaluations keep their classified error, attempt count and elapsed time so reliability measurements do not lose unsuccessful work.
- The API key is read from TYPESAFE_API_KEY or ClientConfig, is redacted from Debug output, and is never included in errors.
- Remote API roots must use HTTPS; HTTP is reserved for literal loopback IPs.
Watch out
Short README, but the constraints are explicit. Response validation is provider-aware, so answers are checked against the request that produced them rather than deserialized and trusted, and remote API roots must use HTTPS with HTTP reserved for literal loopback IPs. Failed evaluations retain their classified error, attempt count and elapsed time specifically so reliability measurements do not lose the unsuccessful work. The API key comes from TYPESAFE_API_KEY or ClientConfig, is redacted from Debug and never included in errors. Licensing matters for adoption: the repository is GPL-3.0-only, which is a real constraint inside a permissive codebase, and it is consumed by pinned git revision. Routing options are explicit too - ClientConfig::openrouter for OpenRouter, with_endpoint_url for a compatible router on a nonstandard path without weakening validation, and tinyhumans_openrouter for a Tiny Humans key, where with_sdk_name("openhuman") attaches sanitized x-sdk-name attribution sent only to that exact HTTPS endpoint. Not documented: a retry policy, default timeouts, model listing, streaming, or what a call costs. 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.
No. The client validates the provider's response against the originating request, and that validation is provider-aware, so pointing it at a different host does not weaken it. That is the point of the with_endpoint_url example: a compatible router exposed at a nonstandard path can be selected while the checks stay in place. It is also why a remote root must be HTTPS, with HTTP reserved for literal loopback IPs - the restriction is part of the trust model rather than a convenience.
No. Failed evaluations retain their classified error, attempt count and elapsed time, so reliability work does not silently drop the failures - successful calls return latency, attempts, usage and request metadata alongside the typed answers. That specific behavior is called out in the README, which makes this client more useful for error-rate work than a client that only surfaces a Result on failure.
Yes. OpenRouter supports the same System One request and response format for Jev, and ClientConfig::openrouter builds the client for it; OpenRouter resolves jev-latest to a concrete typesafe/jev-* model id in its response, so the alias survives the hop. For a Tiny Humans key, ClientConfig::tinyhumans_openrouter targets one specific HTTPS endpoint, and with_sdk_name("openhuman") attaches sanitized x-sdk-name product attribution that is sent only to that exact endpoint, even when an endpoint override is configured.
Two things. The repository is GPL-3.0-only, which matters if the surrounding codebase is permissive - that is a legal question rather than a technical one, but it is stated plainly in the README. And it is consumed by pinned git revision rather than a version range, which is also why there are no release or compatibility notes there. If you run the live example, note that cargo run -p tinyjevclient --example basic does spend a real API call.
It is a typed Rust client used as an async crate. Build an EvaluationRequest::jev with shared JSON state and a map of Choice, Score and Noul questions, then call Client::from_env()?.evaluate(&request).await?. The live example spends a real API call: TYPESAFE_API_KEY='<key>' cargo run -p tinyjevclient --example basic.
It returns latency, attempts, usage and request metadata alongside the typed answers. Failed evaluations retain their classified error, attempt count and elapsed time, so reliability measurements do not lose unsuccessful work.
Remote API roots must use HTTPS, and HTTP is reserved for literal loopback IPs. The key is read from TYPESAFE_API_KEY or supplied to ClientConfig, is redacted from Debug and never included in errors. OpenRouter uses ClientConfig::openrouter, and a nonstandard path can be set without weakening provider-aware response validation.
More Jev resources like this
3GitHub stars
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.
Jev Repos & SDKs#community#jevbest#catalog-import
1GitHub stars
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.
Jev Repos & SDKs#community#jevbest#catalog-import
Community
JedimEmO/typesafe-clientRust
JedimEmO/typesafe-clientRust1GitHub stars
A Rust client for typed decision models across TypeSafe Jev, Cloudflare Clef, Liquid, Vercel AI Gateway and OpenRouter, with noul, choice and score builders, typed label enums, and a scripted fake for tests.
Jev Repos & SDKs#community#jevbest#catalog-import
Community
kunobi-ninja/kunobi-jevRust
kunobi-ninja/kunobi-jevRust45GitHub stars
Go SDK plus a pipeline-friendly CLI for typed decisions, covering single questions, batched question maps, retries, and line-oriented filtering over stdin.
Jev Repos & SDKs#community#jevbest#catalog-import
Community
mattn/go-jevGo
mattn/go-jevGo16GitHub stars
Swift library and CLI for asking Jev typed Choice, Noul, and Score questions from Apple platforms, with answers returned alongside calibrated probabilities in one parallel request.
Jev Repos & SDKs#community#jevbest#catalog-import
Community
d-date/swift-jevSwift
d-date/swift-jevSwift9GitHub stars
Go SDK for the TypeSafe API that asks typed Noul, Choice, and Score questions about a state and returns probability distributions with confidence and typed accessors.
Jev Repos & SDKs#community#jevbest#catalog-import
Community
Tangerg/typesafe-sdk-goGo
Tangerg/typesafe-sdk-goGoFrom the Jev guides
Original write-ups on what this entry is for.
Closed weights have not stopped the ecosystem from rebuilding the shape in the open. API-compatible servers, retrained heads on small models, and inference-time tricks that skip generation entirely.
Jev Repos & SDKs#open-models#research#local
Read article
From the Jev community
Posts from builders shipping with Jev right now.