I already use the TypeSafe SDK. Why add this layer?

Only if you might switch providers. The SDK ties you to TypeSafe, while system-one keeps the same choice, noul, and score code across Jev, local Reflex, or any compatible /v1/systemone endpoint.

Does it pick models or set thresholds for me?

No, deliberately. There is no routing, no model tiers, no thresholds, no escalation, and no retries — policy stays in your application, and malformed provider responses fail closed instead of being normalized.

Has anyone verified it against real providers?

The repository reports live contract tests, golden fixtures, and end-to-end Pi agent runs against jev-latest and Reflex on Qwen3.5-2B. Anything else is protocol-compatible, not verified.

How do I use it from the Pi agent?

Install the pi-system-one extension with pi install npm:pi-system-one for one system_one tool doing batched decisions. Pi-Bifrost is a separate consumer that uses the core for routing.

What do I install, and which way do the dependencies point?

npm install system-one-core for the runtime, and pi install npm:pi-system-one for the agent extension. The direction is one-way: pi-system-one depends on system-one-core, and Pi-Bifrost is a separate consumer that also sits above core. Nothing in system-one-core depends on Pi, on routing, on Bifrost, or on a specific model vendor, which is what keeps the decision code portable.

What happens if a provider returns something malformed?

It fails closed rather than guessing. Validation is strict, and a malformed provider response is rejected instead of being silently normalized into something plausible, so a broken endpoint surfaces as an error rather than as a confident wrong answer. Deterministic mock providers are part of the core for the same reason: they let you exercise the decision code with no live model in the loop.

What does it take to plug in a provider of my own?

Implement SystemOneProvider with a single evaluate(request) returning a promise of SystemOneResponse. That is enough for a hosted System One service, a local model server, a compatible /v1/systemone endpoint, an in-process implementation, or a deterministic test double. Switching the built-in HTTP provider between Jev and a local Reflex server is just a change to baseUrl, apiKey and defaultModel.

CommunityJev Integrations & Adapters

System One — iamaamir

Provider-neutral TypeScript runtime for System One decisions: write choice, noul, and score code once, then run it on TypeSafe Jev, local Reflex, any compatible /v1/systemone endpoint, or a custom provider.

See highlights

Open github.com

Stars: 69
Language: TypeScript
Published by: Community
Author: iamaamir
Last verified: Oct 2026

iamaamir/system-one

User repository on GitHub

View on GitHub

Provider-neutral System One runtime for TypeScript and Pi

Forks: 5
Last pushed: Updated Oct 2026

Repo stats from the GitHub API, cached Oct 2026.Homepage

About this project

system-one is a small, provider-neutral TypeScript runtime for bounded AI decisions. Use TypeSafe Jev today, Reflex locally, any compatible /v1/systemone endpoint, or your own SystemOneProvider tomorrow. Your application keeps the same choice, noul, and score code. System One is the abstraction. Providers are implementation details. Website · Pi integration · Pi-Bifrost. System One is already becoming an ecosystem. Different implementations can make the same kind of bounded decision:

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

Tagscommunity jevbest catalog-import awesomejev

Works forJev for Classification Jev for Tool calling

Used inJev for Software & DevTools

Languages: TypeScript

Highlights

The core owns the mechanism only: typed builders, strict fail-closed validation, and deterministic mocks; no routing, thresholds, or retries.
Tested live against jev-latest and Reflex on Qwen3.5-2B with contract tests, golden fixtures, and end-to-end Pi agent runs.
Ships system-one-core plus pi-system-one, a Pi extension exposing one system_one tool for batched decisions.
Swapping providers is a configuration change; the decision code stays the same.

Watch out

Only Jev and Reflex are listed as tested; other endpoints are protocol-compatible, not verified. Copy reviewed against the repo README on 2026-10-04, not from running it.

Questions about this entry

Short answers drawn from the linked project or page.

Other listings of this project

Forks and copies of this project in the directory. This entry is the canonical one.

system-one

Minimal Python recipe that turns any causal LLM into a Jev-style classifier by prefilling choice_index and constraining sampling to legal indexes in one forward pass.

Jev Practices & Patterns#community#jevbest#catalog-import

Community

sgoedecke/system-onePython

system-one

Vendor-neutral Python SDK for System One decision models. One ask(state, questions) call over noul, choice and score, with provider choice expressed as a config class rather than a string. Hosted backends, a Fastino GLiDE preset, and an in-process ONNX path needing no torch at runtime.

Jev Repos & SDKs#community#awesomejev#catalog-import

Community

asynq-io/system-onePython

system-one

An open System One decision model on small fine-tuned backbones, served locally through Apple MLX and speaking Jev's request/answer shape. Two model tiers with identity-bound temperatures, calibration fitted to your own labeled decisions, and a comparison ladder that includes the misses. A research prototype.

Jev Practices & Patterns#community#awesomejev#catalog-import

Community

mpuig/system-onePython

System One

The idea behind Jev: models that return typed decisions and probabilities instead of generated text, named after Kahneman's fast-thinking System 1, with confidence to route around uncertainty.

Jev Guides & ArticlesDocs#official#docs#architecture

Official

More Jev resources like this

loki

Agent runtime with a terminal UI and a messaging gateway that keeps memory, self-built skills, session search, scheduling, and subagents across Telegram, Discord, Slack, WhatsApp, Signal, and CLI.